PaperlayerView exact revision on arXiv

Source-linked AI summary

Agentic Settlement Protocol: An Application Profile for Refundable, Delayed-Fulfilment Agent Commerce on Stablecoin Rails

Behnam, Mohammadkhani, Atul Khekade, Ritesh Kakkad

arXiv:2609.02208v1cs.CR

TL;DR

Agent purchases may be large, refundable, and fulfilled after payment authorization, so atomic, final per-request payment is not sufficient. ASP profiles on-chain authorize-and-capture escrow around off-chain fulfilment engines, with coordinated holds, verification, and refunds. The paper states conditional safety and exposure properties, while leaving deployed measurement to follow-up work.

  • Problem

    Agent purchases need funds held until fulfilment and returned when appropriate, unlike atomic per-request payments that leave no room to wait for delivery.

    Source: §1 · p. 2

  • Method

    ASP profiles authorize-and-capture escrow around an off-chain fulfilment engine, coordinating hold deadlines, capture verification, engine-computed refunds, and seller exposure controls.

    Source: §4.6 · p. 11, §4.7 · p. 13, §10 · p. 21

  • Results

    Under A1 and H1–H3, no inventory is issued against reclaimable funds; under stated exposure caps and atomic reservations, maximum operator loss is bounded by λ⋅pool.

    Source: §4.5 · p. 10, §4.6 · p. 12

  • Takeaways & Limitations

    The design specifies a settlement layer for online businesses whose fulfilment systems can expose hold, commit, cancel, and refund operations.

    Source: §10 · p. 21

    Gas per operation, XDC finality latency, and expiry-race behavior remain unmeasured; evaluation is left to follow-up work.

    Source: §9 · p. 20

Abstract

from arXiv · show

Autonomous agents can already pay per request: HTTP-native protocols such as x402 let an agent sign a stablecoin authorization and receive a resource in the same round trip. That model is atomic and final, which suits metered access and fails commerce: a purchase made on a person's behalf -- a service appointment, a physical order, a flight -- is large, frequently cancelled, and should not become the seller's money until delivery. We present the Agentic Settlement Protocol (ASP), an application profile over on-chain authorize-and-capture escrow (as standardised by the Commerce Payments Protocol) for businesses whose fulfilment is confirmed off-chain by their own order, scheduling, invoicing or booking system, abstracted as a fulfilment engine. ASP contributes: a three-deadline hold model separating the issuance deadline, escrow expiry and the engine's inventory expiry by an explicit submission-inclusion-finality margin, under which no inventory is issued against reclaimable funds; a fulfilment-verification ladder stating who is trusted to trigger capture, what their attestation proves, and under what challenge window; engine-authoritative partial refunds with a refund-liquidity order and per-seller exposure controls, including atomic exposure reservation, that bound the operator's credit risk; distributor revenue share that is provably unprofitable to self-deal; a single-currency-per-charge invariant; and a normative interface specification (x402 scheme, vault ABI, operator and connector APIs, conformance levels) intended to let independent implementations interoperate. The design originated in a review of travel-agency participation in agentic settlement and is instantiated on the XDC Network. This is a design paper; a fault-injection evaluation plan is specified and measurement is left to follow-up work.

1 Introduction

Atomic, irreversible agent payments suit metered access but do not fit purchases that are large, refundable, and fulfilled later. ASP specifies how to coordinate on-chain escrow with off-chain fulfilment systems, including hold timing, verification, refunds, exposure, and interoperable interfaces.

1 Introduction

  • The underlying authorize–capture–refund lifecycle exists on-chain in CPP, but its existing specifications do not coordinate escrow with an off-chain engine’s deadlines and refund rules [Coinbase and Shopify, 2025, Shopify Engineering, 2025].Unsynchronized holds can leave money held after inventory is released, or inventory reserved after funds return to the buyer.Source: §1 · p. 2
  • ASP defines an application profile over authorize-and-capture escrow for businesses whose off-chain fulfilment systems expose four operations.The business system is abstracted as a fulfilment engine; travel is the running example, not a universal scope claim.Source: §1 · p. 2
  • The three-deadline model separates issuance, escrow expiry, and inventory expiry by a margin for submission, inclusion, and finality.It ensures no inventory is issued against funds the buyer can reclaim.Source: §1 · p. 3
  • A fulfilment-verification ladder specifies who may trigger capture, what their assertion proves, and the applicable challenge window.The refund model makes engine rules authoritative and bounds operator exposure with liquidity ordering and per-seller controls.Source: §1 · p. 3
  • ASP adds capture-time revenue sharing designed to prevent profitable self-referral, a single-currency-per-charge invariant, and a fulfilment-class registry.Its normative interfaces are intended to let independent implementations interoperate.Source: §1 · p. 3
  • ASP is a design contribution with a stated trust model and fault-injection evaluation plan, but no deployed-vault measurements yet.The operator is trusted for capture decisions according to the verification rung; instant-reserve settlement is custodial by construction.Source: §1 · p. 3

2 Background

Existing agent-payment and checkout protocols address distinct parts of commerce: metered payment, escrow, or authorization and checkout. Online businesses already manage time-bounded holds, commitments, cancellations, and refunds in their own fulfilment systems, which ASP abstracts as a common engine interface.

2.1 Metered agent payments: x402

  • x402 provides an HTTP payment handshake and exact, upto, and batch-settlement schemes, but its shipped schemes lack a delivery-dependent hold and exact is irreversible after execution [Linux Foundation, 2026].A seller’s entitlement is based on the buyer’s signature and the seller’s accounting [Linux Foundation, 2026].Source: §2.1 · pp. 3–4

2.2 On-chain authorize-and-capture escrow: CPP and x402r

  • CPP supplies on-chain authorize, capture, charge, void, reclaim, and refund operations, and x402r packages this escrow in the x402 handshake [Coinbase and Shopify, 2025, Shopify Engineering, 2025, x402r, 2026].ASP builds on CPP-compatible escrow rather than claiming a new escrow mechanism.Source: §2.2 · p. 4

2.3 Agent authorization and checkout: AP2 and ACP

  • AP2 standardizes signed user-intent, cart, and payment mandates, while ACP standardizes agent–merchant checkout messages with off-chain processor settlement [Parikh and Surapaneni, 2025, Stripe and OpenAI, 2025].Neither specifies on-chain settlement; ASP is intended to sit beneath them.Source: §2.3 · p. 4

2.4 Fulfilment lifecycles in online businesses

  • Online order, scheduling, invoicing, freelance, and travel systems already use time-limited holds, commitment or confirmation, cancellation, and refunds under their own rules.ASP calls a system with hold, commit, cancel, and refund computation a fulfilment engine; that engine owns refund calculations.Source: §2.4 · pp. 4–5

3 System and Trust Model

The system assigns payment, fulfilment, and capture responsibilities across the principal, buyer agent, seller, operator, escrow, and optional distributor and arbiter. Its trust model relies on explicit timing and engine assumptions, while retaining operator discretion over capture and identifying threats that are outside scope.

3.1 Parties

  • The principal sets the spend cap; the buyer agent selects and authorizes, while the seller owns inventory and receives proceeds through a payout vault.The operator relays authorizations and acts on fulfilment evidence; escrow holds funds between authorization and capture, and a fulfilment engine is authoritative for fulfilment and refundable amounts.Source: §3.1 · p. 5

3.2 Assumptions

  • The capture margin M sums operator submission, chain inclusion, finality, and timestamp-drift bounds, with only finality treated as a chain property.The model assumes a supported stablecoin and authorization method, honest engine reporting, and bounded operator behavior; the operator is not trusted to fabricate evidence at the applicable verification rung.Source: §3.2 · pp. 5–6

3.3 What is and is not trust-minimised

  • “Non-custodial” means the operator cannot redirect in-flight escrow funds arbitrarily, not that it lacks discretion over when to capture [Shopify Engineering, 2025].Instant-reserve settlement is custodial because the operator controls the reserve; it is offered for vetted sellers rather than as the default.Source: §3.3 · p. 6

3.4 Threats considered

  • The threat model includes payment, fulfilment, refund, agent, seller-hook, referral, and stablecoin-depeg risks; engine compromise, censorship beyond Tf, and on-chain metadata privacy are out of scope.The listed in-scope cases include double-charging on retry, capture without fulfilment, refund default, and a compromised buyer agent draining principal.Source: §3.4 · p. 6

4 Protocol

ASP specifies an authorize-and-capture escrow protocol for agent commerce, covering charge deadlines, fulfilment verification, refunds, seller exposure, settlement safeguards, and off-chain orchestration. It defines interoperable implementation requirements while leaving the full implementation state machine to a companion specification.

4.1 Objects

  • A short-expiry signed Offer fixes settlement terms, and its hash binds buyer authorization to those terms; a connector-signed receipt attributes an engine issuance report but does not prove supplier issuance.The chargeId is also the idempotency key across layers.Source: §4.1 · pp. 6–7

4.2 State machine and escrow interface

  • The escrow interface is a strict subset of CPP, with chargeId-keyed idempotent calls and cumulative refunds capped at the captured amount.The vault records issueDeadline at deposit and rejects capture when attestation issuedAt exceeds it.Source: §4.2 · p. 8

4.3 Who signs the Offer

  • Offer signing may be direct, delegated, or operator-signed under mandate; delegated and mandate keys can bind sellers within inspectable scope limits, and ASP-Lite uses delegation.The seller can revoke a delegated connector key, making Offers signed after revocation invalid.Source: §4.3 · p. 8

4.4 Message flow

  • The workflow creates a provisional engine hold before the Offer, authorizes escrow, commits fulfilment before the issuance deadline, and then captures, voids, reclaims, or refunds as appropriate.When an engine cannot hold before authorization, the connector uses a policy expiry and voids and re-quotes if the actual hold fails H1.Source: §4.4 · p. 9

4.5 Hold coordination

  • Under H1–H3, no inventory is issued against funds reclaimable before capture finality, although a reservation may remain alive after escrow expiry.If capture is late, the operator pays the seller from its pool; fulfilment classes with holds shorter than the required margin must use charge mode rather than escrow.Source: §4.5 · p. 10

4.6 Refunds

  • Refunds follow the fulfilment engine’s rules, draw first on seller funds and reserves, and are bounded by per-seller exposure controls.Atomic exposure reservation at Offer issuance prevents concurrent quotes from exceeding seller caps; if reserved-inclusive seller exposure and the aggregate ceiling hold, maximum operator loss is at most λ⋅pool.Source: §4.6 · pp. 11–12

4.7 Fulfilment verification ladder

  • The verification ladder assigns each Offer a capture trigger and challenge window; rungs C and A capture optimistically, while rung S waits for acknowledgement or ruling.Rung C commits an attributable connector assertion, not cryptographically verified fulfilment; buyers, arbiters, or auditors can check the receipt against supplier records, and a demonstrable mismatch can support a refund from the operator pool.Source: §4.7 · pp. 12–13

4.8 Fees and revenue share

  • When the distributor’s fee share s is below 1 and it bears the full charge without subsidy, each referred charge produces a net loss.A third-party subsidy can reverse the condition unless it is below f(1 − s) per charge.Source: §4.8 · p. 13

4.9 Multi-stablecoin, single-currency charges

  • ASP permits registry-added stablecoins but requires one token throughout each charge, avoiding conversion steps while fragmenting liquidity across seller vaults.A seller maintains a vault per accepted currency; if buyer and seller share none, the buyer agent must fund an accepted currency before quoting.Source: §4.9 · pp. 13–14

4.10 Settlement modes and pause

  • Escrow is the default; vetted sellers may receive instant payment against a rolling reserve funded by captures, while pauses can halt deposits and captures but never reclaim.Instant-reserve mode is custodial and requires business verification; the reference deployment assigns the pause role to a time-locked multisig.Source: §4.10 · p. 14

4.11 Interface specification, orchestration and conformance

  • The normative interfaces cover x402 offers and authorizations, vault functions, operator and connector APIs, and ASP-Lite, ASP-Core, and ASP-Full conformance.Settlement-affecting messages must be on-chain or signed with an on-chain hash; off-chain calls are idempotent on chargeId, and timing fields use UTC Unix seconds in chain time.Source: §4.11 · p. 14
  • Orchestration blocks commit until the H1 hold check passes, resolves engine-call timeouts through getHold, and reconciles non-terminal charges using chain authority for payment and engine authority for fulfilment.The paper leaves the full off-chain state machine, reconciliation matrix, risk-engine algorithm, and relayer design to the companion ASP-Lite Implementation Specification; it fixes only what implementations must agree on to interoperate.Source: §4.11 · pp. 14–15

5 Security Properties

The section argues five informal safety properties covering fund recovery, authorization reuse, buyer exposure, late capture, seller payment finality, and seller hooks.

5 Security Properties

  • Every deposit is eventually captured to the seller or returned to the buyer, without depending on operator liveness.After expiry, anyone can call reclaim, and pausing does not block it.Source: §5 · p. 15
  • A buyer authorization is debited at most once because the escrow rejects duplicate chargeIds and token-level authorization nonces are single-use.The chargeId hashes the authorization structure, including a nonce.Source: §5 · p. 15
  • Buyer loss from a malicious operator is bounded by uncured captures within one challenge window and the smart wallet’s spend cap.Escrowed funds can only go to the seller’s registered vault and fee splitter; challenge refunds follow the liquidity order.Source: §5 · p. 15
  • Late-capture loss is assigned to the operator and counted in aggregate liability, which Proposition 3 bounds.The seller is exposed to operator solvency, not chain timing.Source: §5 · p. 15
  • After capture, seller proceeds can only be reduced by an engine-authorized refund within the refund window or an arbiter’s direction.The escrow limits refunds to the captured total and accepts them only before the window closes.Source: §5 · p. 15
  • Seller-supplied code cannot move, hold, or redirect funds because the vault, not the hook, executes transfers.Off-chain hooks have no on-chain authority; on-chain hooks can only observe, annotate, or veto.Source: §5 · p. 15

6 Integration with Fulfilment Engines

ASP leaves a seller’s core engine unchanged and connects it to a shared settlement lifecycle through class-specific connectors. The section describes the registry, example mappings, extensibility, and onboarding requirements.

6 Integration with Fulfilment Engines

  • ASP sits in front of the seller’s existing system, mapping its lifecycle through an operator-run connector without changing the core engine.Seller operations still require work.Source: §6 · p. 15

6.1 Fulfilment-class registry

  • A fulfilment-class registry captures differences in engine operations, hold limits, verification rungs, and refund computation; a new class needs a registry row and connector, not a protocol change.An Offer names its class, whose connector implements the mapping.Source: §6.1 · p. 16

6.2 Worked mappings

  • Worked mappings cover five representative classes, with travel included for its tight holds and complex refund rules.For appointments, confirmation captures earlier at rung C, while completion uses rung A and protects the buyer more; two charges can separate deposit and balance.Source: §6.2 · pp. 16–17

6.3 Extensibility

  • Off-chain hooks run at state transitions but cannot affect settlement; on-chain hooks are audited, whitelisted, and constrained by the hook-isolation property.The reference deployment ships off-chain hooks only.Source: §6.3 · p. 17

6.4 Onboarding paths

  • Onboarding requires engine or API access, field mapping, cancellation and refund permissions, a payout vault, business verification, and sandbox certification.Platform connectors can onboard multiple sellers, while buyer agents need no seller-specific integration.Source: §6.4 · pp. 17–18

7 Instantiation on the XDC Network

The reference deployment targets XDC and uses USDC, with infrastructure choices tied to the paper’s timing and spending-limit assumptions. ASP-Lite narrows the profile to a staged first implementation.

7 Instantiation on the XDC Network

  • The deployment targets XDC’s deterministic finality and USDC on XDC, using ERC-3009 authorization and operator-paid relayer gas.The bounded finality time supports the timing assumption used by the design.Source: §7 · p. 18
  • Buyer smart accounts enforce per-charge and rolling spend caps, while sellers receive proceeds in counterfactually deployed payout accounts.Agent and seller identities use ERC-8004 registries, with ecosystem-maturity caveats noted.Source: §7 · p. 18

7.1 Reference implementation scope: ASP-Lite

  • ASP-Lite limits the first implementation to USDC on XDC, one seller and class, rung C, escrow mode, seven operations, one operator fee, and off-chain hooks.Multi-stablecoin support, revenue share, instant reserve, additional rungs, on-chain hooks, and ERC-8004 integration are deferred until ASP-Lite passes evaluation.Source: §7.1 · p. 18

8 Related Work

The related-work discussion places ASP alongside industry payment protocols and academic work on agent payments, security, and settlement. It identifies a gap in specifying how on-chain and off-chain holds are coupled and how fulfilment trust varies by good or service.

8 Related Work

  • Prior academic work covers agent-payment stages and reversibility [Zhang et al., 2026], payment-step attacks [Mao et al., 2026], and service execution bound to cryptocurrency payment [Li et al., 2026].The discussion also relates ASP to work on replay [Lan et al., 2026] and compliance escrow hooks [See and Tan, 2026].Source: §8 · p. 19
  • The literature discussion distinguishes ASP’s fulfilment-coupling gap from work on x402 free-riding, compliance settlement hooks, and AP2 replay.The cited analysis associates exact-scheme free-riding with a seller serving without payment or a buyer paying without service [Anonymous, 2026].Source: §8 · p. 19
  • The authors identify no prior specification of coupling an on-chain hold to an off-chain fulfilment engine’s hold or assigning fulfilment-verification trust by class.ASP is discussed alongside x402, CPP, x402r, AP2, and ACP.Source: §8 · p. 19

9 Limitations and Open Questions

The paper identifies unresolved scope and trust constraints and reports no deployed measurements. Its evaluation plan specifies fault-injected XDC testing, but results remain future work.

9 Limitations and Open Questions

  • No deployed measurements are available; gas, finality latency, and expiry-race behavior remain unmeasured.The authors frame the paper as a specification that a future evaluation plan will test.Source: §9 · p. 20
  • Open issues include operator discretion at verification rungs A and S, unsupported partial capture, public on-chain amounts and timing, jurisdiction-dependent regulation, and pricing choices.The challenge window bounds but does not eliminate operator discretion; multi-operator or arbiter-set designs remain future work.Source: §9 · p. 20

9.1 Evaluation plan

  • The plan exercises ASP-Lite on XDC testnet and then mainnet using a simulated fulfilment engine and one real connector.Faults include engine timeouts, operator crashes, duplicate callbacks, RPC outages, expiry-boundary races, empty-vault refunds, and token pauses.Source: §9.1 · p. 20
  • The evaluation targets thousands of lifecycles and records capture and refund timing, reverts, late-capture losses, exposure-control behavior, gas, and timing margins.An independently written implementation will run the conformance suite against the first implementation’s vault to test interoperability.Source: §9.1 · p. 20

10 Conclusion

ASP applies an authorize-and-capture escrow to purchases fulfilled through an abstract business engine. It coordinates inventory and funds, verification, refunds, and revenue sharing across listed online-business classes.

10 Conclusion

  • ASP addresses agent purchases requiring inventory holds, accountable fulfilment assertions, and refunds calculated under the applicable fare rules.The conclusion contrasts these needs with metered agent payments.Source: §10 · p. 21
  • Its design separates issuance from reclaimable funds, specifies who can attest fulfilment and for how long, and defers refunds to the engine while bounding operator exposure.The profile also makes distributor revenue share unprofitable to self-deal.Source: §10 · p. 21
  • The protocol uses an abstract fulfilment engine and registry classes for physical orders, appointments, invoices, freelance deliverables, and subscriptions.Travel is the running example because it forces the design requirements to be addressed.Source: §10 · p. 21

A Authorization struct

The Offer struct binds seller and fulfilment details, token and amount, timing, verification and refund terms, expiry, and signing authority. The buyer’s charge authorization repeats the offer’s timing terms.

A Authorization struct

  • An Offer binds the seller, fulfilment class and engine reference to a token, amount, three timing fields, verification rung, challenge and refund windows, policy reference, expiry, and signer authority.Its offerId is the keccak256 hash of the EIP-712 encoding of the Offer.Source: A Authorization struct · p. 21
  • The buyer agent signs a ChargeAuthorization containing the offerId, buyer, token, amount, matching timing fields, and nonce.Both issueDeadline and holdExpiresAt must equal the corresponding Offer fields.Source: A Authorization struct · p. 21
  • The vault recomputes offerId from the supplied Offer and rejects mismatched authorization timing fields; it stores issueDeadline and holdExpiresAt for capture and reclaim.The authorization uses an EIP-712 domain identifying ASP, version 1, chainId, and the vault contract.Source: A Authorization struct · pp. 21–22

B Sandbox certification cases

The appendices specify sandbox certification cases and an x402 interface for ASP offers and authorizations. They define validation, held-funds status, and facilitator failure responses.

B Sandbox certification cases

  • The sandbox suite covers settlement, voids, expiry, refunds, idempotency, timing gates, exposure caps, pauses, offer binding, decline, and commit-timeout recovery.Concurrent quote requests with headroom for one Offer must yield exactly one issued Offer and one exposure-cap refusal.Source: B Sandbox certification cases · p. 22

C Appendix C: The x402 asp scheme

  • An ASP-capable seller advertises a signed Offer in the x402 accepts array; clients recompute offerId, check its signature, and validate offer terms.The facilitator deposits the funds after verifying the payload.Source: C Appendix C: The x402 asp scheme · pp. 22–23
  • The example advertisement specifies ASP version 1 on XDC (eip155:50), with an asset, vault destination, operator API, and charge-status endpoint.The example’s Offer and signature accompany the scheme entry.Source: C Appendix C: The x402 asp scheme · pp. 22–23
  • The client submits a signed ChargeAuthorization and deposit proof; a successful settlement response means funds are held, with delivery following capture and status updates.Clients poll the status URL or subscribe to webhooks to learn whether a charge has been captured.Source: C Appendix C: The x402 asp scheme · p. 23

C.3 Failure

  • The facilitator reports errors for expired or mismatched offers, unauthorized signers, timing mismatches, exposure-cap breaches, and paused tokens.H1_VIOLATION applies only on the holdBeforeAuth path after void.Source: §C.3 · pp. 23–24

D Vault interface

The vault interface specifies escrow authorization, capture, reclaim, and refund rules, while the off-chain interfaces define how operators and fulfilment-engine connectors coordinate those transitions. Registry, arbiter, conformance, and versioning rules establish operational authority and compatibility boundaries.

D Vault interface

  • Delegation checks, timing equality, duplicate handling, and nonce consumption constrain deposits; revocation invalidates not-yet-deposited Offers but leaves authorized charges unaffected.Revocation favours sellers by neutralising compromised keys immediately, at the cost of buyers holding short-lived Offers.Source: D Vault interface · p. 25
  • Capture verifies attestor authority at issuance time, routes seller, fee, and reserve funds atomically, and updates exposure with the transfer; reclaim remains permissionless after expiry.Refunds follow the ordered available, reserve, delayed, then operator-pool liquidity sources in one transaction, and fail without partial payment if funds are insufficient.Source: D Vault interface · p. 26

E Off-chain interfaces

  • Connectors must prevent duplicate fulfilment after indeterminate commits by checking engine state before retrying, and must refuse commits at or after the issue deadline.A committed engine state leads to receipt production and capture; cancelled or expired states lead to voiding, while unknown states are polled until the issue deadline.Source: E Off-chain interfaces · p. 28

E.4 Fulfilment-class registry entry:

  • The fulfilment-class registry sets hold, cancellation, refund, challenge, and verification policies, while an arbiter can issue uphold-or-refund rulings executed through the vault’s liquidity order.The class entry specifies a default verification rung and challenge and refund windows; the Offer’s rung determines which arbiter is acceptable.Source: §E.4 · pp. 28–29, §E.5 · p. 29

E.5 Arbiter interface.

  • The chain is authoritative for payment state, the engine for fulfilment state, and the operator database only for orchestration; reconciliation must follow those authorities.Operators must monitor clock drift and relayer submission-to-finality timing because these are safety inputs to deadline handling.Source: §E.5 · p. 29

F Conformance levels and versioning

  • Conformance levels build from a single-token escrow core with exposure reservation to multi-token, distributor-share, arbiter, and additional advanced features.Conformance is demonstrated with the executable suite, which reports Appendix B cases passed at the claimed level.Source: ASP-Lite · p. 30

ASP-Lite

  • Protocol versioning requires a version bump for changes to typed-data layouts, the vault interface, or existing-field meanings; same-level implementations passing the suite are expected to interoperate without modification.The specification identifies testing two independent ASP-Lite implementations as part of the evaluation plan.Source: ASP-Lite · p. 30
Loading 2609.02208v1…