Add ERC: Unclonable Agent Execution Credentials

[mzf11125]

This proposal defines a single use capability token for delegated agent execution. An orchestrator issues a capability bound to an agent identity and a per issuance secret salt. Spending it requires a zero-knowledge proof, which forces a nullifier derived from that salt into the open, and the Guard burns the nullifier as part of performing the authorized action. A cloned agent holds the same salt, produces the same nullifier, and is rejected.

The idea was discussed on Ethereum Magicians before this PR was opened:
https://ethereum-magicians.org/t/idea-draft-erc-unclonable-agent-execution-credentials-via-zero-knowledge-nullifiers/29274

That thread ran for two weeks and changed the design three times. The substantive points and where each landed:

• Unclonability and authorization soundness are orthogonal (https://ethereum-magicians.org/t/idea-draft-erc-unclonable-agent-execution-credentials-via-zero-knowledge-nullifiers/29274/2). This is now the leading subsection of Security Considerations rather than a footnote. The proposal states plainly that it supplies one of several independent layers and that adopting it alone does not make an agent safe.
• chainId must not be in the nullifier preimage, or the nullifier forks per chain and the credential is spendable once on each. Chain binding is now an acceptance check on homeChainId instead.
• A separable spend primitive lets anyone satisfying the executor check burn a capability without performing the work, so exactly once holds and the deployment still loses. Issuance is now mandatory and the burn is fused to the authorized call. This was the largest change and it came directly from adversarial test vectors contributed on the thread.
• A revert cannot emit, so observability is a burn event on the accepting path plus a named error on the rejecting one, with highestIssuedIndex to classify a collision as a clone versus an issuer reissue bug.
• The security claim is stated as at most once with no ordering, not exactly once. Two holders of the same salt race and the Guard cannot rank them.
• Aggregate spend per identity is named as a separate layer and explicitly out of scope.

The reference implementation lives at https://github.com/mzf11125/unclonable-agent-execution-credentials and the Solidity sources are also vendored into assets/erc-1953/, so the proposal body carries no external links. Nineteen Foundry tests cover the cases in the Test Cases section, including the adversarial vectors from the thread.

Known open questions, stated rather than hidden:

1. Cross chain nullifier mirroring. A capability deliberately issued as spendable on either of two chains with no designated home needs real consensus on spentness. The draft requires a home domain and declares the other case out of scope rather than solving it.
2. Proof generation latency. Proving sits in the execution path, and an attacker holding cloned memory can start proving at the same moment. No mitigation is specified, because a time lock moves the race later without changing who wins it.
3. Relayed submission. The Guard requires msg.sender == executor, so an agent holding no gas cannot spend through a relayer. Adding an EIP-712 path needs a signature argument on execute, which changes the interface, so it is deferred.

All authors listed in the preamble have consented to CC0 licensing and to being named.

[eip-review-bot]

File ERCS/erc-1953.md

Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @lightclient, @samwilsn, @xinbenlv

File ERCS/erc-8380.md

Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @samwilsn, @xinbenlv

[github-actions]

The commit c4687e9 (as a parent of d576371) contains errors.
Please inspect the Run Summary for details.

[babyblueviper1]

Good to see this land as a formal PR -- the thread's arc (separable consume → Cedric's adversarial vectors → mandatory issuance + fused burn) is exactly the right sequence, and CI's green on the current head.

One place worth pinning down: "authorization soundness" is named as the layer this proposal explicitly does not supply (§ Security Considerations, "Unclonability and authorization soundness are orthogonal"). Is that meant to cover both (a) whether the issuing policy was actually followed, and (b) whether the resulting authorized action was itself a good decision? Those are different failure modes with different fixes -- a confidential policy verdict (CAPV / ERC-8354) can prove (a) without ever touching (b). We ran into the same split on the CAPV thread (https://ethereum-magicians.org/t/29088/54, replying to a similar "does ZK add anything over signing" question): ZK removes trust in the definer's honesty about execution, but that's compliance-with-policy, not soundness-of-the-outcome -- a policy can be followed to the letter and still authorize something bad.

Not proposing a change to scope, just flagging that if "authorization soundness" reads as one property to an implementer, a deployment wiring in ERC-8354 alone could believe it's covered both axes when it's only closed the first. Might be worth a clause distinguishing them, the same way the doc already separates unclonability from soundness.