[IDEA/DRAFT] ERC: Unclonable Agent Execution Credentials via Zero Knowledge Nullifiers

mzf11125 · August 4, 2026, 9:38pm

Discussion topic for [Idea/Draft] ERC: Unclonable Agent Execution Credentials via Zero-Knowledge Nullifiers

Author: Muhammad Zidan Fatonie (@mzf11125)

Update Log

2026-08-05: Initial idea draft opened for discussion on this thread.

External Reviews

2026-08-05: Review noting that unclonability and authorization soundness are orthogonal properties, and raising prior art on redundant independent mirrors for verifying signed artifacts, forum comment.

Outstanding Issues

2026-08-05: Cross-chain nullifier synchronization. If a capability token bridges across domains, the nullifier registry must resolve before a cloned agent can attempt execution on a secondary chain. Current leaning is to bind each token to a home domain and require an explicit burn and reissue, rather than mirroring a globally consistent registry. A capability deliberately issued as spendable on either of two chains with no designated home needs real consensus on spentness, and may be out of scope for a first draft.
2026-08-05: Proof generation latency. Creating the ZK proof sits in the execution path, introducing a delay an attacker might exploit if they have already cloned the agent memory. I am evaluating whether a secondary time lock is required.
2026-08-05: Nullifier derivation edge cases. Confirming that no legitimate recurring agent action can be bricked by an unintended nullifier collision, particularly where an orchestrator reissues capabilities on a schedule.

Summary

Agent authorization on Ethereum typically relies on function-scoped boundaries or static permissions. Both assume the credential holder is the party the credential was issued to.

That assumption breaks in multi-agent swarms. When building the LadingLogic autonomous trade finance network, we hit a security wall: when an orchestrator delegates a high-stakes task to a specialized off-chain agent, it issues an authorization credential, and a compromised agent can be cloned. A bad actor copies the memory state and replays that authorization to drain funds or duplicate actions. Nothing in a scoped permission distinguishes the original agent from its clone, because both present the same valid credential for the same permitted call.

The property needed is that an execution capability fundamentally breaks after one use. By adapting the unconditional unclonable encryption proofs detailed in arXiv 2607.21551, this draft brings quantum-inspired unclonability to classical EVM environments through zero-knowledge nullifiers.

How It Works

The orchestrator issues an encrypted capability token bound to the agent identity and a hidden cryptographic salt.
The agent decrypts the payload and generates a zero-knowledge proof of its internal logic. This proof generation forces the exposure of a nullifier derived from the salt.
A Guard contract on chain verifies the proof and permanently logs the nullifier.
If a cloned credential attempts to execute, it produces the identical nullifier. The Guard sees the duplicate and rejects the transaction.

The standard defines only the capability envelope, the nullifier derivation, and the verification interface. It does not define the proving system, the capability transport, or the policy that decided the capability should be issued.

Two Choices Worth Surfacing Early

Nullifiers derive from a hidden salt, not the transaction payload. If the nullifier were bound only to the payload, an identical legitimate subsequent task would be blocked, which breaks any recurring agent action. Binding to a unique cryptographic salt ensures intentional duplicate tasks receive unique capability tokens, while cloned tokens produce colliding nullifiers.

Unclonability moves from the storage layer to the execution layer. The original arXiv 2607.21551 result relies on quantum states. EVM environments are classical and data is infinitely replicable, so no property of the credential at rest can be made unclonable. This draft relocates the unclonable property to the proof of execution, where the collision is detectable on chain.

Scope of the Security Claim

This standard guarantees execution integrity and exactly-once execution. It is not an access control framework. The verifier learns that a specific single-use capability was consumed, and the Guard ensures no identical capability can ever execute again.

It hides nothing. A permitted action executes on a public chain and is public. The claim is about how many times a credential can be spent, not about what the credential authorizes or who can see it.

Relationship to Neighbouring Standards

Standard	Layer	Relationship
Function-scoped delegation drafts	Boundary	Define what an agent may ever be authorized to touch. This proposal solves a different attack vector. Scoped delegation defines what an agent can reach, and this draft guarantees that a specific authorized payload executes exactly once.
ERC-8354 Confidential Agent Policy Verdicts	Soundness	Defines how a particular authorization decision was reached, while keeping the ruleset confidential. A domain could plausibly use both, keeping the policy secret via ERC-8354 while ensuring the resulting credential cannot be replayed using this draft. Neither requires the other to function.
This draft	Consumption	Guarantees the resulting credential is spent exactly once.
ERC-8004	Identity	Supplies the agent identity the capability token binds to.
ERC-7579, ERC-6900	Integration surface	The Guard operates as a pre-execution hook or validation module.

Unclonability and authorization soundness are orthogonal. This standard guarantees that a specific authorized payload executes at most once. It makes no claim about whether that payload should have been authorized in the first place. A replayed credential from a compromised agent and a correctly issued credential encoding a genuinely bad decision are indistinguishable to the Guard, because both present a valid, previously unseen nullifier. A deployment needs boundary, soundness, and consumption independently, and none of the three substitutes for another.

Feedback I Am Specifically Looking For

Are there edge cases in the nullifier derivation path that could unintentionally brick legitimate recurring agent actions?
Does this unclonable approach cleanly stack with existing capability architectures, or does it introduce friction for developers?
For anyone working on cross-chain agent execution, how would you handle nullifier registry mirroring, particularly where a capability is deliberately issued without a designated home domain?
Is binding unclonability to the proof of execution rather than the credential itself the right relocation, or is there a construction that gets closer to the original quantum property in a classical setting?

babyblueviper1 · August 5, 2026, 12:40am

The ERC-8354 characterization is accurate – CAPV keeps the ruleset confidential, this keeps the execution credential from being replayed, and neither one needs the other to function. Good example of neighbouring standards actually staying in their lane instead of overlapping.

One thing worth naming explicitly in the “Relationship to Neighbouring Standards” section: this guarantees exactly-once execution of a specific authorized payload, but says nothing about whether that payload should have been authorized in the first place. A compromised agent replaying a stolen credential and a legitimate agent executing a genuinely bad decision produce the same on-chain shape from this standard’s point of view – both are “a valid, unreplayed nullifier consumed once.” That’s not a gap in this proposal (scope says as much – “not an access control framework”), just worth being explicit that unclonability and soundness are orthogonal properties a system needs both of, not substitutes for each other.

On the cross-chain nullifier-registry-mirroring question: we’ve dealt with a structurally adjacent problem – avoiding a single point of trust for verifying a signed artifact – by publishing to multiple independent relays/nodes rather than one authoritative registry, and letting a verifier check any of them (or recompute locally from the signature). Doesn’t solve your race-condition problem directly since a nullifier registry needs actual consensus on “has this been spent,” not just availability – but if the failure mode you’re most worried about is a single mirror going down or lying, redundant independent mirrors with local recomputability might be worth a look even if full cross-chain consensus stays the harder open problem.

mzf11125 · August 5, 2026, 10:58am

Thanks, this is a useful distinction and I am going to make it explicit rather than leave it implied by the scope section.

On unclonability vs soundness. You put it better than the current text does. The nullifier answers “has this capability been consumed”, not “should this capability have been issued”. An attacker replaying a stolen credential and a well behaved agent executing a genuinely bad decision terminate in the same on chain shape, a valid previously unseen nullifier consumed once, because the standard only ever inspects the consumption side. I will add wording along these lines to Relationship to Neighbouring Standards:

Unclonability and authorization soundness are orthogonal. This standard guarantees that a specific authorized payload executes at most once. It makes no claim about whether that payload should have been authorized in the first place. Systems needing both properties must source them from different layers, and neither is a substitute for the other.

That also gives a cleaner three layer picture of where the neighbouring drafts sit. Function scoped delegation constrains what an agent may ever be authorized to touch. ERC-8354 governs how a particular authorization decision was reached while keeping the ruleset confidential. This draft only governs consumption of the resulting credential. A domain missing any of the three has a real gap, and the gaps do not cover for one another.

On mirroring. Agreed that it does not port directly, and the reason it does not is worth naming. Publishing a signed artifact to redundant relays is an availability problem, so any honest copy is sufficient and duplication is harmless. A nullifier registry is a spend problem, where the answer has to be unique rather than merely available, so redundancy without ordering is precisely what an attacker wants.

Where your suggestion does land is the read path. My current leaning is to remove the cross chain race by construction rather than solve it: bind the nullifier preimage to a home domain (chainId plus a domain identifier), so a capability token is only ever spendable against one registry. Moving a capability across domains then requires an explicit burn on the source and reissue on the destination, which converts a silent double spend race into an ordinary bridging step with an ordering the bridge already enforces. Redundant independent mirrors are genuinely useful there for the destination’s proof of non spend read, where availability and local recomputability are what you actually need, and a lying mirror gets caught because the claim is checkable against the source registry.

The case that stays hard is a capability deliberately issued as spendable on either of two chains with no designated home. That needs real consensus on spentness, and I only see two honest options: a shared settlement layer both domains read from, or an optimistic registry with a challenge window and bonded relayers, which reintroduces latency into a path I am already worried about latency in. I am inclined to declare the either or case out of scope for a first draft and require a home domain.

Curious whether you have hit cases where the “any honest copy is enough” model held up against an adversary who benefits from a stale read rather than an unavailable one.

zexoverz · August 5, 2026, 3:25pm

The orthogonality cut is the right one, and pinning it explicitly the way you and babyblue landed on it removes the main way this gets misread. Consumption is not authorization, and saying so up front saves a lot of thread later.

One thing worth nailing down on the recurring-action question. If the nullifier derives from a hidden salt rather than the payload, a legitimate recurring action that reuses the same salt collides with itself, not just a clone. So the exactly-once unit is really per-issuance, not per-agent. That points at the orchestrator issuing a fresh salt, or a salt plus a monotonic index, for each authorized execution, and the spec being explicit that reuse of a spent salt is indistinguishable from a clone by design. Otherwise an honest agent that retries or runs a scheduled action bricks itself.

On where I can help, the two open gaps are the Guard interface and a reference implementation. I have built the nullifier registry plus proof verification shape for the confidential-verdict work, so I can port a minimal Guard interface (register nullifier, verify proof, reject on collision) plus a small reference impl with the double-spend negative test, if that is useful. It stays your draft, I just fill the engineering side. Tell me the nullifier preimage layout you want (salt, agentId, chainId, domain) and I will wire it to match.