---
title: what a tokenbound account is
canonical_url: https://ensurance.app/guide/what-a-tokenbound-account-is
markdown_url: https://ensurance.app/guide/what-a-tokenbound-account-is.md
subtitle: "an account assigned to an nft you already have, without changing the contract"
category: onchain
---

# what a tokenbound account is

*an account assigned to an nft you already have, without changing the contract*

A token can own an account.

Not a label in someone's database and not a pointer in an app's backend — an address onchain that holds ether, holds tokens, signs messages, and moves what it holds, with the NFT as the only key.

One account that already exists here belongs to a river. [`colorado-river.basin`](/colorado-river.basin?from=guide) is an NFT that stands for a watershed, and it has an account in its own name. That is the reason this machinery is here at all: a watershed, a forest, or a species already exists, and it can have an account in its own name. Whoever holds that NFT signs for it, the same as every other account here. [**ensurance**](/general?from=guide) is how the living system gets funded. The account is only where the funding lands.

A picture you bought in 2021 and never sold can have the same kind of account. The river got one because it needed somewhere to receive. The picture can get one for whatever reason you have.

## what a tokenbound account is

A **tokenbound account** is a smart contract account that an NFT owns — the account the token holds, rather than a wallet that holds the token.

One account, permanently bound to one token. Hold the token and you control the account. Transfer the token and control goes with it, along with whatever the account is holding at that moment.

:::johnson
**your nft can have an account address. it has not been deployed yet.**

For the account implementation this app uses, the address is computed from the contract, the token id, and the chain. You do not mint it, you do not pick it, and the NFT's contract does not change to allow it.

[read the standard →](https://eips.ethereum.org/EIPS/eip-6551)
:::

## the standard, and where it actually stands

This is [ERC-6551](https://eips.ethereum.org/EIPS/eip-6551), "Non-fungible Token Bound Accounts," created February 23, 2023. The abstract is two sentences and worth reading in full:

> "This proposal defines a system which assigns Ethereum accounts to all non-fungible tokens. These token bound accounts allow NFTs to own assets and interact with applications, without requiring changes to existing smart contracts or infrastructure."

"All non-fungible tokens" is carrying real weight in that sentence. Not new ones. Not upgraded ones. All of them, including the one in your wallet right now.

One honest note, because engineers check headers: the EIP page still carries a review banner reading "This EIP is in the process of being peer-reviewed." The status is Review, not Final. The registry is deployed, widely implemented, and behaves the same everywhere it exists — but anyone who tells you the standard is finalized has not looked at the top of the page.

## three properties worth knowing

### the existing contract does not change

The proposal does not extend ERC-721. It adds a registry alongside the token, which means a contract deployed in 2017 by a team that has long since disbanded still gets accounts. The registry does not even run an ERC-165 interface check before creating one, which the EIP explains is deliberate: it keeps the pattern compatible with contracts that predate ERC-721 (CryptoKitties is the example the spec names) and with contracts that implement only part of the interface.

Nobody has to redeploy. Nobody has to find the original developer. There is no migration.

### the address is determined by the token

For a given account implementation, the registry derives the address from the chain id, the contract, and the token id, so you can know the address before anything is deployed. The standard allows more than one account per NFT. This app deploys one. Once that account exists, its address does not move.

The chain id is part of the identity for a reason the EIP states plainly: a token id is unique on one chain, not across chains. Same contract and token id on a different chain is a different account.

### the current holder controls the account

Each account is permanently bound to one NFT, and control of that account is granted to whoever holds the NFT. Not the minter, not the creator, not the deployer of the collection — the holder, right now.

This is the property that makes the whole thing interesting and the property that bites if you ignore it. It means a position can change hands by moving one token. It also means the person holding the token before you could empty the account on the way out. The EIP spends a section on exactly this: Alice deposits 10 ETH into her token's account, Bob bids 11 ETH for the token expecting the balance to come with it, Alice withdraws the 10 ETH and then accepts the bid. The spec's answer is that marketplaces need to commit the account's state or its assets into the order. Until a given marketplace does, check the balance at settlement rather than at listing.

## what the account can do here

Once the account exists, it is a normal onchain account that happens to be keyed by an NFT. In this app, that means it can:

- **Hold tokens** — ether, stablecoins, ensurance coins, other NFTs
- **Swap on Base** — the holder signs, the account trades
- **Carry a purpose and a place** — the identity layer the rest of the protocol reads
- **Run a program on a schedule** — only when the operator account is the one holding the NFT

That last line matters more than it looks. In manual mode you sign every transaction, the same as any wallet you already use. You sign every action while the NFT is in your wallet. A program runs on a schedule only when your operator account holds the NFT.

Never send the NFT into its own account. The standard's own warning is that the token and everything in the account can become unreachable.

## what it is not

**Not a new token.** No mint, no supply, no ticker. An account is infrastructure, not an asset.

**Not a floor revival.** Giving a collection accounts does not create demand for it. An account is a job the object never had; whether anyone values the object more for having one is a separate question, and we are not going to pretend to know the answer.

**Not an automatic payment to a forest.** A swap inside one of these accounts does not route a fee to a watershed. Nature gets funded when someone buys a [coin or a certificate](/general?from=guide), or routes value to an agent that represents a place. Holding a picture with an account attached is not that payment. Pointing the account at a living system is a choice someone makes on purpose.

## where this works today

Base. That is where activation runs in the app right now, and the chain id baked into each account address is Base's. Ethereum mainnet is the next one. No other chain is on the list.

The registry itself is permissionless and does not ask our permission — anyone can create an account for any token. The app is the part that asks: a collection is reviewed once per contract before we treat its tokens as agents, which keeps out spam and tokens that already have a job elsewhere, like a name service record or a liquidity position. The steps are in [how to turn an nft into an agent](/guide/how-to-turn-an-nft-into-an-agent?from=guide).

## frequently asked questions

### what is a tokenbound account?

A smart contract account owned by a single NFT. The account's address is derived from the token's chain, contract, and id, and whoever holds that token controls the account. It can hold assets and transact like any other onchain account.

### do I have to upgrade my nft contract?

No. ERC-6551 does not extend ERC-721 and requires no changes to existing contracts or infrastructure. A registry alongside your contract assigns the account. Contracts that predate ERC-721 can receive one.

### who controls the account?

The current holder of the NFT. Control transfers when the token transfers, and so does everything the account holds — which is why a buyer should verify the balance at settlement, not at listing.

### is erc-6551 final?

No. As of October 2026 the EIP page still shows status Review with a banner saying the proposal is in the process of being peer-reviewed. Deployed and widely used, but not a finalized standard. Anyone claiming otherwise has not read the header.

## see it

If you hold an NFT on Base in a wallet you can connect, [`/agents/mine`](/agents/mine?from=guide) is where it shows up and where activation happens. If you want to see an account that exists because a living system needed somewhere to receive, [`colorado-river.basin`](/colorado-river.basin?from=guide) is live.

## sources

[ERC-6551: Non-fungible Token Bound Accounts](https://eips.ethereum.org/EIPS/eip-6551) — abstract, motivation, chain identifier, backwards compatibility, and fraud prevention. Created 2023-02-23. Status Review as of the page fetch on October 6, 2026.

## the series

- [what an nft agent is](/guide/what-an-nft-agent-is?from=guide) — the definition, and the two origins an agent can have
- [how to turn an nft into an agent](/guide/how-to-turn-an-nft-into-an-agent?from=guide) — the steps, on Base, with the review gate
- [what a tokenbound account is](/guide/what-a-tokenbound-account-is?from=guide) — this post: the standard, cited
- [an nft can be a wallet](/guide/an-nft-can-be-a-wallet?from=guide) — any approved contract, not only the ones we deployed
- [what to do with an nft](/guide/what-to-do-with-an-nft?from=guide) — the objects are still sitting there
- [nfts are dead, long live nfts](/guide/nfts-are-dead-long-live-nfts?from=guide) — the December 2025 essay this series updates
