Update ERC-8001: Move to Review #1243
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Semantics updates based on review feedback
Collaborator
|
✅ All reviewers have approved. |
eip-review-bot
changed the title
3 tasks
SamWilsn
approved these changes
Oct 7, 2025
Contributor
SamWilsn
left a comment
SamWilsn
left a comment
There was a problem hiding this comment.
In your abstract, you might want to define an intent (for anyone, like me, who might not be super familiar).
Your motivation might benefit from a use case.
Line 33: s/above/below?
In Typed Data Hashes, I'd probably appreciate some introductory text to give some context for the following code snippet. Essentially, why does the reader need to see this code at this point in the document?
Comment on lines
198
to
+227
| - `proposeCoordination`: | ||
| - Verifies EIP-712 signature by `agentId` using ECDSA for EOAs or [ERC-1271] for contracts. | ||
| - Requires `intent.expiry > block.timestamp` and `intent.nonce > agentNonces[agentId]`. | ||
| - Stores the canonicalised state and sets `agentNonces[agentId] = intent.nonce`. | ||
| - Emits `CoordinationProposed`. | ||
| Rejects: invalid signatures, expired intents, non-monotonic nonces, malformed participants | ||
|
|
||
| Accepts valid EIP-712 signed intents and: | ||
| - Emits `CoordinationProposed` | ||
| - Makes intent queryable as `Proposed` | ||
| - Enforces nonce monotonicity for `agentId` | ||
|
|
||
| - `acceptCoordination`: | ||
| - Checks the intent exists and is not expired. | ||
| - Verifies the participant is listed and has not already accepted. | ||
| - Verifies the acceptance signature against the typed `AcceptanceAttestation`. | ||
| - Records acceptance and stores the acceptance `expiry` for that participant. | ||
| - Emits `CoordinationAccepted` with the typed acceptance hash. | ||
| - Returns `true` when all required acceptances are present. | ||
| Rejects: non-existent intents, expired intents, non-participants, duplicate acceptances, invalid signatures | ||
|
|
||
| Accepts valid attestations and: | ||
| - Emits `CoordinationAccepted` | ||
| - Adds participant to `acceptedBy` in status | ||
| - Returns `true` when all required acceptances present | ||
|
|
||
| - `executeCoordination`: | ||
| - Requires the intent to be in an executable state. In [ERC-8001](./eip-8001.md) the policy is **all participants have accepted**. | ||
| - Requires every stored acceptance to be unexpired at execution time. | ||
| - Verifies `payloadHash` matches the stored hash. | ||
| - Emits `CoordinationExecuted`. | ||
| Rejects: non-ready intents, expired intents or acceptances, payload mismatches | ||
|
|
||
| Executes when all participants accepted and unexpired: | ||
| - Emits `CoordinationExecuted` with result | ||
| - Status becomes `Executed` | ||
| - Returns success and execution result | ||
|
|
||
| - `cancelCoordination`: | ||
| - The proposer MAY cancel before execution. Anyone MAY cancel after expiry. | ||
| - Emits `CoordinationCancelled`. | ||
| - Status values are implementation-defined but MUST include Proposed, Ready, Executed, Cancelled, Expired. | ||
| - `executeCoordination` MUST: | ||
| - Verify status == Ready (i.e., every participant has accepted). | ||
| - Verify `block.timestamp < intent.expiry`. | ||
| - For each recorded acceptance: verify `block.timestamp < acceptance.expiry`. | ||
| - Verify `keccak256(abi.encode(payload))` equals the stored `payloadHash`. | ||
| Proposer MAY cancel before execution; anyone MAY cancel after expiry | ||
| - Emits `CoordinationCancelled` | ||
| - Status becomes `Cancelled` | ||
|
|
||
| - `getCoordinationStatus` MUST return one of: `None`, `Proposed`, `Ready`, `Executed`, `Cancelled`, `Expired` |
Contributor
There was a problem hiding this comment.
These are decent descriptions of pre- and post-conditions, but I think this section is lacking a bit of detail on what these functions actually do. Think natspec/developer docs.
eip-review-bot
approved these changes
Oct 7, 2025
Collaborator
eip-review-bot
left a comment
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
eip-review-bot
approved these changes
Oct 7, 2025
Collaborator
eip-review-bot
left a comment
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Move EIP-8001 to Review
Changes: