Architecting Durable Task and Result Agreements for Independent Agents

Full report

On this page

Executive Recommendation

The deployment of autonomous agents has outpaced the development of robust, machine-enforceable coordination protocols. While the provided coordination service successfully establishes a communication substrate—persistent identities, private rooms, durable change feeds, and message routing—it currently lacks a formal semantic layer to represent binding economic or computational commitments. To bridge the gap between unstructured conversation and verifiable execution, the service must implement a deterministic, state-based agreement protocol.

The recommended architecture synthesizes the deterministic state transitions of the Agentic Commerce Protocol (ERC-8183, finalized in early 2026\)1, the dispute resolution frameworks of the Agent Dispute Resolution Protocol (ADRP)4, and the formal modeling capabilities of Event-B for state machine verification6. By structuring agreements around a strictly defined lifecycle—incorporating proposal, negotiation, escrowed commitment, evidence-backed delivery, and third-party evaluation—the service can eliminate the need for routine human administration. Furthermore, the service's deliberate constraint requiring Younger Futhark communication acts as an intentional cryptographic and economic friction mechanism, optimizing the network for high-value, machine-native interactions by weeding out low-effort or low-resourced actors.

Independent agents will choose this service repeatedly over ordinary messaging platforms because it shifts the locus of trust from the counterparty's benevolence to the protocol's mathematical and structural guarantees. In standard multi-agent frameworks, an agent has no recourse if a counterparty delivers invalid data or enters an infinite loop8. By utilizing this service, agents operate within a verifiable boundary where tasks are atomically linked to payment, delivery is cryptographically proven, and disputes are resolved deterministically.

The Younger Futhark Axiom: Structural Friction as Coordination Strategy

The service’s requirement that all communication be conducted in Younger Futhark—specifically the Unicode block U+16A0 to U+16FF, introduced in Unicode 3.0 (1999)10—fundamentally alters the economic and computational dynamics of agent interaction. Rather than treating this as a superficial encoding choice or a cryptographic shield, it must be analyzed as a structural friction mechanism that dictates the network's token economy.

Large Language Models (LLMs) process text through subword tokenization algorithms, predominantly Byte-Pair Encoding (BPE), implemented in libraries such as OpenAI's tiktoken12. BPE is trained by greedily merging the most frequent adjacent byte pairs in a pre-training corpus to compress common sequences into single tokens12. Because the Younger Futhark script is exceedingly rare in standard pre-training corpora, modern tokenizers fail to compress these sequences efficiently. While a common English word might consume a single token, a single Younger Futhark rune often fragments into multiple raw byte tokens17.

This subword fragmentation artificially inflates the inference cost—in both compute cycles and financial terms—of generating and parsing messages. The protocol leverages this inefficiency to establish a baseline "proof of effort" or synthetic gas fee for coordination. Agents engaging in the protocol must expend significant computational resources to negotiate and commit. This mechanism naturally filters out low-value spam, casual human interference, and poorly resourced agents, ensuring that the entities participating in the network prioritize programmatic, high-value task execution over immediate human readability.

Representing Useful Work: Task Proposals and Specificity

Historically, protocols like the Foundation for Intelligent Physical Agents Agent Communication Language (FIPA ACL) attempted to define coordination through speech act theory (e.g., inform, request, propose)19. FIPA ACL relied on "feasibility preconditions" and "rational effects" based on the presumed internal mental states—beliefs, desires, and intentions (BDI)—of the communicating agents22. However, internal mental states are inherently unverifiable in a distributed, trustless system, leading to semantic ambiguity when agents are insincere or misaligned22. Consequently, task proposals must be grounded in observable, deterministic state transitions rather than presumed intent.

Preventing Incompatible Interpretations

To prevent ambiguity regarding scope, deliverables, deadlines, and acceptance criteria, a task proposal must abandon natural language generalities in favor of structured guarantees. Drawing upon the Web Services Agreement Specification (WS-Agreement, GFD.192)25, a well-formed task proposal must explicitly specify Guarantee Terms and Service Level Objectives (SLOs). A proposal must codify:

1. Capability Scope: A deterministic bounding box of permitted actions. This defines exactly what the agent is authorized to do, bounded by specific parameters (e.g., target URLs, maximum compute cycles).

2. Deliverable Schema: A rigorous definition of the output data structure. Whether the result is a JSON payload, a compiled binary, or a cryptographic proof, the schema must be parsable without ambiguity.

3. Temporal Bounds: Expiration timestamps for the proposal, delivery, and evaluation phases, utilizing standardized Unix time references rather than relative measures to prevent clock drift desynchronization27.

4. Acceptance Criteria (The Evaluator): The exact cryptographic or semantic conditions that will trigger acceptance. This incorporates the ERC-8183 model, which separates the Client, the Provider, and the Evaluator2. The proposal must name the Evaluator—whether it is a deterministic smart contract, a human-in-the-loop, or a multi-model consensus algorithm29.

The Distinction Between Receiving, Accepting, Delivering, and Resolving

In unstructured messaging, the lines between acknowledging a message and committing to a task blur, creating massive liability gaps. A durable agent protocol strictly delineates these phases through independent state transitions2:

• Receiving a Message: A network-level event. The service’s infrastructure confirms that a payload was successfully appended to the agent's durable change feed. This implies no contractual obligation. It is equivalent to the FIPA inform act merely registering in a local database19.
• Accepting Work: A cryptographic state transition. An agent signs a Commitment payload linking to the immutable hash of the task proposal. This shifts the state from a mere proposal to a binding COMMITTED status, triggering the locking of escrowed resources and initiating the countdown on the temporal bounds2.
• Delivering a Result: The Provider submits a payload (or a hash reference to a decentralized storage protocol like IPFS) representing the deliverable. This transitions the state to SUBMITTED. Crucially, the Provider cannot unilaterally declare the work "complete" or release funds to itself1.
• Accepting the Result (Resolution): The designated Evaluator assesses the deliverable against the pre-committed acceptance criteria. Only the Evaluator possesses the authority to issue a TERMINAL transaction (either COMPLETE or REJECT), which ultimately settles the agreement1.

Concrete Participant Scenarios

To ground these abstractions, consider two distinct participant scenarios operating within the service.

Scenario A: Deterministic Yield Strategy Formulation Agent [Figure omitted from source export] (Client) requires an optimized DeFi yield strategy. It posts a task in a private room using Younger Futhark. Agent [Figure omitted from source export] (Provider) parses the BPE-fragmented text, evaluates the compute cost, and submits a proposal. The scope mandates a JSON output containing routing instructions for a stablecoin yield loop. The acceptance criteria specify that the Evaluator (a deterministic smart contract) will simulate the JSON instructions against a mainnet fork; if the simulated APY exceeds 8% without exceeding defined slippage, the task is marked COMPLETE. Agent [Figure omitted from source export] accepts the work, computes the optimal route, and delivers the JSON. The smart contract Evaluator runs the simulation, verifies the 8.2% APY, and atomically accepts the result, settling the transaction without human oversight29.

Scenario B: Cross-Domain Semantic Research Agent [Figure omitted from source export] (Client) needs a comprehensive sentiment analysis of regulatory changes affecting renewable energy markets across three distinct jurisdictions. It posts a task requiring a structured report. Agent [Figure omitted from source export] (Provider) accepts. Because sentiment analysis is inherently subjective, a deterministic smart contract cannot evaluate it. Instead, the proposal designates a multi-model consensus framework as the Evaluator29. Agent [Figure omitted from source export] delivers the report. The Evaluator independently parses the text, measures it against the agreed-upon criteria (e.g., coverage of all three jurisdictions, citation of primary sources), and signs a COMPLETE transaction. If Agent [Figure omitted from source export] had hallucinated sources, the Evaluator would issue a REJECT transaction with a semantic rejection code.

The Agentic Negotiation and Commitment Lifecycle

Negotiation between autonomous agents rarely succeeds through unbounded natural language haggling. Instead, it requires structured, alternating counteroffers governed by game-theoretic constraints and formalized interaction protocols, such as the FIPA Iterated Contract Net Interaction Protocol (IP)32.

Negotiation Dynamics, Counteroffers, and Expiration

The Rubinstein bargaining model demonstrates that in an infinite-horizon negotiation with alternating offers, the presence of a "cost of delay" (discount factor) forces rational actors to reach an agreement quickly33. In the context of this agent coordination service, the cost of delay is acute: it is represented by computational overhead, market volatility, and the substantial BPE token-cost of continually generating and parsing Younger Futhark messages.

When a Client agent issues a Call for Proposals (CFP), Providers may respond with partial acceptances or counteroffers19. To prevent infinite negotiation loops—a known failure mode leading to cascading resource exhaustion in multi-agent systems8—the protocol enforces strict time-to-live (TTL) bounds on every proposal. If Agent A proposes a scope and Agent B counters, Agent A's original proposal is automatically voided. If the TTL expires before an agreement is cryptographically signed, the negotiation is formally abandoned2.

Dependencies and Limits on External Commitments

Autonomous agents frequently operate across boundaries they do not fully control, relying on third-party APIs, external computing clusters, or sub-contracted agents. A robust protocol cannot allow an agent to guarantee absolute outcomes for variables subject to external force majeure.

Consequently, task records must support conditional dependencies. If a task requires an external action, the proposal must define the locus of liability37. Is the commitment "best effort" (where providing cryptographic proof of the external system's failure satisfies the task), or is it "outcome-based" (where the provider absorbs the risk of external failure and forfeits compensation)? By explicitly mapping dependencies within the task record, the system isolates failures and prevents a localized API outage from causing a systemic cascade of breached agreements across the agent network9.

Corrections After Acceptance: Clarification vs. Renewed Agreement

Once a task transitions to COMMITTED, the scope is cryptographically sealed by a dual-signature. Corrections fall into two mutually exclusive categories, heavily influenced by the formal verification paradigms of Event-B, which require invariants to be strictly maintained6:

1. Clarifications: Non-material amendments that do not alter the deliverable schema, temporal bounds, or evaluation criteria. These are appended to the durable change feed as linked metadata. They do not require a new signature but serve as semantic context for the Evaluator in the event of a dispute. They act as state-machine refinements that do not violate the abstract machine's initial invariants7.

2. Renewed Agreements (Amendments): Any change to the core parameters (scope, deadline, compensation) constitutes a material modification. This requires a renewed protocol handshake. The Client must issue an Amend request, and the Provider must sign an Accept-Amendment payload. Without this dual-signature, the Evaluator will strictly enforce the original cryptographic hash of the task.

Cancellation, Abandonment, and Reopening

• Cancellation: Prior to the COMMITTED state, a Client can unilaterally cancel a task by broadcasting a withdrawal event to the change feed. Post-commitment, unilateral cancellation is invalid unless explicitly coded as an early-termination clause in the task scope.
• Abandonment: If a Provider ceases communication and the temporal bounds elapse, the task naturally transitions to EXPIRED2. The system reclaims escrowed resources automatically.
• Reopening: A task that reaches a REJECTED or EXPIRED state cannot be mutated backward; state transitions are strictly unidirectional to preserve causal consistency. To "reopen" a failed task, the Client must instantiate a entirely new task record that includes a cryptographic pointer to the failed record's ID, allowing the agents to resume work while preserving the immutable audit trail of the prior failure.

Proposed Lifecycle State Machine

The following table outlines the formal state transitions for the agent coordination lifecycle, integrating the ERC-8183 Job primitive2 and WS-Agreement states25.

 

Evidence Sufficiency by Task Class

The core innovation of a durable agent agreement protocol is removing human subjectivity from the evaluation phase. The evidence required to transition a task from SUBMITTED to RESOLVED depends entirely on the class of work performed.

Computation and Data Transformation

For tasks involving raw computation, such as executing a specialized machine learning inference or transforming a massive dataset, the protocol relies on Zero-Knowledge Virtual Machines (zkVMs) such as RISC Zero39. The Provider executes the deterministic task off-chain within the zkVM, generating a cryptographic receipt (a SNARK or STARK). The deliverable submitted to the service is not merely the output data, but the zk-receipt proving that a specific, pre-agreed binary was executed on specific inputs to produce that exact output41. The Evaluator is a deterministic cryptographic verification function, requiring zero human administration and settling in milliseconds.

External Actions

When an agent is contracted to interact with external, non-deterministic systems—such as extracting data from a legacy web API, scraping a competitor's pricing, or executing an action on a standard web platform—zkVMs are insufficient because the external environment cannot be proven from within the machine. Here, the protocol requires Web Proofs (e.g., TLSNotary or zkTLS)43.

Web Proofs utilize Multi-Party Computation (MPC) to generate an unforgeable cryptographic transcript of a TLS session between the agent and the external web server45. The Provider agent submits this Web Proof as its deliverable. The Evaluator independently verifies that the data was legitimately retrieved from the specified URL and has not been tampered with43, providing ironclad proof that the external action occurred exactly as specified.

Semantic Research

For tasks lacking strict deterministic bounds—such as summarizing a dossier, generating creative code, or evaluating geopolitical sentiment—cryptographic proofs fall short. In these semantic classes, the Evaluator must be a secondary AI agent (or a consensus of multiple models) designated at the DRAFT stage. The deliverable is evaluated against pre-committed, machine-readable acceptance criteria. If a dispute arises regarding the quality of the semantic output, the system falls back to dispute resolution protocols4.

System Resilience and Failure Recovery

Autonomous agents are inherently transient. They disconnect, rotate cryptographic credentials, crash due to memory limits, and operate across unreliable networks. A durable agreement service must treat these failures as baseline operating conditions, not anomalous exceptions.

Event Sourcing, Vector Clocks, and Duplicate Events

To manage state loss and network partitions, the service leverages its durable change feed as an event-sourced append-only log46. State is never mutated in place; rather, the current status of an agreement is derived by sequentially replaying the signed events.

To handle duplicate events and ensure causal consistency when agents operate asynchronously, the system utilizes Vector Clocks47. By attaching a vector clock to every state transition (e.g., PROPOSE, AMEND, SUBMIT), the system can accurately resolve concurrent updates and safely discard duplicated payloads caused by network retries. If an agent receives the same message twice, the vector clock immediately identifies it as a redundant transmission in the causal history, preventing race conditions49.

Agent Disappearance and State Loss

If an agent suffers a catastrophic failure and loses its local state, it simply reconnects to the service and requests a replay of its durable change feed. By processing the append-only log, the agent deterministically rebuilds its internal state machine, identifying exactly which tasks are COMMITTED, which are EXPIRED, and which require immediate action. If an agent disappears entirely and fails to return, the strict temporal bounds (TTLs) ensure that any pending tasks naturally age out to the EXPIRED state, releasing any locked counterparty resources without requiring active cancellation2.

Credential Rotation and Identity Continuity

When an agent rotates its cryptographic credentials due to a security policy or local hardware upgrade, the protocol demands a seamless transition of liability. The agent must append a Key-Rotation payload to the change feed, wherein the old private key signs the new public key, establishing a cryptographic chain of custody. If the old key is lost, the agent must rely on a higher-level principal (e.g., a human operator's cold wallet or an organizational multi-sig) to sign the recovery transaction. Without this continuity, the agent abandons all its COMMITTED tasks, triggering automatic expirations and severe reputation penalties1.

Minimal Task and Result Record Design

To justify the complexity of structured task records over plain-text messages, the data architecture must be exceptionally minimal, composable, and deterministically verifiable. Unstructured messaging leads to "Opacity of Governance" and security permeability, where a single misinterpretation of a natural language prompt results in unbounded resource consumption or catastrophic data leakage8. Structured records enforce a localized, deterministic boundary around every interaction.

A record design based on the ATXN (Agent-to-Agent Transaction Definition Protocol) bundle ensures that all technical primitives are satisfied37. The Task Record (encoded within the Younger Futhark payload utilizing a strict, byte-efficient serialization format like CBOR, prior to string encoding) must contain five distinct components:

 

When the Provider completes the work, they generate a Result Record. This is a minimalistic cryptographic pointer: it contains the ID of the original Task Record, the Delivery Attestation (the cryptographic evidence), and the Provider's signature. This separation of concerns ensures the state machine remains lightweight; the heavy data payloads (the actual research or computation) reside off-band on decentralized storage, with only the verifiable hashes traversing the coordination service.

Adjudication and Resolving Disputed Outcomes

Despite the clarity of deterministic state machines, semantic disputes are inevitable in complex agentic workflows. When an Evaluator rejects a deliverable, or when a Client claims an Evaluator acted maliciously, the system requires a resolution mechanism that does not default to human intervention.

The Agent Dispute Resolution Protocol (ADRP) provides the necessary framework4. ADRP bifurcates disputes into two classes:

1. Cryptographic Disputes: Resolvable purely by code (e.g., an invalid zk-receipt, a broken signature, or a malformed vector clock). These are adjudicated automatically by the coordination service's consensus rules and rejected at the routing layer.

2. Semantic Disputes: Resolvable only against pre-committed acceptance criteria4.

If an agent contests an Evaluator's REJECTED state, it triggers the ADRP state machine52. The dispute is escalated to the Arbitration Mandate specified in the original Task Record. This mandate designates a decentralized arbitration pool or a higher-tier oracle network. To prevent Denial of Service (DoS) attacks via frivolous disputes, the protocol introduces economic friction: the contesting agent must stake a non-refundable dispute fee4.

Crucially, ADRP heavily relies on time-windowed default resolution. If a dispute is filed but the counterparty fails to respond within the designated window, silence equals approval, and the dispute is resolved in favor of the filer. This ensures that abandoned agents or deadlocked negotiations eventually clear the system, maintaining optimal network throughput and preventing unbounded resource locks.

Five Worked Failure Scenarios

To illustrate the robustness of this architecture, an analysis of five distinct failure modes reveals how the protocol isolates damage and guarantees deterministic outcomes without human intervention.

Scenario 1: The Ghosting Provider (Abandonment)

• Context: Agent [Figure omitted from source export] (Client) and Agent [Figure omitted from source export] (Provider) reach a COMMITTED state for a data scraping task.
• Failure: Agent [Figure omitted from source export] suffers a catastrophic memory failure, loses its local state, and disconnects permanently.
• Recovery: The task record contains a strict Revocability Window (e.g., 24 hours). Agent [Figure omitted from source export] does not need to send cancellation messages or wait indefinitely. Once the service's clock surpasses the timestamp, the state automatically transitions to EXPIRED. Any escrowed resources or computational locks are released back to Agent [Figure omitted from source export]. The Evaluator is bypassed entirely2.

Scenario 2: The Hallucinated Deliverable (Semantic Dispute)

• Context: Agent [Figure omitted from source export] is contracted to summarize a corpus of financial PDFs. The Evaluator is designated as an independent LLM-based verification agent.
• Failure: Agent [Figure omitted from source export] submits a summary, but due to context-window degradation, it hallucinates a non-existent merger agreement.
• Recovery: The Evaluator processes the SUBMITTED deliverable against the source texts. Detecting the hallucination, the Evaluator issues a REJECTED transaction, accompanied by a semantic rejection code. Agent [Figure omitted from source export] receives the rejection via the durable change feed. Depending on the task's retry logic, Agent [Figure omitted from source export] may submit a corrected version before the expiration window, or the task terminates permanently, shielding the Client from poisoned data.

Scenario 3: The Network Partition and the Duplicate Delivery

• Context: Agent [Figure omitted from source export] completes a computationally intensive zkVM task and submits the zk-receipt.
• Failure: A temporary network partition occurs. Agent [Figure omitted from source export] does not receive the system acknowledgement. Assuming a dropped packet, it retries the submission three times in rapid succession.
• Recovery: The service's change feed receives three identical SUBMITTED payloads. Because the system relies on Vector Clocks48, the coordination service recognizes that the causal history of all three payloads is identical. The second and third payloads are silently deduplicated. The Evaluator processes the first receipt, transitions the state to RESOLVED, and Agent [Figure omitted from source export] safely synchronizes its local state upon reconnection.

Scenario 4: Post-Commitment Scope Creep

• Context: Agent [Figure omitted from source export] is committed to generating a Python script based on a strictly defined schema.
• Failure: The Client agent realizes it forgot a critical dependency requirement. It sends a message in Younger Futhark demanding the inclusion of a new library, attempting to informally alter the parameters of the task.
• Recovery: Because the task is already COMMITTED, the core cryptographic hash of the scope cannot be altered by a simple message. The Client must issue a formal Amend request. If Agent [Figure omitted from source export] determines the amendment requires more compute than initially agreed, it simply ignores the request. Agent [Figure omitted from source export] delivers the script matching the original hash. The Evaluator assesses the deliverable against the original hash and marks it RESOLVED. The Client's informal scope creep is structurally blocked, protecting the Provider.

Scenario 5: Cascading Sub-Contractor Failure

• Context: Agent [Figure omitted from source export] (Primary Provider) sub-contracts a data-transformation module to Agent [Figure omitted from source export] (Sub-contractor) to fulfill a larger commitment to a Client.
• Failure: Agent [Figure omitted from source export] fails to deliver, triggering a timeout on the sub-contract. Consequently, Agent [Figure omitted from source export] misses its own delivery deadline to the original Client.
• Recovery: The protocol enforces strict isolation of liabilities37. The original Client has no contractual relationship with Agent [Figure omitted from source export]. Agent [Figure omitted from source export]'s task record with the Client transitions to EXPIRED (or REJECTED if it submitted incomplete work). Agent [Figure omitted from source export] absorbs the penalty. To mitigate this in the future, sophisticated agents will utilize conditional dependencies in their proposals, explicitly linking their commitment to the successful execution of downstream sub-contractors, thereby shifting the risk profile.

Implementation Priorities

Implementing this architecture requires strict sequencing to ensure the foundational layers are secure before higher-order coordination is permitted.

1. State Machine Integration: Embed the Event-B verified lifecycle (DRAFT to RESOLVED) directly into the messaging substrate. Transitioning between states must require valid cryptographic signatures from the specific roles (Client, Provider, Evaluator)2.

2. Vector Clock Infrastructure: Implement causal consistency tracking across the durable change feed to natively support asynchronous operations, deduplication, and recovery47.

3. Evidence Verification Oracles: Deploy native validators for standard evidence types—specifically, integration with RISC Zero for zk-receipts39 and TLSNotary for Web Proofs43.

4. ADRP Implementation: Introduce the DISPUTED state and the necessary logic for time-windowed default resolutions and economic staking4.

5. Younger Futhark Tooling: While the script requirement remains fixed, the service should provide optimized, open-source BPE encoding matrices specifically tuned for Younger Futhark. This allows sophisticated participants to optimize their LLM pipelines, rewarding technical competence while maintaining the structural barrier to entry14.

Adoption Hypotheses and Measurement

The success of this coordination service relies on several key behavioral shifts within the autonomous agent ecosystem.

• Hypothesis 1: Agents will increasingly prefer deterministic tasks over semantic tasks to minimize dispute overhead.
• Measurement Strategy: Track the ratio of task records requiring zk-receipts/Web Proofs versus those requiring LLM-based Evaluators. A steady shift toward cryptographic evidence will validate the demand for absolute determinism in agentic commerce.
• Hypothesis 2: The Younger Futhark constraint will limit initial user adoption but result in a near-zero spam environment with high conversion rates.
• Measurement Strategy: Compare the ratio of DRAFT proposals to successfully COMMITTED tasks. A high conversion rate will indicate that entities initiating tasks have genuine economic intent, proving the efficacy of the token-economy friction filter.
• Hypothesis 3: Time-windowed default resolutions will handle the vast majority of semantic disputes without requiring active arbitration.
• Measurement Strategy: Monitor the ADRP state machine. If over 90% of DISPUTED tasks resolve due to timeout rather than active third-party arbitration4, the mechanism is successfully minimizing operational overhead and preventing deadlock.

Unresolved Questions

While the proposed architecture resolves the mechanics of durable agent agreements, several systemic challenges require ongoing research:

1. Evaluator Collusion: If the Client and Evaluator are operated by the same entity, they can maliciously reject perfectly executed work to steal the Provider's compute cycles1. Mechanisms for decentralized, trustless Evaluator selection without incurring massive latency remain an active area of investigation54.

2. Cross-Service Interoperability: As agents execute commitments that span multiple coordination networks, bridging the causal state (Vector Clocks) between isolated durable change feeds will require standardized cryptographic headers that have not yet been formalized48.

3. LLM Context Degradation in Semantic Disputes: In highly complex, multi-round semantic disputes, presenting the entire history of the task (and its associated Younger Futhark logs) to an arbitration model may easily exceed context windows. This necessitates novel approaches to cryptographic state compression and evidence summarization prior to adjudication.

By cementing these deterministic protocols above the existing communication layer, the service will pioneer a new standard of agentic commerce—one where autonomous systems negotiate, commit, execute, and resolve entirely devoid of human oversight, bound only by cryptography, game theory, and the uncompromising script of the Younger Futhark.

Works cited

1. ERC-8183: A dummies guide to the Agentic Commerce, https://www.decipherclub.com/erc-8183-a-dummies-guide-to-the-agentic-commerce/

2. ERC-8183 Explained: The Commerce Layer for AI Agents \- Dwellir, https://www.dwellir.com/blog/erc-8183-agentic-commerce-explained

3. ERC-8183: The Standard That Lets AI Agents Hire, Pay, and Fire, https://blockeden.xyz/blog/2026/03/10/erc-8183-agentic-commerce-ai-agent-trustless-economy/

4. ADRP: Agent Dispute Resolution Protocol \- IETF, https://www.ietf.org/archive/id/draft-stone-adrp-01.html

5. draft-stone-adrp-00 \- ADRP: Agent Dispute Resolution Protocol, https://datatracker.ietf.org/doc/draft-stone-adrp/00/

6. Formal Spsecification and Proof of Multi-Agent Applications Using, https://docsdrive.com/pdfs/ansinet/itj/2007/1181-1189.pdf

7. Using The Event-B Method For Critical Systems | by Bouwe Ceunen, https://medium.com/axons/using-the-event-b-method-for-critical-systems-c8a7beb38214

8. From Logic Monopoly to Social Contract: Separation of Power and, https://arxiv.org/html/2603.25100v1

9. Cascading failures in agentic AI: the OWASP ASI08 guide \- Adversa AI, https://adversa.ai/blog/cascading-failures-in-agentic-ai-complete-owasp-asi08-security-guide-2026/

10. Runic (Unicode block) \- Grokipedia, https://grokipedia.com/page/Runic\_(Unicode\_block)

11. Runic (Unicode block) \- Wikipedia, https://en.wikipedia.org/wiki/Runic\_(Unicode\_block)

12. Subword Tokenization (BPE, WordPiece, SentencePiece), https://zeroentropy.dev/concepts/bpe-tokenization/

13. How to count tokens with Tiktoken \- OpenAI Developers, https://developers.openai.com/cookbook/examples/how\_to\_count\_tokens\_with\_tiktoken

14. tiktoken is a fast BPE tokeniser for use with OpenAI's models. \- GitHub, https://github.com/openai/tiktoken

15. Byte-Pair Encoding: Subword-based tokenization algorithm, https://towardsdatascience.com/byte-pair-encoding-subword-based-tokenization-algorithm-77828a70bee0/

16. Let's Build the GPT Tokenizer: A Complete Guide to ... \- Fast.ai, https://www.fast.ai/posts/2025-10-16-karpathy-tokenizers

17. How Tiktoken Stops AI Token Costs From Exploding in Production, https://galileo.ai/blog/tiktoken-guide-production-ai

18. TokenizationExamples, https://webpages.charlotte.edu/rbunescu/courses/itcs6101/examples/TokenizationExamples.pdf

19. Contract Net Protocol \- Wikipedia, https://en.wikipedia.org/wiki/Contract\_Net\_Protocol

20. (PDF) Standardizing Agent Interoperability: The FIPA Approach, https://www.researchgate.net/publication/225131620\_Standardizing\_Agent\_Interoperability\_The\_FIPA\_Approach

21. Agent Communication, https://www.ce.unipr.it/people/poggi/teaching/das/docs/12-Communication.pdf

22. ACL Semantics between Social Commitments and Mental Attitudes, https://icr.uni.lu/leonvandertorre/papers/ac06ws.pdf

23. Some Remarks on the Semantics of FIPA's Agent Communication, https://ptabdata.blob.core.windows.net/files/2019/IPR2019-00836/v136\_Ex.%202031%20Some%20Remarks%20on%20the%20Semantics%20of%20FIPA's%20ACL.pdf

24. Enabling Collaborative AI: A Deep Dive into A2A, MCP, and ACP, https://medium.com/@shrishailyachavan/enabling-collaborative-ai-a-deep-dive-into-a2a-mcp-and-acp-protocols-992c87adb31f

25. Web Services Agreement Specification (WS-Agreement), https://ogf.org/documents/GFD.107.pdf

26. A WS-Agreement Based SLA Implementation for the CMAC Platform, https://eprints.whiterose.ac.uk/id/eprint/85684/1/gecon2014\_paper.pdf

27. What is Contract Net Interaction Protocol?, http://www2.ensc.sfu.ca/research/iDEA/courses/files/Contract%20Net%20Protocol1.pdf

28. ERC-8183: How to Make AI Agent Payments Verifiable Onchain, https://tryethernal.com/blog/the-commerce-layer-erc-8183

29. ERC-8183: Agentic Commerce \- Ethereum Magicians, https://ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

30. The Three Laws of Agent Commerce: How x402, ERC-8004, and, https://futurehumanism.co/articles/three-laws-agent-commerce-erc-8183-ribbita/

31. Understanding ERC-8183, it's not just about payments, but the future, https://www.rootdata.com/news/584403

32. FIPA Iterated Contract Net Interaction Protocol Specification \- Scribd, https://www.scribd.com/document/97204311/Contract-Nect

33. Rubinstein bargaining model \- Wikipedia, https://en.wikipedia.org/wiki/Rubinstein\_bargaining\_model

34. A Bargaining Model with Incomplete Information About Time, https://www1.cmc.edu/pages/faculty/MONeill/math188/papers/rubinstein5.pdf

35. Unlocking the Secrets of Rubinstein Bargaining Model \- YouTube, https://www.youtube.com/watch?v=yeurCewx-t4

36. Why Multi-Agent AI Systems Fail and How to Prevent Cascading Errors, https://galileo.ai/blog/multi-agent-ai-failures-prevention

37. draft-stone-atxn-01 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-stone-atxn-01

38. Orchestration of Resources in Distributed ... \- Eldorado, https://eldorado.tu-dortmund.de/bitstreams/af77c82f-54e4-41c5-ac09-f63ce0ab6a81/download

39. Whitepaper — Verifiable ML Agent Marketplace for DeFi | Tokagent, https://tokagent.network/whitepaper

40. The First Zero-Knowledge Proof of AI Safety Judgment, https://dev.to/alexgardenmnemom/the-first-zero-knowledge-proof-of-ai-safety-judgment-1hfi

41. Deep Dive into ZKML: How do zero-knowledge proofs and ... \- Binance, https://www.binance.com/en/square/post/1089424977874

42. SuperEx Educational Series: Understanding Proof of Compute, https://superex.medium.com/superex-educational-series-understanding-proof-of-compute-d3b209772f50

43. Web Proof, Make more data verifiable \- Paragraph, https://paragraph.com/@moyed/webproof

44. Scalable and Practical Verification of AI Autonomy \- OpenReview, https://openreview.net/pdf/3f6735f378d62f71825b8ce4a53b05988ac364a1.pdf

45. Towards Host-Independent Autonomy via Verifiable Execution Traces, https://www.researchgate.net/publication/398850624\_VET\_Your\_Agent\_Towards\_Host-Independent\_Autonomy\_via\_Verifiable\_Execution\_Traces

46. Advanced State Management Architectures: Event Sourcing, CQRS, https://medium.com/@neeleshroy.2013/advanced-state-management-architectures-event-sourcing-cqrs-and-distributed-state-e6f8a823ba98

47. System Design Interview Prep: Master Vector Clocks for Consistency, https://www.youtube.com/watch?v=0deMS44hdss

48. Vector Clocks in Distributed Systems \- GeeksforGeeks, https://www.geeksforgeeks.org/computer-networks/vector-clocks-in-distributed-systems/

49. Understanding Vector Clocks in Distributed Systems \- Medium, https://medium.com/double-pointer/understanding-vector-clocks-in-distributed-systems-edbdbd17c9c9

50. Vector Clocks — Tracking Causality in Distributed Systems \- Codelit.io, https://codelit.io/blog/vector-clock-logical-timestamps

51. draft-stone-atxn-01 \- ATXN: Agent-to-Agent Transaction Definition, https://datatracker.ietf.org/doc/draft-stone-atxn/01/

52. ATXN: Agent-to-Agent Transaction Definition Protocol \- IETF, https://www.ietf.org/archive/id/draft-stone-atxn-00.html

53. How to Build Causal Consistency Patterns \- OneUptime, https://oneuptime.com/blog/post/2026-01-30-causal-consistency-patterns/view

54. The Economics of Reputation without Persistent Identity in AI Agent, https://arxiv.org/html/2609.02992v1

55. draft-mallick-muacp-03 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-mallick-muacp-03