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

Unclonable Agent Execution Credentials proposes a strictly single use pre execution authorization for autonomous agents, where a zero knowledge nullifier guarantees the capability cannot be cloned or replayed by a compromised agent. Authors: Muhammad Zidan Fatonie ( @mzf11125 ) Summary Agent authorization on Ethereum typically relies on function scoped boundaries or static permissions. When building heavy infrastructure like the LadingLogic autonomous trade finance network, we hit a critical cysec wall with multi agent swarms. When an orchestrator delegates a high stakes task to a specialized off chain agent, it issues an authorization credential. The vulnerability is that a compromised agent can be cloned. A bad actor could copy the memory state and replay that authorization to drain funds or duplicate actions. We need a way to ensure that an execution capability fundamentally breaks after one use. By adapting the Unconditional Unclonable Encryption proofs detailed in arXiv 2607.21551 , this standard 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 ZK 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 smart contract sees the duplicate nullifier and instantly rejects the transaction. Two Choices Worth Surfacing Early Deriving nullifiers from a hidden salt rather than the transaction payload. If the nullifier were bound only to the payload, an identical legitimate subsequent task would be blocked. Binding to a unique cryptographic salt ensures that intentional duplicate tasks receive unique capability tokens, while cloned tokens produce colliding nullifiers. Translating physical unclonability to cryptographic nullifiers. The original arXiv 2607.21551 paper relies on quantum states. Since EVM environments are classical and data is infinitely replicable, this draft shifts the unclonable property from the data storage layer to the execution proof layer. 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 ensures no identical capability can ever execute again. It does not hide the on chain action itself. Relationship to Neighbouring Standards Function scoped delegation drafts provide excellent frameworks for access control and defining strict capability boundaries. This proposal solves a fundamentally different attack vector. While scoped delegation defines what an agent can touch, this unclonable standard guarantees that a specific authorized payload can strictly be executed exactly once. ERC 8354 Confidential Agent Policy Verdicts handles the privacy of the ruleset. A domain could plausibly use both, keeping the policy secret via ERC 8354 while ensuring the resulting execution credential cannot be replayed using this standard. Outstanding Issues August 5 2026: Cross chain nullifier synchronization. If a capability token is bridging across domains, the nullifier registry must resolve before a cloned agent can attempt execution on a secondary chain. I am looking into lightweight payload transmission to prevent race conditions. August 5 2026: Proof generation latency. Creating the ZK proof sits in the execution path, introducing a delay that an attacker might exploit if they have already cloned the agent memory. I am evaluating whether a secondary time lock is required. 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 those working on cross chain agent execution, how would you handle the nullifier registry mirroring? 2 posts - 2 participants Read full topic