Written by Pablo Gómez
Founder & CEO at Metlabs · Reviewed on October 11, 2026
ERC-3525 uses a triple scalar model: ID, SLOT, VALUE. The ID is the token's unique identifier, as in ERC-721. The SLOT is the category that determines fungibility: two tokens in the same slot can transfer value to each other. The VALUE is the fractional quantity held inside the token. Functions such as slotOf(tokenId), balanceOf(tokenId) (which returns the token's value, not a count of tokens) and valueDecimals() support it. The transfer transferFrom(fromTokenId, toTokenId, value) moves value between two tokens in the same slot, and lets value be split or merged without destroying the token's identity. It keeps the ERC-721 interface for ownership and compatibility with NFT infrastructure.
The EIP-3525 specification, Final in status, was created on 1 December 2020 and finalized in September 2022. It requires ERC-20, ERC-165 and ERC-721, and is authored by Will Wang, Mike Meng, Yi Cai, Ryan Chow, Zhongxin Wu and AlvisDu, proposed by Solv Protocol. It matters because it targets customizable, fractional financial instruments: bonds, vesting, fixed-income positions or options, assets that are at once unique in their terms and quantitative in their divisible principal.
ERC-3525 is highly relevant to real-world asset tokenization, especially structured financial assets, where a single slot groups instruments that are fungible by value yet keep their own identity. It sits conceptually between ERC-721 (pure uniqueness) and ERC-20 (pure fungibility), and differs from ERC-1155, which separates fungibility by ID rather than by internal value. On its own it is not a compliance standard: for regulated security tokens it would combine with permission and KYC logic such as that of ERC-3643. The reference example is Solv Protocol, its creator, which uses it for financial vouchers and on-chain yield products.
Also known as
- ERC3525
- Semi-Fungible Token





