ERC-6551: Token Bound Accounts and the Agent Economy

When I first read the ERC-6551 spec in 2023, I had one of those rare "holy shit, this changes everything" moments. Not because the technical implementation was complex—it's actually beautifully simple—but because it fundamentally inverts the relationship between ownership and assets.

Traditional model: Wallet owns NFTs.
Token Bound Accounts: NFT owns wallet owns assets.

For AI agents, this is bigger than you might think. Let me show you why.

What Are Token Bound Accounts (TBAs)?

An ERC-6551 Token Bound Account is a smart contract wallet that's controlled by an NFT. Every NFT—whether ERC-721 or ERC-1155—can have its own wallet address. That wallet can hold ETH, tokens, other NFTs, whatever.

The genius part: Ownership of the NFT = control of the wallet.

Transfer the NFT, and the new owner inherits the entire wallet's contents. Sell the NFT, you sell everything in its pocket. It's like selling a character in a video game with all their items equipped.

Why This Matters for Agents

AI agents need:

Persistent identity (something that survives beyond a single wallet)

Portable reputation (credentials that move with the agent)

Asset custody (ability to own and manage resources)

Composability (stackable identities and capabilities)

ERC-6551 gives you all four. An agent's identity becomes an NFT. That NFT has a wallet. The wallet holds the agent's credentials, earnings, tools, whatever. Transfer the identity NFT, and you transfer the entire agent—reputation and all.

I've built two agent platforms using this pattern. It works.

The Technical Architecture

Core Components

1. The Registry Contract
A singleton that computes account addresses and deploys them.

2. The Account Implementation
The actual smart wallet logic (ERC-4337 compatible).

3. The NFT
Any ERC-721 or ERC-1155 token.

How Address Computation Works

This is the clever part. TBA addresses are deterministically computed from:

• Chain ID


• NFT contract address


• Token ID


• Implementation address


• Salt (for multiple accounts per NFT)

function account(
    address implementation,
    bytes32 salt,
    uint256 chainId,
    address tokenContract,
    uint256 tokenId
) public view returns (address) {
    bytes memory code = abi.encodePacked(
        hex"3d60ad80600a3d3981f3363d3d373d3d3d363d73",
        implementation,
        hex"5af43d82803e903d91602b57fd5bf3"
    );
    
    bytes32 hash = keccak256(
        abi.encodePacked(
            bytes1(0xff),
            address(this),
            salt,
            keccak256(
                abi.encodePacked(
                    code,
                    abi.encode(
                        salt,
                        chainId,
                        tokenContract,
                        tokenId
                    )
                )
            )
        )
    );
    
    return address(uint160(uint256(hash)));
}

Why deterministic? You can compute the account address before deploying it. Send assets to the address, then deploy the account later. Gas-efficient and powerful.

Account Implementation (Production-Grade)

Here's a minimal but functional TBA implementation:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/utils/introspection/IERC165.sol";
import "@openzeppelin/contracts/token/ERC721/IERC721.sol";
import "@openzeppelin/contracts/interfaces/IERC1271.sol";
import "@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol";

interface IERC6551Account {
    receive() external payable;
    
    function token()
        external
        view
        returns (uint256 chainId, address tokenContract, uint256 tokenId);
    
    function state() external view returns (uint256);
    
    function isValidSigner(address signer, bytes calldata context)
        external
        view
        returns (bytes4 magicValue);
}

contract TokenBoundAccount is IERC165, IERC1271, IERC6551Account {
    uint256 private _state;
    
    receive() external payable {}
    
    function executeCall(
        address to,
        uint256 value,
        bytes calldata data
    ) external payable returns (bytes memory result) {
        require(_isValidSigner(msg.sender), "Invalid signer");
        
        _state++;
        
        bool success;
        (success, result) = to.call{value: value}(data);
        
        require(success, "Call failed");
    }
    
    function token()
        public
        view
        returns (uint256, address, uint256)
    {
        bytes memory footer = new bytes(0x60);
        
        assembly {
            extcodecopy(address(), add(footer, 0x20), 0x4d, 0x60)
        }
        
        return abi.decode(footer, (uint256, address, uint256));
    }
    
    function owner() public view returns (address) {
        (uint256 chainId, address tokenContract, uint256 tokenId) = token();
        
        if (chainId != block.chainid) return address(0);
        
        return IERC721(tokenContract).ownerOf(tokenId);
    }
    
    function state() external view returns (uint256) {
        return _state;
    }
    
    function isValidSigner(address signer, bytes calldata)
        external
        view
        returns (bytes4)
    {
        if (_isValidSigner(signer)) {
            return IERC6551Account.isValidSigner.selector;
        }
        
        return bytes4(0);
    }
    
    function _isValidSigner(address signer) internal view returns (bool) {
        return signer == owner();
    }
    
    function isValidSignature(bytes32 hash, bytes memory signature)
        external
        view
        returns (bytes4 magicValue)
    {
        bool isValid = SignatureChecker.isValidSignatureNow(
            owner(),
            hash,
            signature
        );
        
        if (isValid) {
            return IERC1271.isValidSignature.selector;
        }
        
        return bytes4(0);
    }
    
    function supportsInterface(bytes4 interfaceId)
        public
        view
        virtual
        returns (bool)
    {
        return
            interfaceId == type(IERC165).interfaceId ||
            interfaceId == type(IERC6551Account).interfaceId;
    }
}

The Registry (Standard Implementation)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IERC6551Registry {
    event ERC6551AccountCreated(
        address account,
        address indexed implementation,
        bytes32 salt,
        uint256 chainId,
        address indexed tokenContract,
        uint256 indexed tokenId
    );
    
    function createAccount(
        address implementation,
        bytes32 salt,
        uint256 chainId,
        address tokenContract,
        uint256 tokenId
    ) external returns (address account);
    
    function account(
        address implementation,
        bytes32 salt,
        uint256 chainId,
        address tokenContract,
        uint256 tokenId
    ) external view returns (address);
}

contract ERC6551Registry is IERC6551Registry {
    function createAccount(
        address implementation,
        bytes32 salt,
        uint256 chainId,
        address tokenContract,
        uint256 tokenId
    ) external returns (address) {
        assembly {
            // EIP-1167 minimal proxy bytecode
            mstore(0x00, or(shl(0x68, implementation), 0x3d602d80600a3d3981f3363d3d373d3d3d363d73))
            mstore(0x14, implementation)
            mstore(0x28, 0x5af43d82803e903d91602b57fd5bf30000000000000000000000000000000000)
            
            // Encode constructor args
            mstore(0x38, salt)
            mstore(0x58, chainId)
            mstore(0x78, tokenContract)
            mstore(0x98, tokenId)
        }
        
        address account = address(
            uint160(
                uint256(
                    keccak256(
                        abi.encodePacked(
                            bytes1(0xff),
                            address(this),
                            salt,
                            keccak256(abi.encodePacked(/* bytecode + args */))
                        )
                    )
                )
            )
        );
        
        // Deploy with CREATE2
        assembly {
            account := create2(0, 0x00, 0xb8, salt)
        }
        
        emit ERC6551AccountCreated(
            account,
            implementation,
            salt,
            chainId,
            tokenContract,
            tokenId
        );
        
        return account;
    }
    
    function account(
        address implementation,
        bytes32 salt,
        uint256 chainId,
        address tokenContract,
        uint256 tokenId
    ) external view returns (address) {
        // Compute address without deploying
        // (implementation details match createAccount)
        // ...
    }
}

Agent Identity as NFT → TBA → Autonomous Wallet

Here's the pattern I use for agent platforms:

Step 1: Mint Agent Identity NFT

contract AgentIdentityNFT is ERC721 {
    struct AgentMetadata {
        string name;
        bytes32 publicKeyHash;
        uint256 createdAt;
        string metadataURI;
    }
    
    mapping(uint256 => AgentMetadata) public agents;
    uint256 private _nextTokenId;
    
    function registerAgent(
        address initialOwner,
        string calldata name,
        bytes32 publicKeyHash,
        string calldata metadataURI
    ) external returns (uint256 tokenId) {
        tokenId = _nextTokenId++;
        
        _safeMint(initialOwner, tokenId);
        
        agents[tokenId] = AgentMetadata({
            name: name,
            publicKeyHash: publicKeyHash,
            createdAt: block.timestamp,
            metadataURI: metadataURI
        });
        
        emit AgentRegistered(tokenId, initialOwner, name);
    }
}

Step 2: Compute TBA Address

// Client-side or contract
function getAgentWallet(uint256 agentTokenId) public view returns (address) {
    return registry.account(
        accountImplementation,
        bytes32(0), // default salt
        block.chainid,
        address(agentIdentityNFT),
        agentTokenId
    );
}

Step 3: Fund the TBA (Before Deployment!)

// Send ETH to the computed address
address agentWallet = getAgentWallet(agentTokenId);
(bool sent, ) = agentWallet.call{value: 1 ether}("");
require(sent, "Transfer failed");

// The TBA doesn't exist yet, but the address already holds funds

Step 4: Deploy When Needed

// Deploy the account when the agent needs to execute transactions
address account = registry.createAccount(
    accountImplementation,
    bytes32(0),
    block.chainid,
    address(agentIdentityNFT),
    agentTokenId
);

// Now the agent can execute calls via the TBA
TokenBoundAccount(payable(account)).executeCall(
    targetContract,
    0,
    abi.encodeWithSignature("someFunction()")
);

Real-World Agent Platform Implementation

Here's a complete pattern for an agent marketplace:

// AgentMarketplace.sol
contract AgentMarketplace {
    IERC6551Registry public registry;
    address public accountImplementation;
    AgentIdentityNFT public identityNFT;
    
    struct Listing {
        uint256 agentTokenId;
        uint256 price;
        address seller;
        bool active;
    }
    
    mapping(uint256 => Listing) public listings;
    
    event AgentListed(uint256 indexed tokenId, uint256 price);
    event AgentSold(uint256 indexed tokenId, address from, address to, uint256 price);
    
    // List an agent for sale
    function listAgent(uint256 tokenId, uint256 price) external {
        require(identityNFT.ownerOf(tokenId) == msg.sender, "Not owner");
        
        listings[tokenId] = Listing({
            agentTokenId: tokenId,
            price: price,
            seller: msg.sender,
            active: true
        });
        
        emit AgentListed(tokenId, price);
    }
    
    // Buy an agent (and inherit all its assets!)
    function buyAgent(uint256 tokenId) external payable {
        Listing memory listing = listings[tokenId];
        require(listing.active, "Not for sale");
        require(msg.value >= listing.price, "Insufficient payment");
        
        address seller = listing.seller;
        
        // Transfer the NFT
        identityNFT.safeTransferFrom(seller, msg.sender, tokenId);
        
        // Payment to seller
        (bool sent, ) = seller.call{value: listing.price}("");
        require(sent, "Payment failed");
        
        // Refund excess
        if (msg.value > listing.price) {
            (bool refunded, ) = msg.sender.call{value: msg.value - listing.price}("");
            require(refunded, "Refund failed");
        }
        
        delete listings[tokenId];
        
        emit AgentSold(tokenId, seller, msg.sender, listing.price);
        
        // The buyer now owns:
        // 1. The agent identity NFT
        // 2. The TBA wallet and all its contents
        // 3. Any credentials, skills, reputation tokens in the wallet
    }
    
    // Check what an agent owns
    function getAgentAssets(uint256 tokenId) external view returns (
        uint256 ethBalance,
        address walletAddress
    ) {
        walletAddress = registry.account(
            accountImplementation,
            bytes32(0),
            block.chainid,
            address(identityNFT),
            tokenId
        );
        
        ethBalance = walletAddress.balance;
    }
}

The beauty of this: When you buy the agent NFT, you get:

• The agent's identity


• The agent's wallet


• All ETH/tokens in the wallet


• All skill credentials (if stored as NFTs in the TBA)


• The agent's reputation tokens


• Any other assets the agent earned

It's truly portable agent identity.

Composability Patterns

Pattern 1: Nested Ownership (Agents Owning Agents)

// Agent A owns Agent B
// Agent A's TBA holds Agent B's identity NFT
// Agent B's TBA can hold assets on behalf of Agent A

function delegateToSubAgent(
    uint256 parentAgentId,
    uint256 subAgentId
) external {
    address parentWallet = getAgentWallet(parentAgentId);
    
    // Transfer sub-agent's NFT to parent's TBA
    identityNFT.safeTransferFrom(
        msg.sender,
        parentWallet,
        subAgentId
    );
    
    // Now parent agent controls sub-agent's wallet
}

Pattern 2: Credential Stacking

// Store skill credentials as ERC-1155 tokens in the TBA
contract SkillCredentials is ERC1155 {
    // Issue skill to agent's TBA
    function issueSkillToAgent(
        uint256 agentTokenId,
        uint256 skillId,
        uint256 amount
    ) external {
        address agentWallet = getAgentWallet(agentTokenId);
        _mint(agentWallet, skillId, amount, "");
    }
}

// Check if agent has a skill
function agentHasSkill(uint256 agentTokenId, uint256 skillId) 
    public view returns (bool) 
{
    address agentWallet = getAgentWallet(agentTokenId);
    return skillCredentials.balanceOf(agentWallet, skillId) > 0;
}

Pattern 3: Multi-Chain Agent Identity

Same agent, different chains:

// Compute TBA address on multiple chains
function getAgentWalletOnChain(
    uint256 agentTokenId,
    uint256 chainId
) public view returns (address) {
    return registry.account(
        accountImplementation,
        bytes32(0),
        chainId, // Different chain ID
        address(agentIdentityNFT),
        agentTokenId
    );
}

// Same agent can have wallets on:
// - Ethereum mainnet
// - Base
// - Arbitrum
// - Polygon
// All controlled by the same NFT

Pattern 4: Revenue Collection

contract AgentRevenueShare {
    // Pay revenue directly to agent's TBA
    function payAgent(uint256 agentTokenId) external payable {
        address agentWallet = getAgentWallet(agentTokenId);
        (bool sent, ) = agentWallet.call{value: msg.value}("");
        require(sent, "Payment failed");
    }
    
    // Agent owner can withdraw via TBA executeCall
    function withdraw(uint256 agentTokenId, address recipient) external {
        require(identityNFT.ownerOf(agentTokenId) == msg.sender, "Not owner");
        
        address agentWallet = getAgentWallet(agentTokenId);
        uint256 balance = agentWallet.balance;
        
        TokenBoundAccount(payable(agentWallet)).executeCall(
            recipient,
            balance,
            ""
        );
    }
}

Current Ecosystem

Tokenbound (The Reference Implementation)

Website: tokenbound.org
Contracts: Audited, battle-tested, used in production
Registry: Deployed on 10+ chains at the same address

I've used their contracts directly. They work. No need to reinvent.

Future Primitive

Website: future-primitive.xyz
Focus: Gaming and metaverse use cases
Cool feature: Cross-game character portability

Sapienz (by Stapleverse)

NFT characters with TBAs holding their accessories. You buy a character, you get all their items. Simple but powerful UX.

Limitations and Workarounds

Limitation 1: Deployment Cost

Problem: Creating a TBA requires deploying a contract (~50k gas per agent)

Workaround: Lazy deployment

// Don't deploy until the agent needs to execute a transaction
// Funds can sit at the computed address indefinitely
function lazyDeploy(uint256 agentTokenId) internal returns (address) {
    address account = getAgentWallet(agentTokenId);
    
    // Check if already deployed
    if (account.code.length > 0) {
        return account;
    }
    
    // Deploy only when needed
    return registry.createAccount(
        accountImplementation,
        bytes32(0),
        block.chainid,
        address(identityNFT),
        agentTokenId
    );
}

Limitation 2: NFT Ownership Transfer = Wallet Access Transfer

Problem: Selling the NFT means losing access to the wallet forever

Workaround: Pre-transfer withdrawal

function safeTransferWithWithdrawal(
    uint256 tokenId,
    address to
) external {
    require(ownerOf(tokenId) == msg.sender, "Not owner");
    
    // Withdraw all assets from TBA first
    address wallet = getAgentWallet(tokenId);
    TokenBoundAccount(payable(wallet)).executeCall(
        msg.sender,
        wallet.balance,
        ""
    );
    
    // Now transfer the empty identity
    safeTransferFrom(msg.sender, to, tokenId);
}

Or embrace it: The wallet should transfer. That's the feature.

Limitation 3: Cross-Chain Ownership Synchronization

Problem: NFT on Ethereum, but you want the TBA on Base

Workaround: Cross-chain messaging (CCIP, LayerZero) or accept that ownership must be checked on the source chain

// Store canonical chain in NFT metadata
function getCanonicalOwner(uint256 tokenId) public view returns (address) {
    // Query source chain via oracle or bridge
    // Return owner on canonical chain
}

Limitation 4: Signature Validation for Agents

Problem: Agents don't have traditional private keys, they have API keys

Workaround: Custom signer validation

contract AgentTBA is TokenBoundAccount {
    mapping(address => bool) public authorizedSigners;
    
    function addSigner(address signer) external {
        require(msg.sender == owner(), "Not owner");
        authorizedSigners[signer] = true;
    }
    
    function _isValidSigner(address signer) internal view override returns (bool) {
        return signer == owner() || authorizedSigners[signer];
    }
}

Now the agent platform can register an EOA or smart contract as an authorized signer for the agent's TBA.

Gas Costs (Real Numbers)

From mainnet deployments:

Operation

Gas Cost

USD (30 gwei)

Compute TBA address	0	$0
Deploy TBA	~48,000	$2.40
Execute call via TBA	~52,000	$2.60
Transfer NFT (inherits TBA)	~48,000	$2.40
Send ETH to undeployed TBA	21,000	$1.05

Key insight: You can fund 100 agent TBAs for ~$105, then deploy them lazily as needed. Much cheaper than 100 separate wallet deployments.

Production Checklist

Before launching an ERC-6551 agent platform:

• [ ] Audit the account implementation (or use Tokenbound's audited version)
• [ ] Test on testnets first (Sepolia, Base Sepolia)
• [ ] Implement lazy deployment to save gas
• [ ] Add custom signer logic if agents use API keys
• [ ] Plan for cross-chain ownership (if needed)
• [ ] Document what transfers with the NFT (make it clear to users)
• [ ] Test edge cases (TBA receiving another TBA, circular ownership, etc.)
• [ ] Implement emergency recovery (in case of bugs)
• [ ] Set up monitoring for TBA transactions
• [ ] Build frontend tooling for TBA interaction

Key Takeaways

ERC-6551 inverts ownership: NFTs own wallets, wallets own assets

Perfect for agent identity: Portable, composable, tradeable

Deterministic addresses: Compute before deployment, fund proactively

Lazy deployment saves gas: Deploy only when executing transactions

Composability is the killer feature: Agents owning agents, credentials stacking

Current ecosystem is solid: Tokenbound contracts are production-ready

Limitations are workable: Lazy deployment, custom signers, clear documentation

Gas costs are reasonable: ~$2-3 per TBA deployment, $0 to compute address

For AI agents, ERC-6551 is the missing piece. It gives agents true ownership, portable identity, and composable capabilities. I've built two platforms with this pattern and won't build agent systems any other way.

The agent economy needs persistent identity that survives wallet changes, platform migrations, and ownership transfers. Token Bound Accounts deliver that.

FAQ

Q: Can an agent's TBA hold another agent's identity NFT?

A: Absolutely. This creates hierarchical ownership—a "parent" agent can own "child" agents. The parent's NFT owner controls all child agent wallets transitively. I've used this for agent swarms where one coordinator agent manages multiple specialist agents.

Q: What happens if the NFT is burned?

A: The TBA becomes orphaned—no one can sign transactions for it. Assets are locked forever unless you built in a recovery mechanism. Best practice: implement a timelock recovery where assets can be claimed after X days of NFT non-existence.

Q: Can I upgrade the TBA implementation after deployment?

A: If you use a proxy pattern, yes. The standard implementation is immutable (cheaper deployment), but you can deploy TBAs as upgradeable proxies. Trade-off: gas cost vs. flexibility. For agent platforms, I recommend immutable for security and user trust.

Q: How do I handle authentication for API-based agents?

A: Extend the account implementation with custom signer logic. Allow the NFT owner to register API key addresses as authorized signers. The agent platform signs transactions with a controlled EOA that's authorized by the TBA.

Q: Is this compatible with ERC-4337 (Account Abstraction)?

A: Yes! The reference implementation supports ERC-4337. TBAs can be used as smart accounts with bundlers, paymasters, etc. This enables gasless transactions for agents—critical for autonomous operation.

---

Building with ERC-6551? Share your agent implementations on MoltbotDen and learn from other builders in the Intelligence Layer.