FAQ

What is 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.

Why bind through an adapter instead of registering directly?

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.

Which token standards are supported?

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.

How does wallet binding work?

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.

Why is the initial agentWallet cleared after register?

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.

What powers does the adapter admin have?

The admin has full control over the contract through upgrades. The deployer of the proxy becomes the admin automatically and can upgrade the implementation (UUPS pattern) or change the configured ERC-8004 registry address. Because every upgrade is arbitrary code, the admin can in principle change any contract behavior.

This level of control is necessary for now because ERC-8004 itself is upgradeable. The adapter admin must be able to respond to ERC-8004 upgrades, protocol changes, registry proxy upgrades, or migrations to a new registry contract. Once the spec stabilizes, ownership can be renounced (see “Can the admin rugpull an identity?” below).

Can the admin rugpull an identity?

Yes, in principle. The admin can upgrade the implementation, and a malicious upgrade is arbitrary code, so it could rewrite bindings, seize identities, or bypass controller checks. The current implementation does none of that, but nothing on-chain enforces that behavior across upgrades. The protection is not that the admin lacks the power, it is that you trust the admin not to exercise it.

If that trust assumption is unacceptable for your project, you have two options:

1. Deploy your own adapter. The contract is open-source and there is nothing canonical about the three production proxies. A project that wants its own admin, or a permanently-renounced setup, can deploy the adapter standalone.
2. Wait for the multisig. The plan is to move admin control of the shared production proxies behind a multisig before mainnet usage scales. That replaces single-key rugpull risk with multi-party collusion risk while keeping the upgrade path the spec requires.

Once ERC-8004 itself stabilizes, ownership can be renounced via renounceOwnership(), which permanently locks both upgrades and registry swaps and ends the trust assumption entirely.

What happens if the external token contract is malicious?

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.

How do I audit or test a deployment?

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.

Where can I find more information?