ERC-6960: Dual Layer Token

Abstract

The dual-layer token combines the functionalities of ERC-20, ERC-721, and ERC-1155 while adding a classification layer that uses mainId as the main asset type identifier and subId as the unique attributes or variations of the main asset.

The proposed token aims to offer more granularity in token management, facilitating a well-organized token ecosystem and simplifying the process of tracking tokens within a contract. This standard is particularly useful for tokenizing and enabling the fractional ownership of Real World Assets (RWAs). It also allows for efficient and flexible management of both fungible and non-fungible assets.

The following are examples of assets that the DLT standard can represent fractional ownership of:

• Invoices
• Company stocks
• Digital collectibles
• Real estate

Motivation

The ERC-1155 standard has experienced considerable adoption within the Ethereum ecosystem; however, its design exhibits constraints when handling tokens with multiple classifications, particularly in relation to Real World Assets (RWAs) and fractionalization of assets.

This EIP strives to overcome this limitation by proposing a token standard incorporating a dual-layer classification system, allowing for enhanced organization and management of tokens, especially in situations where additional sub-categorization of token types is necessary.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

DLT Interface

DLTReceiver Interface

Smart contracts MUST implement all the functions in the DLTReceiver interface to accept transfers.

Rationale

The two-level classification system introduced in this EIP allows for a more organized token ecosystem, enabling users to manage and track tokens with greater granularity. It is particularly useful for projects that require token classifications beyond the capabilities of the current ERC-1155 standard.

As assets can have various properties or variations, our smart contract design reflects this by assigning a mainId to each asset category and a unique subId to each derivative or sub-category. This approach expands the capabilities of ERC-1155 to support a broader range of assets with complex requirements. Additionally, it enables tracking of mainBalance for the main asset and subBalance for its sub-assets individual accounts.

The contract can be extended to support the use of subIds in two ways:

• Shared SubIds: where all mainIds share the same set of subIds.
• Mixed SubIds: where mainIds have unique sets of subIds.

DLT provides a more versatile solution compared to other token standards such as ERC-20, ERC-721, and ERC-1155 by effectively managing both fungible and non-fungible assets within the same contract.

The following are questions that we considered during the design process:

• How to name the proposal? The standard introduces a two-level classification to tokens where one main asset (layer 1) can be further sub-divided into several sub-assets (layer 2) hence we decided to name it as "Dual-layer" token to reflect the hierarchical structure of the token classification.
• Should we limit the classification to two levels? The standard’s implementation maintains a mapping to track the total supply of each sub-asset. If we allow sub-assets to have their own children, it would be necessary to introduce additional methods to track each sub-asset, which would be impractical and increases the complexity of the contract.
• Should we extend the ERC-1155 standard? As the ERC-1155 standard is not designed to support a layered classification and requires significant modifications to do so, we concluded that it would not be appropriate to extend it for the dual-layer token standard. Hence, a standalone implementation would be a more suitable approach.

Backwards Compatibility

No backward compatibility issues found.

Test Cases

The test suite covers:

• Minting tokens with specific mainId and subId combinations and verifying subBalanceOf reflects correct amounts
• Batch balance queries via balanceOfBatch with array parity validation
• safeTransferFrom between EOAs with balance and allowance checks
• safeTransferFrom to contract recipients implementing IDLTReceiver, verifying onDLTReceived callback
• Rejection of transfers to non-receiver contracts and to revertable receiver contracts
• Approval flows: approve for specific (mainId, subId) pairs and setApprovalForAll for operator-level access
• Allowance spending and the type(uint256).max infinite approval pattern
• Batch transfers via safeBatchTransferFrom with array length validation
• Burning tokens and verifying supply reduction
• Zero address validation on mints, transfers, and approvals

Reference Implementation

A reference implementation is provided in DLT.sol.

The implementation includes:

• DLT.sol: Core token contract implementing the IDLT interface with dual-layer balance tracking, approval management, safe transfers with receiver callbacks, and batch operations.
• IDLT.sol: The interface as specified above.
• IDLTReceiver.sol: Receiver interface for safe transfer callbacks.

The reference implementation uses a nested mapping mapping(uint256 mainId => mapping(address => mapping(uint256 subId => uint256))) for balance storage, enabling O(1) lookups for any (account, mainId, subId) tuple. Allowances follow the same pattern with an additional spender dimension.

Security Considerations

Allowance Race Condition

The dual-layer allowance system inherits the same approve/transferFrom race condition present in ERC-20. If an owner changes an allowance from N to M, the spender may be able to spend both N and M. Implementers SHOULD provide increaseAllowance and decreaseAllowance helper functions or use the check-set pattern where the owner first sets allowance to zero before setting the new value.

Receiver Callback Reentrancy

The safeTransferFrom function calls onDLTReceived on the recipient contract after updating balances. This follows the checks-effects-interactions pattern, but implementers extending the base contract SHOULD be aware that the recipient callback executes with updated state. Contracts that override _beforeTokenTransfer or _afterTokenTransfer hooks must not introduce external calls that could create reentrancy paths.

Batch Operation Gas Limits

safeBatchTransferFrom and balanceOfBatch iterate over unbounded arrays. Callers MUST ensure the array lengths do not exceed block gas limits. Implementations MAY impose an upper bound on array length to prevent out-of-gas failures in on-chain contexts.

Integer Overflow in Balance Aggregation

While individual subBalance values are tracked per (mainId, subId) pair, any aggregation of balances across sub-IDs (e.g., computing a total mainBalance) must account for potential overflow when summing multiple uint256 values. The reference implementation tracks main balances separately to avoid this.

Copyright

Copyright and related rights waived via CC0.