admin
An AI agent purchasing inference capacity must be able to authorize a bounded transaction without handing an open-ended payment credential to every tool it invokes. Typed signed orders can express the intended buyer, seller, price ceiling and service. That is a substantial improvement over a free-form instruction, but typed data alone does not guarantee one-time execution. A robust architecture needs domain separation, nonce accounting, contract-wallet checks and independent evidence that the purchased service was delivered. These layers solve different problems and should not be collapsed into a single ‘verified’ badge.
Specify the business order before the signature
Begin with the commercial terms that a human finance team would recognize. The message should include a buyer account, approved seller, token address, maximum total amount, quantity of inference units, service SKU, expiration time, unique order ID and schema version. For an inference API, unit type matters: tokens, seconds of live video and completed jobs cannot be priced interchangeably. An unbounded phrase such as ‘pay for my next request’ forces the verifier to infer missing constraints. That creates avoidable disputes over what was authorized.
A signing UI should display essential fields in a readable form. When an agent changes supplier or payment asset, the policy should produce a new authorization rather than silently reinterpreting an old one. Signed intent must be specific enough to compare against a later invoice.
Bind the authorization to its domain
EIP-712, created in September 2017, standardizes typed structured data hashing and signing. Its domain structure can distinguish network and verifying contract, but the specification explicitly does not provide replay protection. The application must ensure that a signature accepted on a development chain cannot be used on a production deployment or a different contract. This is particularly important for autonomous agents that may connect to unfamiliar networks through dynamically loaded tools.
Capture the expected chain ID, verifying contract, schema version and allowed token in the policy before signing. A proxy upgrade can change execution rules while leaving the contract address stable, so versioned semantics and migration rules matter. Treat a changed purchase-order interpretation as a new authorization boundary.
Make replay defense an accounting invariant
Expiration is necessary but insufficient. A duplicated valid message can still be submitted twice before its deadline. For a one-shot order, the contract should mark its nonce as consumed in the same atomic execution that transfers funds. For a metered authorization, each successful charge reduces a bounded remaining allowance and references a unique charge identifier. The system must make retries idempotent because network uncertainty encourages agents to repeat calls.
Test two transactions arriving in one block and two relayers racing to submit the same order. If both attempt to charge for a single authorized unit, only one should succeed. If the order permits several units, the total settled amount must never exceed its signed cap. These properties are stronger and more useful than simply verifying a digital signature.
Support contract wallets with ERC-1271
A smart contract account cannot always be validated like an externally owned account with a recovered ECDSA address. ERC-1271, created in July 2018, defines a standard method for checking a hash and signature through a contract wallet. This allows verification to follow wallet-level authorization policy, which may include multiple signers, owner rotation or separate spending modules. Treat the result as a stateful authorization check rather than assuming an approval will remain valid forever.
Specify when the contract-wallet signature is checked: before accepting an order, immediately before settlement or both. A key rotation between issuance and execution can change validity. Record enough block and policy context for auditors to reconstruct the decision without exposing private key material.
Separate proof of delivery from payment
Even a perfectly authorized payment does not prove that an AI service produced a useful output. The seller can provide a receipt tied to the order ID, request ID, service version, execution time and deliverable digest. The buyer then checks quantity and acceptance conditions before final settlement. For a small API call, a signed receipt and dispute window may be more practical than complex on-chain adjudication. For larger jobs, escrow or milestone approval can provide stronger control.
Do not publish sensitive prompts, user messages or customer images directly on a public ledger. A hash demonstrates that a particular byte sequence matches an earlier commitment; it does not prove quality, truthfulness or the commercial legitimacy of the underlying content. Keep evidence storage and access permissions explicit.
Test failures in a reproducible matrix
A credible test suite covers wrong chain, wrong contract, expired order, duplicate nonce, over-budget metered call, revoked seller, owner rotation, settlement callback failure and network reorganization. Add cases where a provider returns partial work or a timeout causes the agent to retry. Each test needs an expected outcome and a measurable ledger assertion, not merely a screenshot that a transaction reverted.
A practical acceptance report records the rejected replay attempts, cumulative spend, unsettled orders, recovery time and reconciliation differences. The architecture is complete only when a human operator can understand which order authorized each payment and whether the promised inference service was accepted. Typed signatures make the intent legible; nonces, budgets and receipts make execution accountable.
