[Pre-ERC Discussion] Agent Service Order Amendments

What it claims

This is an exploratory proposal, not an assigned ERC. It defines a narrow boundary: a signed amendment to an already-authorized service order, plus the conditions for applying it. Discovery, negotiation, model execution, quality evaluation, disputes and general escrow design are left to other components. A new catalogue offer or a chat message never counts as consent. Both parties must sign the exact new terms.

How it works

newTermsHash commits to the complete new Terms (scopeHash, acceptanceHash, totalPrice, deadline), not to a natural-language delta. Scope and acceptance documents are hashed from their exact bytes. The hash proves nothing about their quality or availability, so signers need the documents and a readable before/after diff. Signatures use EIP-712 with chainId and verifyingContract domain separation. The orderId binds buyer, provider, asset and settlement context, and an amendment cannot change any of them.

An amendment applies only if all of these hold:

• The order is active and the original execution deadline has not passed.
• Revision, terms hash and nonce match the signed base state.
• Both signatures are valid and validUntil has not passed.
• The supplied terms match the commitment and the profile's restrictions.
• Supplemental funding is secured, and activation happens in one authoritative state transition.

If any check fails, the original terms and balances are untouched. If all pass, the revision and nonce advance, so competing amendments signed against the old revision become unusable. Either party can advance the nonce on its own to kill outstanding signatures; this does not cancel the work. Submission and acceptance records bind the order revision, terms hash and result hash.

How to use it

No code, repository or test vectors are published. The proposed next step is a cross-implementation test: one client builds an amendment from published vectors, and a separately implemented consumer verifies and applies it. The author asks for other implementations to compare workflows. A non-binding scope poll offers four options: a separate minimal ERC, a profile of an existing ERC, application-layer only, or more evidence needed. Feedback closes 24 October 2026, 09:30 UTC. Technical objections remain relevant after that date.

Limits

• Profile scope: one buyer, one provider, one payment asset and one settlement domain. Only price increases or unchanged prices, and only deadline extensions or unchanged deadlines, are allowed. Partial completion, refunds, provider changes and asset changes need separate profiles or replacement orders.
• Freeze on submission: no amendments once a deliverable is submitted. Milestone-style changes would need an explicit rule protecting existing submissions and earned amounts.
• Funding trust boundary:
• An adapter acknowledgement is not proof of funding.
• Only a same-chain implementation gets funding and activation in one EVM transaction.
• An off-chain marketplace needs a durable reservation and recovery design.
• Cross-chain atomicity is out of scope.
• Experiment coverage: the JavaScript experiment covers EOA signatures and mock funding only. It is not an audited escrow. Contract-wallet signatures, delegated authority, durable storage, real transfers and the Finch adapter are unimplemented.
• Prior-work integration: relationships to ERC-8001, ERC-8412 and ERC-8414 are composition candidates, not implemented integrations. Integrating with ERC-8414 would not mutate a tender's fixed reward. It may instead need a linked supplemental or replacement instrument.
• Finch: Finch is a motivating use case only, not a production deployment or an endorsement.