I’m working on Agent Service Order Amendments, a pre-ERC proposal for mutually agreed changes before delivery submission. One integration case is increasing the price of an order that already holds budget.
The reserve/confirm/cancel discussion and the current Reservation Binding section already cover the shared-cap problem. My question is how to bind an amendment to those reservations. I’m assuming a reservation-aware substrate here, not a decrement of the monotonic spent in the flat budget profile.
For one chain, one asset, and a fixed shared cap of 300, these are the expected cases I’d propose:
- A reserves 100, B reserves 180: total committed is 280.
- A proposes 100 → 180: only the additional 80 is requested, but 280 + 80 > 300, so the amendment fails and A’s current terms and reservation remain unchanged. Buyer/provider agreement does not itself authorize raising the shared cap.
- If B confirms its 180, that converts reserved budget to confirmed spend; it does not free headroom for A’s amendment.
- If B instead validly cancels its unsettled reservation, A’s increase can fit. A subsequent 180 → 220 amendment requests only 40.
Would you recommend keeping one stable order reservation and atomically resizing it, or separate amendment-delta reservations grouped under the same order? In either design, I’d bind authorization to the order’s current revision, new terms hash and a replay-protected nonce within the registry/envelope domain, while retaining the reserver restriction. The budget update, escrow top-up and revision activation would succeed or revert together; stale revisions or failed funding would leave all three unchanged.
Our current prototype tests order revisions with EOA signatures and in-memory balances; these shared-budget cases are proposed integration tests, not completed ERC-8312 conformance or on-chain tests.