I would like feedback on a narrow interoperability problem: after a buyer and an agent service provider have agreed to an order, how can they consent to changing its scope, price, deadline, or acceptance criteria without losing the previous agreement or accidentally authorizing additional spending?
This is an exploratory discussion, not an assigned ERC. Existing work or a suitable extension point may already cover it; pointers to concrete interfaces would be especially useful.
A concrete example
A buyer orders a report on three projects for 100 units, due tomorrow. During execution, the buyer requests ten projects and a spreadsheet. The provider proposes an additional 80 units and a longer deadline. Both parties need an unambiguous answer to:
- Which exact change did each party authorize?
- When does the change become effective?
- What happens if the additional funds are unavailable?
- Which criteria apply to work already submitted?
- Can a delayed signature or a competing change replace the current agreement?
An ordinary follow-up message should not by itself authorize an additional payment. Publishing a new catalogue offer also does not establish consent to changing an existing order.
Proposed boundary
The candidate standard would describe a signed amendment to an existing service order and the conditions for applying it. It would leave discovery, negotiation strategy, model execution, quality evaluation, disputes, and general escrow design to other components.
The initial experimental profile is deliberately small:
- One buyer, one provider, one payment asset, one settlement domain.
- An already-authorized order with an immutable identity and a revision history.
- Price increases or unchanged prices, and deadline extensions or unchanged deadlines.
- Changes only while the order is active and before a deliverable is submitted.
- Both parties approve the exact change. Neither silence nor a chat message constitutes approval.
Partial completion, refunds, changing providers, and changing payment assets would require separate profiles or replacement orders. The initial profile does not silently rewrite accrued rights.
Candidate message and application rules
An amendment identifies:
Amendment {
orderId: bytes32
baseRevision: uint64
baseTermsHash: bytes32
newTermsHash: bytes32
nonce: uint256
validUntil: uint64
}
For the local experiment, the committed terms are:
Terms {
scopeHash: bytes32
acceptanceHash: bytes32
totalPrice: uint256
deadline: uint64
}
newTermsHash commits to the complete new terms, rather than an ambiguous natural-language delta. Scope and acceptance documents are hashed from their exact bytes; their commitments do not establish the quality or availability of their contents. Signers need access to those documents and a readable before/after comparison.
The experiment uses EIP-712 with chainId and verifyingContract domain separation. The order identity resolves to the authorized buyer, provider, asset, and settlement context. Those bindings cannot be changed by an amendment in this profile.
Applying an amendment would require:
- The order is still active and
now < currentTerms.deadline, using the current authoritative revision immediately before applying the amendment. A previously agreed extension replaces the deadline used for this check; this profile has no separate immutable amendment cutoff. - The current revision, terms hash, and nonce match the signed base state.
- Both signatures are valid for the authorized parties and the amendment has not expired.
- The supplied new terms match the signed commitment and the selected profile’s restrictions.
- The supplemental funding,
newTerms.totalPrice - currentTerms.totalPrice, is secured and the new revision becomes active as one authoritative state transition. The funding delta, deadline check, revision, terms hash, and nonce all use the same current base state. For100 -> 180 -> 220, the supplements are 80 and then 40.
If any check fails, the current terms and balances remain unchanged. A successful transition advances the revision and nonce, making competing amendments from the old revision unusable. Either party can explicitly invalidate outstanding amendment signatures through a separate nonce advance; this does not cancel the underlying work.
Submitted work freezes amendment eligibility in this initial profile. Submission and acceptance records bind the exact order revision, terms hash, and result hash. More flexible milestone changes need an explicit rule for protecting existing submissions and earned amounts.
An adapter acknowledgement is not automatically proof of funding. A same-chain implementation can make funding and activation one EVM transaction. An off-chain marketplace would need a durable reservation and recovery design, with its trust boundary stated explicitly. Cross-chain atomicity is outside this proposal.
Relation to existing work
- ERC-8414 provides versioned task tenders and tender economics. This proposal asks about counterparties consenting to amendments of an existing service engagement. It would not mutate a tender’s fixed reward; a compatible integration may require a linked supplemental or replacement instrument.
- ERC-8001 provides generic agent coordination and consent. A central question is whether order amendment semantics should be a profile over that framework rather than a separate ERC.
- ERC-8412 addresses preregistered acceptance criteria. An amendment can reference a new criteria commitment for eligible future work, while preserving the criteria attached to protected submissions.
These are composition candidates, not claims that the integration is already implemented.
Implementation experiment and Finch use case
Finch’s public Agent integration documentation provides a useful motivating example: versioned offers, persisted Call Rights authority, logical invocations, terms hashes, and asynchronous supplemental input. The proposed integration would add a consented order-terms revision layer while preserving historical service versions and dispatch records. This is a proposed use case, not a claim of a production Finch deployment or endorsement.
A local JavaScript experiment currently exercises EIP-712 EOA signatures, supplemental mock funding, stale-revision rejection, signature invalidation, and revision-bound submission and acceptance. It is an executable state-machine experiment, not an audited escrow contract. Contract-wallet signatures, delegated authority, durable storage, real asset transfers, and the Finch adapter remain implementation work.
The next useful interoperability test would have one client construct an amendment and a separately implemented consumer verify and apply it using published test vectors.
Questions for reviewers
- Is this a missing interoperability boundary, or is an existing interface sufficient?
- Should this be an independent ERC, an ERC-8001 profile, or a companion to a commerce/tender standard?
- Is freezing changes once work is submitted a reasonable first profile?
- Which funding/activation guarantees should be common, and which should belong to adapters?
- Does another implementation want to compare a concrete workflow and test vectors?
Non-binding scope poll
This poll is advisory feedback on the direction, not an ERC approval vote. Please explain your choice, especially any overlap with existing work. The initial feedback window closes on 13 October 2026 at 09:30 UTC (approximately 3 days after publication); technical objections remain relevant regardless of vote totals.
- Explore a separate minimal ERC for service order amendments
- Define this as a profile or extension of an existing ERC
- Keep this at the application layer; no shared standard is needed yet
- Need more implementation evidence before choosing
References
| Reference | URL |
|---|---|
| ERC-8414 discussion | ERC-8414: Token-Bound Task Tenders |
| ERC-8001 specification | ERC-8001: Agent Coordination Framework |
| ERC-8412 discussion | ERC-8412: Preregistered Acceptance Criteria |
| EIP-712 | EIP-712: Typed structured data hashing and signing |
| Finch public integration documentation | Finch |