What is ERC-3525: The rise of semi-fungible tokens

Semi-fungible tokens are quickly becoming one of the most practical building blocks for complex assets on-chain. ERC-3525, the “Semi-Fungible Token” (SFT) standard, sits between ERC-20 and ERC-721 by introducing fungible value inside unique token containers. This design unlocks native representations for vouchers, bonds, yield positions, subscriptions, and many other instruments that don’t fit neatly into purely fungible or purely non-fungible paradigms.

Below, we unpack ERC-3525, explain how it works, where it shines, and why it’s poised to power the next wave of tokenized finance.

A quick refresher on token standards

• ERC-20: Fully fungible tokens. Every unit is identical and interchangeable. Widely used for currencies and governance tokens. See the canonical specification on the Ethereum Improvement Proposals site: ERC-20.
• ERC-721: Non-fungible tokens (NFTs). Each token is unique, typically used for collectibles or ownership certificates. Reference: ERC-721.
• ERC-1155: Multi-token standard supporting both fungible and non-fungible items in a single contract with batch operations. Reference: ERC-1155.

ERC-3525 bridges a key gap: you might want a unique token identity (like an NFT) that also carries a divisible, fungible “value” when compared to other tokens of the same type. That’s where “semi-fungibility” lands.

What ERC-3525 actually is

ERC-3525 formalizes three core ideas:

1. Token identity: Each token has its own unique tokenId (like an NFT).
2. Slot: Tokens are grouped into “slots.” Tokens within the same slot are considered fungible with respect to value. Think of slots as asset classes or product lines (e.g., a specific bond series or a particular subscription SKU).
3. Value: Each token carries a numeric balance (its value), which can be partially transferred. Value is fungible within a slot but remains held by unique tokenIds.

In practice, ERC-3525 lets you:

• Mint a unique token that belongs to a certain slot.
• Increase or decrease that token’s value.
• Partially transfer value from one token to another (or to an address), as long as slot rules are respected.

Read the full specification and methods (including slotOf, value, and specialized transfer/approval flows) at the official Ethereum proposal: ERC-3525 Semi-Fungible Token Standard.

Why semi-fungibility matters

Real financial assets frequently have nuanced structures: denominations, maturities, tranches, and rights that are identical only within a specific product line. Representing these as pure ERC-20s or ERC-721s often forces awkward workarounds. ERC-3525 enables:

• Native denomination and partial redemption inside a unique token identity
• Clean grouping by “slot,” so fungibility applies within the intended cohort
• Streamlined approval models to move part of a token’s value (not just entire token ownership)

This is particularly useful for structured products, RWA bonds, staking vouchers, fixed-term deposits, subscriptions, and game economy items that accumulate or spend value.

Key features and mechanics

• Slot-based fungibility: Tokens in the same slot share fungibility of value. Tokens in different slots do not.
• Partial transfers: Move a portion of value from token A to token B (same slot) or to a recipient as a new token.
• Flexible approvals: Approve transfers by token or slot scope for precise control over delegated value movement.
• Metadata: Like ERC-721, ERC-3525 can expose metadata for each tokenId, making UI/UX richer than simple ERC-20 balances.

For developers designing token logic, ERC-3525’s APIs are intentionally structured to make partial-value operations standard, not an add-on. That reduces bespoke logic and improves composability. See the EIP for exact method signatures and expected events: ERC-3525 Specification.

How ERC-3525 compares to ERC-1155

ERC-1155 efficiently handles multiple token types and batch transfers but does not embed the notion of “value inside a unique identity” in the same way. With ERC-3525:

• Each token is unique (like ERC-721), enabling per-token metadata, ownership, and lifecycle.
• Fungibility is defined by slots and the token’s internal value, which can be partially moved.
• It maps neatly to UIs that need to show “this voucher has 100 units remaining” or “this bond position holds 1,000 face value.”

If your application revolves around identity-bound positions with nontrivial denomination handling, ERC-3525 is often more expressive.

Real-world use cases

• On-chain bonds and notes: Issue a series (slot) and mint positions as unique tokens with face value and coupon mechanics. Genesis-style digital bonds have been explored by public institutions, underscoring the direction of travel for tokenized fixed income; see BIS initiatives on digital bonds for context: Bank for International Settlements – Project Genesis.
• Staking and yield vouchers: A user receives a voucher token with accruing value or redeemable shares. Semi-fungibility allows partial redemptions and transfers without losing the token’s identity. For a practical introduction to vouchers and SFTs, see the documentation by protocol teams pioneering this model: Solv Protocol Docs on Vouchers and SFTs.
• Subscriptions and credits: Represent an account’s remaining credits or membership value inside a unique token, enabling transfers or top-ups while preserving identity and metadata.
• Tranche-based assets: Group tranches by slots (e.g., Senior, Mezzanine), and handle partial movements of value. This fits tokenized structured products, which are gaining traction as tokenization matures; see broader context on tokenization growth from institutional sources: BlackRock’s Tokenized Fund Announcement.

Ecosystem context and momentum

Tokenization is accelerating across capital markets and DeFi, with increased experimentation around bonds, money-market strategies, and liquidity tranching. Semi-fungible representations cleanly align with these needs. Developers already familiar with ERC-20 and ERC-721 can adopt ERC-3525 where the product demands:

• Unique token identities that hold fungible value
• Slot-based fungibility classes for asset lines
• Partial transfers, redemptions, and approvals that mimic real-world instruments

For a broader overview of Ethereum token standards and design considerations, consult the official developer resources: Ethereum.org – Token Standards.

Design and UX tips for builders

• Metadata clarity: Include clear metadata about slot semantics (e.g., product type, maturity date, risk profile) so wallets and explorers can present tokens meaningfully.
• Partial transfer UX: Users should understand when they are moving value vs. transferring ownership of the tokenId. Explicit labels and confirmations help.
• Indexing and analytics: You may need custom indexers to track value flows per slot and per tokenId for portfolio reporting and compliance.
• Compatibility: Most infrastructure supporting ERC-721-style metadata can display ERC-3525 tokens, but to fully leverage partial transfers and slot semantics, dApps and wallets should integrate the specific interface. Reference: ERC-3525 EIP.

Security and custody considerations

Semi-fungible tokens frequently represent positions with tangible financial value. As such, secure transaction signing and private key management are paramount:

• Use hardware-backed signing for approvals and partial-value transfers, especially when interacting with DeFi protocols that handle complex value flows.
• Prefer audited smart contracts and well-documented interfaces. Read and verify slot policies and transfer constraints before moving value.

If you want an audited, open-source hardware wallet with strong multi-chain support, OneKey can be a solid choice. OneKey’s firmware and apps are open-source, and it integrates with EVM chains and WalletConnect-enabled dApps, making it suitable for signing ERC-3525 interactions even when the UI is custom to a particular protocol. This is especially helpful for SFTs where precision approvals and partial transfers need secure, reviewable signing flows.

Looking ahead

As tokenization expands to yield markets, fixed income, subscriptions, and game economies, ERC-3525 offers an elegant middle ground between fungible and non-fungible design. Its slot-and-value model captures how real instruments behave: fungible within a series or product, yet managed as unique positions for accounting, rights, and metadata.

If you’re building or investing in complex on-chain assets, consider ERC-3525 for:

• Voucher-style positions with denominations and partial settlement
• Tranche-based structures where fungibility is scoped
• Tokenized credit or utility balances that need identity

For deeper reading and specification details:

• Official spec: ERC-3525 Semi-Fungible Token Standard
• Related standards: ERC-20, ERC-721, ERC-1155
• Tokenization context: Ethereum.org – Token Standards, BlackRock’s Tokenized Fund Announcement, BIS – Project Genesis

If you plan to custody semi-fungible assets and interact with DeFi protocols that use ERC-3525, a robust hardware wallet can meaningfully reduce operational risk. OneKey’s open-source approach and seamless EVM support give you the transparency and control needed to safely manage approvals and value transfers in the emerging SFT ecosystem.