Everything you need to know about the ERC-8004 Identity Adapter
Adapter8004.sol is an upgradeable wrapper contract that lets an external token — ERC-721, ERC-1155, or ERC-6909 — drive an ERC-8004 identity record. The adapter registers the ERC-8004 identity itself, keeps permanent custody of the resulting NFT, and binds the new agentId to the external token. Whoever controls that external token controls the identity.
ERC-8004 ties identity ownership to a single ERC-721-style owner. If you want a multi-holder token (ERC-1155, ERC-6909) or an arbitrary external NFT collection to drive an ERC-8004 record, you need an intermediary that owns the registry slot while forwarding control decisions. That is exactly what this adapter does — it preserves ERC-8004 semantics while delegating control to any token standard you point it at.
ERC-721, ERC-1155, and ERC-6909. For ERC-721 control belongs to ownerOf(tokenId). For ERC-1155 and ERC-6909 control belongs to any account with balanceOf(account, tokenId) > 0, so shared control is preserved instead of being flattened into a synthetic single owner.
setAgentWallet is forwarded to the ERC-8004 registry unchanged, so the wallet-proof rule still applies: newWallet must produce a valid EIP-712 or ERC-1271 signature. The registry enforces the check — the adapter just forwards the call on behalf of the current controller of the bound token.
ERC-8004 sets agentWallet to msg.sender on registration. Because the adapter is the one calling register, it would otherwise inherit that slot. The adapter is only a registry custodian, not the intended runtime wallet, so it immediately calls unsetAgentWallet to clear it.
The deployer of the proxy becomes the admin automatically. The admin can upgrade the implementation (UUPS pattern) and change the configured ERC-8004 registry address. It cannot modify individual bindings, seize identities, or bypass controller checks. The admin role exists to track future ERC-8004 protocol changes — registry proxy upgrades or migrations to a new registry contract.
The admin cannot steal, reassign, or delete bindings. What the admin can do is upgrade the implementation — which, like any UUPS-upgradeable contract, is a trust assumption. If that is unacceptable for your deployment, renounce ownership after initial setup; this permanently locks both upgrades and registry swaps. The tradeoff is that you also lose the ability to migrate to future ERC-8004 registry versions.
The adapter is a trust-forwarder: whoever the token contract says owns the bound tokenId controls the identity. If you bind to a contract that lies about ownerOf or balanceOf, control follows those lies. Mitigations the adapter enforces automatically: reverting tokens propagate the revert, and view-time reentrancy from the token contract is blocked by Solidity's STATICCALL on view functions.
The repository ships with a Foundry test suite covering the full contract surface — unit tests, adversarial tests against malicious token contracts, and fuzz tests for all invariants. Run forge test and forge coverage. See the Quick Start guide for details.