Ethereum StandardDraft

ERC-6960: Dual-Layer Token Standard

A single token contract that represents both a main asset and fractional shares of that asset. Two layers, one contract.

Adam's role

Co-author. I designed the dual-layer architecture at Polytrade to solve the fractional ownership problem for real-world assets.

What is it?

ERC-6960 lets a single smart contract manage both parent assets and their fractional shares. Layer one (mainId) is the asset itself. Layer two (subId) is a fraction of that asset. No need for separate contracts or complex bridging.

Simple analogy

Imagine a building worth $10M. The mainId is the building itself. The subIds are 10,000 shares worth $1,000 each. One smart contract manages both.

How it works

1

Asset Registration

A new mainId is created representing the parent asset. Metadata (valuation, legal docs, asset type) is attached to this ID.

2

Fraction Creation

SubIds are minted under the mainId. Each subId has its own supply, properties, and transfer rules. A building might have 10,000 subIds each representing 0.01% ownership.

3

Dual-Layer Transfers

Transfers specify both mainId and subId. You're not just sending 'token 42' but 'share 7 of asset 42.' The contract tracks balances across both dimensions.

4

Unified Queries

One contract call tells you everything: what assets exist, what fractions each has, who owns what. No need to query dozens of separate contracts.

Key concepts

Main ID (Layer 1)

The parent asset identifier. This represents the whole thing: a building, a fund, a portfolio. It carries the asset's metadata, valuation, and top-level properties.

Sub ID (Layer 2)

A fraction of the parent asset. Each subId represents a specific share class or ownership slice. Multiple subIds can exist under one mainId, each with its own properties.

Single Contract Architecture

Unlike deploying separate ERC-20 contracts for each fraction, ERC-6960 handles everything in one contract. This reduces gas costs, simplifies management, and makes querying ownership trivial.

ERC-1155 Compatibility

ERC-6960 builds on ERC-1155 patterns. If you've worked with multi-token contracts before, the interface will feel familiar. The innovation is the explicit parent-child relationship between IDs.

Use cases

Fractional Real Estate

One contract manages the property and all its ownership shares.

A commercial property is the mainId. 10,000 fractional shares are subIds. Investors buy and trade subIds while the mainId tracks the property's overall status, valuation, and legal documents.

Multi-Class Fund Shares

Different share classes under one fund, all in one contract.

A venture fund has Class A (voting) and Class B (non-voting) shares. The fund itself is the mainId. Each class is a different subId with its own rules and distribution logic.

Gaming Items with Sub-Properties

A weapon with detachable enchantments, all managed in one contract.

A legendary sword is the mainId. Its enchantments, gems, and upgrades are subIds. Players can trade individual enchantments without trading the whole item.

Technical specification

The core interface that defines ERC-6960.

IERC6960.sol
// SPDX-License-Identifier: MIT
interface IERC6960 {
    // Balance queries — note the dual-layer IDs
    function balanceOf(address account, uint256 mainId, uint256 subId) external view returns (uint256);
    function balanceOfBatch(
        address[] calldata accounts,
        uint256[] calldata mainIds,
        uint256[] calldata subIds
    ) external view returns (uint256[] memory);

    // Transfers with dual-layer addressing
    function safeTransferFrom(
        address from, address to,
        uint256 mainId, uint256 subId,
        uint256 amount, bytes calldata data
    ) external;

    // Approvals
    function setApprovalForAll(address operator, bool approved) external;
    function isApprovedForAll(address account, address operator) external view returns (bool);

    // Events
    event TransferSingle(
        address indexed operator, address indexed from, address indexed to,
        uint256 mainId, uint256 subId, uint256 value
    );
}

Frequently asked questions

Why not just use multiple ERC-20 or ERC-1155 contracts?
You could, but it's expensive and messy. Deploying a new ERC-20 for every fraction of every asset means hundreds of contracts, complex cross-contract calls, and no native parent-child relationship. ERC-6960 gives you a clean, gas-efficient solution in one contract.
How does this compare to ERC-1155?
ERC-1155 has a single token ID dimension. ERC-6960 adds a second dimension. In ERC-1155, token ID 42 is just token 42. In ERC-6960, mainId 42 subId 1 is 'share class 1 of asset 42.' The parent-child relationship is explicit and queryable.
What happens to subIds if the mainId asset is sold?
That's up to the implementation. Common patterns include: burning all subIds and distributing proceeds, converting subIds to a claim on the sale price, or transferring the mainId to a new owner while subId holders retain their fractional rights.
Is ERC-6960 a Final standard?
Not yet. It's currently in Draft status. The specification is being refined based on real-world usage at Polytrade and feedback from the Ethereum community. The core architecture is stable.