ERC-6960: Dual-Layer Token Standard
ERC-6960 is a Draft token interface with two identifiers: mainId for an asset category and subId for a class or variation within it.
ADAM'S ROLE
First author (1 of 6). I designed the dual-layer architecture at Polytrade to solve the fractional ownership problem for real-world assets.
What is it?
ERC-6960 tracks balances by account, mainId and subId. A subId identifies a token class or variation, and an amount records the units held. This can represent fractional assets without making each unit a separate token identifier.
SIMPLE ANALOGY
Illustrative mapping: mainId 42 identifies a property-related asset, subId 1 identifies its ordinary share class, and a balance of 100 means 100 units of that class. The IDs do not establish legal ownership or a price.
How it works
Asset Registration
A new mainId is created representing the parent asset. Metadata (valuation, legal docs, asset type) is attached to this ID.
Fraction Creation
Define the token subtypes under each mainId, then mint amounts of those types. A share class can have 10,000 fungible units under one subId; it does not need 10,000 subIds.
Dual-Layer Transfers
Transfers specify mainId, subId and amount: for example, 100 units of share class 7 under asset category 42. The contract tracks each account’s balance for that identifier pair.
Unified Queries
Query balances for known accounts and (mainId, subId) pairs. Listing all assets or holders still requires an indexer or additional enumeration logic.
Key concepts
Main ID (Layer 1)
The main asset type identifier. An application can associate it with an asset and metadata; valuation and legal records are application responsibilities.
Sub ID (Layer 2)
A subtype or share-class identifier within a mainId. Balances hold amounts of each (mainId, subId) pair; one subId can have many fungible units.
Single Contract Architecture
One contract can track several asset classes and subtypes. Whether it saves gas depends on storage, batching and the operations being compared; benchmark the implementation.
Relationship to ERC-1155
ERC-6960 uses familiar multi-token ideas but specifies a standalone interface, including DLT receiver callbacks. Do not assume an ERC-1155 integration or receiver will work unchanged.
Illustrative use cases
Fractional Real Estate
One contract manages the property and all its ownership shares.
Fractional Real Estate
One contract manages the property and all its ownership shares.
Multi-Class Fund Shares
Different share classes under one fund, all in one contract.
Multi-Class Fund Shares
Different share classes under one fund, all in one contract.
Gaming Items with Sub-Properties
A weapon with detachable enchantments, all managed in one contract.
Gaming Items with Sub-Properties
A weapon with detachable enchantments, all managed in one contract.
Technical specification
Selected declarations from ERC-6960, shortened for explanation. Referenced interfaces and omitted methods are in the full specification linked below.
// SPDX-License-Identifier: MIT
interface IERC6960 {
// Balance queries; note the dual-layer IDs
function subBalanceOf(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 returns (bool);
// Approvals
function setApprovalForAll(address operator, bool approved) external;
function isApprovedForAll(address account, address operator) external view returns (bool);
// Events
event Transfer(
address indexed sender, address indexed recipient, uint256 indexed mainId,
uint256 subId, uint256 amount
);
}