ERC-6551 is an Ethereum standard that gives every existing NFT its own smart contract wallet, without changing the NFT or its contract. Each NFT gets a dedicated account that can hold tokens, own other NFTs, and sign transactions — and whoever holds the NFT controls that account. The standard is still under review as an Ethereum proposal, not yet finalized, but the contracts are live and in use across several EVM chains.
The short version: a single on-chain registry turns any NFT into the owner of a wallet, address and all, using the NFT’s contract and token ID as the key. Nothing about the original token needs to be redeployed or upgraded. That one design choice is what makes the standard work with NFTs that were minted years before it existed.
This guide starts with what a token bound account actually is, moves through why earlier NFTs couldn’t do this, and ends with the mechanics, the real projects using it, and the risks worth understanding before you build.
What Is a Token Bound Account?
A token bound account is a smart contract wallet that belongs to a specific NFT rather than to a person. The NFT becomes the owner of the account, and control of the account passes automatically to whoever currently holds that NFT. Sell the NFT, and the new owner inherits everything inside its account.
Think of it as an inversion of the normal relationship. Usually a wallet owns NFTs. Here, an NFT owns a wallet — and through that wallet it can own tokens, hold other NFTs, and interact with applications on its own.
The account isn’t a new kind of token. It’s a standard smart contract account, the same category as the account abstraction wallets Ethereum has been moving toward, except its owner is defined by an NFT instead of a private key. That distinction is the whole point of the standard.
How Is This Different From a Normal NFT?
A normal NFT is a record of ownership and nothing more. It proves you hold token #482 in a collection, but the token itself can’t do anything — it can’t hold funds, can’t sign a message, can’t act. Anything you do “with” an NFT actually happens from your personal wallet.
A token bound account changes that by attaching a functioning wallet to the token. The NFT can now accumulate assets, build an on-chain history that stays with it through every sale, and participate in applications directly. The NFT stops being a static receipt and starts behaving like an actor.
Why NFTs Needed Their Own Wallets
The problem ERC-6551 solves is that NFTs were isolated. An NFT couldn’t hold other assets, couldn’t own a second NFT, and couldn’t interact with a protocol unless the user’s main wallet did it on the token’s behalf. There was no way for the token itself to be a participant.
Earlier attempts at “NFTs that own things” required building custom contracts or modifying the NFT standard, which meant existing collections were left out. Benny Giang, co-founder of Future Primitive and a co-creator of CryptoKitties, described the barrier plainly: keeping an NFT’s activity fully on-chain added complexity and gas costs, and that friction was the main thing holding the idea back, he told Blockworks.
Giang traces the standard back to Sapienz, a project he built with streetwear designer Jeff Staple, where the goal was NFT avatars that could change outfits and own their digital clothing. That use case needed NFTs to hold other NFTs — which is exactly what nothing on Ethereum allowed at the time.
“It’s like giving an NFT a passport,” Giang told Blockworks, describing how the accounts let an NFT reach functions it was previously locked out of, from holding assets to voting.
The elegance of the eventual design is backward compatibility. Because the standard works through an external registry rather than inside the NFT contract, every NFT already on Ethereum mainnet — CryptoKitties included — gained an account address the moment the registry went live. No migration, no reissue.
How the ERC-6551 Registry Works
The system runs on one contract: a permissionless registry that any application can call to create or look up an account for a given NFT. There’s no central operator and no approval step. The registry is the single entry point for the entire standard.
Every account is deployed as a minimal proxy — a tiny contract that forwards its logic to a shared implementation, following the ERC-1167 minimal-proxy pattern. This keeps per-account deployment cheap, since each NFT doesn’t need a full copy of the wallet code.
The account’s address is derived deterministically from four inputs: the account implementation, a salt, the chain ID, the NFT’s contract address, and its token ID. Because the registry uses Ethereum’s CREATE2 opcode, that address can be calculated in advance and is always the same for the same NFT. An application can show an NFT’s account address before the account is even deployed.
What Address Is the Registry Deployed At?
The registry lives at the same address on every supported EVM network: 0x000000006551c19487814612e58FE06813775758. It’s deployed deterministically so that Ethereum, Polygon, Optimism, Base, and other chains all expose the identical contract at the identical address.
That consistency matters for multi-chain apps. A developer calling the registry doesn’t need per-chain configuration for the contract itself — the same call works wherever the registry has been deployed.
Two functions carry most of the weight. createAccount deploys the account for a given NFT and returns its address, or simply returns the existing address if the account already exists. account is a read-only view that computes the same address without deploying anything, which is how interfaces display an account before it’s active.
What Can the Account Actually Do?
The account implementation defines the token’s capabilities, and the standard sets a baseline every implementation must meet. Each account has to report which NFT it’s bound to through a token() function whose answer never changes, accept Ether, and validate signatures using the ERC-1271 standard so contracts can verify the account signed something.
Signing authority is handled through an isValidSigner check. By default the current NFT holder is the valid signer, and implementations can expand or restrict that — adding session keys, for example, or requiring a multisig.
Most implementations also expose an execution function that lets the authorized signer run arbitrary operations from the account: sending funds, calling another contract, approving a token. The exact method set is left to the implementation, which is why two token bound accounts can offer different features while both following the standard.
Who Is Building on ERC-6551?
The standard appeals to anyone who wants an NFT to carry assets or state, not just prove ownership. Gaming, identity, and composable collectibles are the clearest early categories, and most production use runs through Tokenbound, the main suite of open-source tools and the reference account implementation for the standard.
The pattern shows up across a few distinct use cases:
- Games give a character NFT its own inventory, so weapons, currency, and cosmetics live inside the character and transfer with it when the character is sold.
- PFP and avatar projects let a profile-picture NFT own its accessories — the Sapienz “change your outfit” idea — instead of tracking them in a separate database.
- On-chain identity and reputation accrue to the NFT itself: badges, credentials, and transaction history that stay attached through every transfer.
- Bundling and vaults use one NFT as a container for a whole portfolio, so selling the NFT transfers everything in its account in a single transaction.
- Subscriptions and memberships attach benefits or balances to a membership token that functions as a wallet in its own right.
For developers, interacting with these accounts means ordinary on-chain reads and writes — deriving the account address, checking its balance, broadcasting the signed execution call. That traffic is standard JSON-RPC, so it can route through a self-run node or a provider such as NOWNodes, which offers Ethereum RPC access alongside 120-plus other networks, including the EVM chains where the registry is deployed.
ERC-6551 vs. Ordinary NFT Standards
ERC-6551 doesn’t replace the standards that define NFTs — it layers on top of them. An NFT is still an ERC-721 or ERC-1155 token; ERC-6551 only adds a wallet that token can control. The table below shows where the line falls.
| Capability | ERC-721 / ERC-1155 NFT | NFT with ERC-6551 account |
|---|---|---|
| Proves ownership of an item | Yes | Yes |
| Holds other tokens or NFTs | No | Yes, in its account |
| Signs transactions or messages | No | Yes, via the current holder |
| Builds history that survives a sale | Limited | Yes, inside the account |
| Requires changing the NFT contract | — | No |
| Works with NFTs minted before the standard | — | Yes |
The key row is the last one. Because the account is created and controlled externally, the standard reaches backward to every NFT that already exists, which is unusual for an Ethereum extension.
The Trade-offs and Risks to Know
Token bound accounts add power, and with it some new ways to lose money. The most-cited risk is the one that comes from the feature itself: if an NFT’s account holds valuable assets, selling or transferring that NFT hands those assets to the buyer along with it. The account and its contents follow the token, so a careless transfer can give away far more than the NFT alone.
Nested ownership creates a second hazard. An NFT can own an account that owns another NFT that owns a third account, and so on. Deep chains like this are hard for people to reason about and have raised questions about recursion and gas in edge cases, which is partly why the standard is still under review rather than final.
There’s also a tooling gap. Wallets and marketplaces don’t all display what an NFT’s account holds, so buyers can’t always see the full picture before a purchase. And because the standard is a proposal under peer review, details of the account interface can still shift — worth factoring in before committing a production system to a specific implementation.
A related extension, ERC-7656, generalizes the registry idea so that accounts and other linked contracts can be bound to any token, not only NFTs. It signals where the pattern is heading, but it’s a separate, newer proposal rather than part of ERC-6551 itself.
Conclusion
ERC-6551 reframes what an NFT can be. Instead of a static proof of ownership, an NFT becomes something that can hold assets, carry a history, and act on-chain — all through a wallet the token itself controls, with control passing cleanly to each new holder. The design’s quiet strength is that it asked nothing of existing NFTs to do it.
If you’re building with it, start small and deliberate. Derive an account address, move a test asset through it, and confirm your marketplace or wallet surfaces what the account holds before you ship anything that depends on it. The standard is capable, but it’s still maturing, and the risks concentrate exactly where the new power is — in what an NFT’s account quietly carries from one owner to the next.
FAQ
Is ERC-6551 a finalized Ethereum standard?
No. As of this writing it’s an Ethereum proposal under peer review, not a finalized standard. The contracts are deployed and functional, but the specification can still change, so build with that in mind.
Do I need to redeploy my NFT to use a token bound account?
No. The registry works entirely outside the NFT contract, so any existing NFT — including ones minted long before the standard — can have an account created for it without any change to the original token.
What happens to the account’s assets when the NFT is sold?
They transfer with the NFT. Control of the account follows whoever holds the token, so the buyer gains access to everything the account holds. This is intended behavior, and it’s the main thing to check before transferring an NFT with a funded account.
Can a token bound account exist before it’s deployed?
Yes. The account’s address is calculated deterministically from the NFT’s details, so applications can display and reference that address before the account is ever deployed on-chain. Deployment happens the first time someone calls createAccount.
Which blockchains support ERC-6551?
The registry is deployed at the same address across multiple EVM-compatible chains, including Ethereum, Polygon, Optimism, and Base. On networks where it isn’t already deployed, the contracts can be deployed deterministically to the same address.
