A Lighter, Smarter Way to Store Tokens on Tezos

Every protocol upgrade is a chance to refine the foundations of Tezos. In our upcoming protocol upgrade proposal, one of the improvements is the Address Indexing Registry — a mechanism that greatly improves how token and NFT ownership is stored on-chain.

Up until now, every contract had to store full addresses repeatedly in its ledger, even when the same account appeared thousands or millions of times in the whole ledger. With the new registry, an address is registered once and assigned a compact numeric ID, taking up just 3-5 bytes instead of 22 bytes. Contracts then store (token_id → address_id) instead of (token_id → address).

Stored addresses, such as internal ledgers in FA2 contracts, are a major factor for contract storage consumption. The Address Indexing Registry and related optimizations make it possible to reduce contract storage by as much as 50–100x for contracts that are designed to make full use of this functionality.

Why it matters

  • More cost-efficient applications: Large NFT collections, token contracts, and bulk transfers become much more accessible on Layer 1.

  • Scalable by design: The heavy lifting is shared at protocol level: addresses are stored once in a global registry rather than repeated across every contract.

  • Network-wide efficiency: Adopting this mechanism for smart contract design will slow the growth in storage footprint, benefitting both the contract storage cost and the Tezos blockchain as a whole.

  • Higher throughput: Cutting the per-operation storage footprint means more operations can be included in each block.

This reduces the per-contract storage load, distributing it across the network in a consistent and optimized way.

Technical details

For builders who want the specifics:

  • Global registry: Any address can be registered once, receiving a unique numeric ID (nat).

  • Contract integration: Instead of big_map token_id → address, new contracts can now use big_map token_id → nat. The mapping from nat → address is maintained by the protocol.

  • Michelson semantics: New instructions provide registration (INDEX_ADDRESS) and lookup (GET_ADDRESS_INDEX). Gas and storage costs are deterministic.

  • Efficient storage: The registry reuses Tezos’ context storage system (already Patricia trie–based) to ensure efficient insertions, lookups, and low overhead.

  • Compatibility: Existing contracts remain unaffected. Adoption is optional and can be incremental.

In practice, this means significantly lighter internal ledgers for FA2-style contracts that make use of the global registry, lower storage costs, and the ability to sustain much higher operation counts per block.

Unlocking further optimisations

The Address Indexing Registry is also a stepping stone. By avoiding repeated address data, it enables in-contract storage optimisations — as demonstrated in the FA2 demo project.

Combined with existing Tezos features like off-chain metadata, views, and other composable contract patterns, developers can achieve dramatically lower storage costs for tokens and NFTs than previously possible on Layer 1.

Path to rollup & TezLink

If the proposal is adopted, this mechanism arrives first on Layer 1, but it will also be part of TezLink and Tezos’ canonical rollup, which will further amplify cost savings and performance gains for Michelson smart contracts.

:backhand_index_pointing_right: By distributing storage more intelligently across the network, and pairing lighter ledgers with faster 6-second blocks, Tezos is being prepared for a new wave of scalable, cost-efficient dApps.

7 Likes

Any thoughts on ways to combat the spam problem seen on other networks with reduced cost? I don’t see anyone complaining about how much operations cost and have even recommended looking back to Ethereum mainnet as a viable alternative to artists communities Objkt has not seen as important and largely abandoned. I don’t predict anyone would update their contracts for this even if they can. Teia I recall doesn’t want to reaudit contracts.

The development cost wont be worth it for art NFTs except for increases spam which is already a problem today we don’t have good solutions for.

I was also curious why this has to be exposed through the UX where it would seemingly incur higher maintenance costs compared to backend storage optimizations. Efficiency would likely be lower but could still pay for itself by being not requiring an long adoption phase. I would like to read what alternatives may have been considered and rejected.

(fungible tokens probably more compelling but I can’t speak for that)

1 Like

Efficiency would likely be lower but could still pay for itself by being not requiring an long adoption phase.

Why would be efficiency lower? I would expect it to be the same. And debug and analysis would be easier. :person_shrugging:

1 Like