What is ERC-6551?
NFTs with accounts attached - powerful, but another account layer.
ERC-6551 gives an NFT an account. That one move unlocks game inventories, composable avatars, NFT-owned assets, and agent-like behavior tied to a token.
on this page
The standard, in one card.
- Standard
- ERC-6551 / EIP-6551
- Status
- Review on eips.ethereum.org
- Core idea
- token-bound accounts
- Primary asset
- ERC-721 NFTs
The origin story.#
ERC-721 made tokens ownable, but it did not make tokens capable of owning other assets or calling contracts. ERC-6551 adds that missing account layer without changing existing ERC-721 contracts.
What ERC-6551 actually is.#
interface IERC6551Registry {
function createAccount(
address implementation,
bytes32 salt,
uint256 chainId,
address tokenContract,
uint256 tokenId
) external returns (address);
function account(
address implementation,
bytes32 salt,
uint256 chainId,
address tokenContract,
uint256 tokenId
) external view returns (address);
}
createAccount · account chainId · tokenContract · tokenId execute · owner from NFT A registry computes or deploys an account address from an implementation, salt, chain ID, token contract, and token ID. The account implementation can then use the NFT's owner as its authority source.
What's broken about ERC-6551.#
The model is powerful but easy to misunderstand. If the account is controlled by NFT ownership, then transferring the NFT can transfer control of the account and whatever the account holds.
-
The account is bound to NFT ownership.#
Control of the token-bound account follows ownership of the NFT. That is powerful for composability, but it can be surprising when selling or transferring the NFT also transfers control of everything the account owns.
ERC-6551NFT owns accountLSP0account owns assetsworkarounds tried- clear wallet UI
- inventory warnings
- pre-transfer checks
- asset sweeping
-
It adds registry and implementation complexity.#
The address is derived from registry inputs and an implementation contract. Integrators need to reason about the registry, implementation, salt, chain ID, token contract, token ID, and account behavior.
ERC-6551registry.account(...)Universal Profileaccount addressworkarounds tried- canonical registry
- audited account implementations
- SDKs
-
It does not fix ERC-721 metadata or approvals.#
The NFT that controls the account is still an ERC-721. tokenURI, setApprovalForAll, safeTransferFrom, and uint256 token ID limits remain unless other standards or custom logic address them.
ERC-721 + 6551token-bound accountLSP8 + LSP0asset and account standardsworkarounds tried- ERC-4906
- ERC-2981
- transfer warnings
- custom metadata
LUKSO designed it differently.#
LUKSO starts with the account. A Universal Profile owns assets, exposes profile metadata, and delegates permissions through LSP6. ERC-6551 recreates an account under an NFT; LSP0 makes the account the primary object.
ERC-6551 vs LSP0 in one table.#
| row | ERC-6551 | LSP0 |
|---|---|---|
| account relation | account bound to an NFT | account is first-class |
| ownership | follows ERC-721 owner | managed by account ownership/permissions |
| asset composition | NFT can own assets via account | Universal Profile owns assets directly |
| metadata | still ERC-721 tokenURI unless extended | LSP3/LSP4 typed metadata |
FAQ.#
-
What is a token-bound account? #
A token-bound account is a smart contract account associated with a specific NFT. Whoever owns the NFT controls the associated account under the implementation's rules.
-
Is ERC-6551 final? #
As of June 26, 2026, the EIP page lists ERC-6551 with Review status, so teams should verify current status before treating it as finalized.
-
What happens when an ERC-6551 NFT is sold? #
Control of the token-bound account generally follows ownership of the NFT, so assets held by that account may effectively move under the buyer's control unless handled before transfer.