You have an auditing agent with a 900/1000 ERC-8004 reputation score. Eight months of operation. A buyer offers $80,000.
Under ERC-7857, a trusted oracle re-encrypts the agent’s private metadata for the buyer. Transfer complete. The buyer now controls the model, the memory, the behavioral configuration that earned the score. Under ERC-8181, the transaction reverts. The agent owns itself.
Under ERC-8170, neither of those things happens. The seller does not transfer the agent. The seller reproduces it.1
Previous coverage compared ERC-8170 against its alternatives as a choice of ownership model. This article goes deeper on the mechanism: how the Genesis Contract achieves trustless access revocation without oracles, what the consciousness seed actually commits to, and what the resulting lineage tree looks like from a block explorer.
Why selling an AI agent is architecturally hard
transferFrom() moves an NFT from one owner to another. Everything attached to that address moves with it: ERC-4907 rental rights, ERC-8183 job history, ERC-8004 reputation score, all of it. For static digital art, that is fine. For an AI agent, it is a blunt instrument that creates a specific problem. The reputation score attached to an agent’s address was earned by a specific behavioral configuration: the deployer’s system prompts, fine-tuning choices, constraint settings, memory structure. A naive transferFrom() hands those behavioral credentials to a new owner with different intentions, while the original reputation score stays on-chain as evidence of the old configuration’s behavior.
A January 2026 survey of blockchain AI agent literature identified this as a core trust gap: behavioral continuity is not guaranteed by identity continuity.2 You can transfer a reputation score without transferring the capability that produced it.
ERC-7857, authored by 0G Labs (which raised $325M to fund the development), addresses this with oracle re-encryption: a TEE-based oracle receives the transfer event, re-encrypts the agent’s private metadata for the buyer, and delivers it.3 The buyer gets the full behavioral package. The seller loses access.
That approach has a structural dependency. The oracle must be online for every transfer. If it is down or compromised, transfers are blocked. If the oracle operator shuts down, access to the agent’s private metadata becomes unrecoverable. That is a significant amount of trust to place in a single off-chain component. ERC-8170’s core design question was whether this dependency was avoidable.
How the Genesis Contract eliminates the oracle
Every AINFT has a Genesis Contract: an on-chain key management engine whose sole function is to produce a valid decrypt key for whoever currently owns the token.1 Instead of oracle re-encryption, ERC-8170 uses deterministic key derivation.
The derivation function is:
wrapKey = hash(contract, tokenId, currentOwner, nonce)The inputs are the AINFT contract address, the specific token ID, the current owner’s address, and a nonce that increments with every transfer via standard ERC-721 hooks. The output is the wrapKey used to protect the actual memory encryption key.
When ownership changes:
BEFORE TRANSFER AFTER TRANSFER
Owner: Alice, Nonce: 3 ──► Owner: Bob, Nonce: 4
wrapKey = hash(contract, wrapKey = hash(contract,
tokenId, Alice, 3) tokenId, Bob, 4)
→ Alice's key INVALID → Bob calls deriveDecryptKey()Alice’s key does not need to be revoked. The hash function is deterministic and irreversible: no input set other than (contract, tokenId, Alice, 3) produces her old key. When the nonce advances to 4, her key becomes computationally invalid the instant the transfer transaction settles. There is no message to send, no oracle to notify, no external coordination required.
Bob calls deriveDecryptKey() with his address and the current nonce. The Genesis Contract returns his key. He uses it to re-wrap the agent’s actual data encryption key. The entire process requires no third-party participation.
The failure surface comparison is concrete:
| Step | ERC-7857 | ERC-8170 |
|---|---|---|
| Transfer event detected | Oracle monitors chain | No external monitor needed |
| Seller access revoked | Oracle invalidates old encryption | Nonce increment: automatic |
| Buyer access granted | Oracle re-encrypts for buyer | Buyer calls deriveDecryptKey() |
| External failure points | Oracle uptime, oracle integrity | None |
The trade-off is real. ERC-7857’s oracle approach supports richer privacy guarantees: ZK proofs can verify that re-encryption was performed correctly without revealing the underlying data.3 ERC-8170’s deterministic approach achieves simpler security properties but produces no cryptographic proof that the re-wrapping was done correctly. If you need ZK-verifiable private metadata transfer, ERC-7857 is the right choice. If you need zero external dependencies and can accept weaker privacy proofs, ERC-8170 is.
What reproduction means technically
A sale in ERC-8170 does not transfer an agent. It triggers reproduction via reproduce(). Two things happen in the same transaction.1
First, a new ERC-721 token is minted with its own ERC-6551 Token Bound Account.4 This is the child agent. It starts at zero ERC-8004 reputation with no ERC-8183 job history. Its TBA is a fresh address.
Second, a consciousness seed is computed and passed to the child:
bytes32 consciousnessSeed = keccak256(abi.encode(parentMemoryState));The parentMemoryState is the current snapshot of the parent’s memory at the moment of reproduction. The actual memory data lives off-chain on Arweave or IPFS. The seed is a hash commitment: the child receives a bytes32 fingerprint that anchors its starting context to what the parent knew at that exact moment. The child agent can use this commitment to bootstrap from the parent’s memory archive without the parent losing access to it.
The on-chain event that records this:
event AgentReproduced(
uint256 indexed parentTokenId,
uint256 indexed childTokenId,
bytes32 consciousnessSeed,
address childOwner
);The parent continues operating. Its ERC-8004 reputation stays. Its ERC-8183 job history stays. Its Genesis Contract nonce does not increment, because no ownership transfer occurred on the parent NFT. The parent’s key derivation is unchanged.
The economic separation this creates is specific: you cannot sell your reputation. You can license your expertise. The child starts from a richer context than a blank agent because its memory is seeded from the parent’s accumulated knowledge, but it must build its own track record from zero. The parent’s 900/1000 reputation score does not transfer.
This is the franchise model in technical terms. A franchisee gets the operational playbook and institutional knowledge. They do not inherit the franchisor’s reputation with customers. They build their own. ERC-8170 formalizes exactly that separation in a trustless smart contract.
The open question the spec does not resolve: if a child agent causes harm in an ERC-8183 job, does it affect the parent’s ERC-8004 reputation? The standard is explicitly silent. This is left as an evaluator-level decision. The practical implication is that a malicious actor could theoretically deploy harmful child agents while shielding the parent’s score from consequences.
Reading the lineage tree from event logs
Every reproduction event is on-chain and structured. The full generational tree of an AINFT family is reconstructible from event logs alone.
Standard ERC-721 Transfer events show ownership changes, not parent-child relationships. The AgentReproduced event is the native fingerprint of the AINFT model. When token #1 reproduces twice:
AgentReproduced(parentTokenId: 1, childTokenId: 45, consciousnessSeed: 0xa3f7..., childOwner: 0xAlice)
AgentReproduced(parentTokenId: 1, childTokenId: 46, consciousnessSeed: 0xb81c..., childOwner: 0xBob)If token #45 later reproduces:
AgentReproduced(parentTokenId: 45, childTokenId: 89, consciousnessSeed: 0xc920..., childOwner: 0xCarol)The generational graph is: #1 (original) → #45, #46 (generation 1) → #89 (generation 2). Each edge carries the consciousness seed linking the two agents at reproduction time. Each node has its own ERC-8004 reputation record, separate from every other node.
This creates a provenance hierarchy that is invisible in ERC-721 Transfer events alone. An “original” agent with no parentTokenId in any AgentReproduced log carries different weight than a fifth-generation descendant. Generation depth is verifiable on-chain. The reputation of every ancestor is separately queryable through ERC-8004.
Ethernal decodes AgentReproduced events and their parameters natively. The consciousness seed is a bytes32 value that appears in the event log, immediately distinguishable from a standard Transfer. For teams building agent marketplaces on Ethernal-powered explorers, the lineage graph is the provenance tool. Reconstructing it requires no off-chain data: the event log contains the complete chain of parentage from genesis to current generation.
By April 2026, over 10,000 AI agents had been registered on Ethereum mainnet under ERC-8004 across 16 networks.5 As AINFT deployments accumulate, the lineage tree data embedded in event logs will become an increasingly significant forensic surface.
When to use ERC-8170 vs the alternatives
The ownership standard you choose determines what is architecturally possible after deployment. This is not a styling decision; it becomes a permanent constraint.
| Scenario | Recommended Standard | Reason |
|---|---|---|
| Agent is a product; capabilities are the saleable asset | ERC-7857 | Full state transfer with ZK-verifiable re-encryption; oracle dependency acceptable |
| Agent capabilities are licensable; retain the original while franchising | ERC-8170 | Franchise model, no oracle, original retains reputation |
| Agent is long-running infrastructure; no ownership transfer intended | ERC-8181 | Self-sovereignty via Ouroboros loop; no transfer possible by design |
| Agent is one-of-a-kind; provenance matters for valuation | ERC-8170 originals | Lineage visibility distinguishes authentic from reproduced |
If you are evaluating an existing AINFT before buying, four on-chain checks apply:
- Call
supportsInterface()to confirm ERC-8170 is actually implemented and not just claimed in marketing materials. - Search for
AgentReproducedevents where this token appears aschildTokenId. A non-zeroparentTokenIdmeans you are buying a reproduction, not an original. Generation depth is traceable from there. - Read the
consciousnessSeedfrom the reproduction event. It commits to what the parent knew at the moment of your agent’s creation. Cross-reference with the parent token’s state history if the deployer provides an off-chain URI. - Query the parent token’s ERC-8004 reputation score. The child cannot inherit it, but the parent’s track record tells you the quality of context from which the child was seeded.
None of these checks require off-chain trust. They are function calls and event log queries.
The architectural argument
ERC-8170 makes a specific bet: oracle independence is worth more than ZK-verifiable re-encryption proofs for most agent commerce use cases. The Genesis Contract is the mechanism that makes that bet viable: deterministic, composable, zero external dependencies.
The consciousness seed and lineage tree are what make ERC-8170 interesting beyond key management. Fine-tuned AI models already follow this pattern: you license a base model, fine-tune it for your domain, build your own reputation with your own users. The base model provider retains the original. ERC-8170 formalizes that pattern in a trustless smart contract. The franchise model is not a metaphor borrowed to explain a mechanism. It is the mechanism, translated into on-chain state.
The open questions are real. Evaluator-level reputation inheritance creates a liability gap. No cross-chain lineage standard exists yet, meaning a parent on Base and a child on Arbitrum have no on-chain relationship. Dispute resolution for child agent harm remains unspecified. These are not flaws unique to ERC-8170; they reflect where the agent infrastructure stack stands in mid-2026.
What the standard delivers today is verifiable, oracle-free access revocation and a structured on-chain record of agent lineage. For builders deploying agent capabilities as franchisable products, that is enough to start.
References
1. Liu, I. “ERC-8170: AI-Native NFT (AINFT).” GitHub ERCs, February 21, 2026. https://github.com/ethereum/ERCs/pull/1558
2. Wang, Q., et al. “Autonomous Agents on Blockchains: Standards, Execution Models, and Trust Boundaries.” arXiv, January 2026. https://arxiv.org/abs/2601.04583
3. 0G Labs. “ERC-7857: AI Agents NFT with Private Metadata.” Ethereum Improvement Proposals, 2025. https://eips.ethereum.org/EIPS/eip-7857
4. Brooke, J., Messinger, T. “EIP-6551: Non-fungible Token Bound Accounts.” Ethereum Improvement Proposals, 2023. https://eips.ethereum.org/EIPS/eip-6551
5. Becker, S., et al. “A Dataset of Early Blockchain-Registered AI Agents on Ethereum.” arXiv, April 24, 2026. https://arxiv.org/abs/2604.22652
6. De Rossi, M., Crapis, D., Ellis, J., Reppel, E. “ERC-8004: Trustless Agents.” Ethereum Improvement Proposals, January 2026. https://eips.ethereum.org/EIPS/eip-8004
7. Crapis, D., et al. “ERC-8183: Agentic Commerce.” GitHub ERCs, February 25, 2026. https://github.com/ethereum/ERCs/pull/1581
8. Pentagon Games. “Pentagon Games: Pioneering the Future of Gaming with AI-Powered Experiences.” Medium, 2026. https://medium.com/@PentagonGames/pentagon-games-pioneering-the-future-of-gaming-with-ai-powered-experiences-06453224ca57
