Core Mechanism
In contrast to ERC-20’s _value, ERC-721’s _tokenID or ERC-1155’s (_id, _value), the data structure of an ERC-3525 semi-fungible token is an <ID, SLOT, VALUE> Triple Scalar Model, consisting of _tokenId, _slot, and _value.


The _tokenId in ERC-3525 is defined as a value type in terms of a uint 256, an unsigned integer in the size of 256 bits in Solidity, and is equivalent to the _tokenID in ERC-721. _tokenId reflects the non-fungible aspect of digital assets.


_slot is a new attribute that categorizes variables in financial or business applications. One may implement _slot by hashing its underlying properties as a uint-256 abstraction.
A critical tip for implementation here is the uniqueness of the _slot value. As long as different slots have different values, there could be different solutions (such as uint 8).


Similar to the balanceOf() / _value mechanism in ERC-20, ERC-3525's balanceOf() can be used to query the amount of the underlying asset of an ERC-3525 token, and its value type is defined as a Solidity-based uint 256. That means transferring ERC-3525’s _value to other addresses works similarly to transferring _value for ERC-20 tokens.
This means that the token-address structure of ERC-3525 has two layers, upgraded from one-layer structures found within ERC-20, ERC-721, and ERC-1155. The _value in ERC-20, _tokenID in ERC-721, and (_id, _value) in ERC-1155 are owned by an address. While the _tokenId in ERC-3525 is also owned by an address, the _value is contained or “owned” by the _tokenId.
The Two Layers of ERC-3525's token-address structure
Is this section clear to you? Your feedback is important to us. To provide feedback, go here.