ERC-3525

The core innovation is the dual-identifier system: a slot (defining a token's class or type) and a unique ID (defining the specific instance). All tokens with the same slot are fungible with each other, while tokens in different slots are non-fungible. This allows for representing assets like bonds (slot = bond series, ID = specific certificate) or loyalty points tiers.

Each ERC-3525 token has an intrinsic value property, stored directly on-chain within the token itself. This value is a positive integer that can be transferred between tokens of the same slot, enabling operations like splitting and merging value without burning and minting new tokens. It's ideal for representing balances, credits, or stakes attached to a specific identity.

The standard supports three granular transfer modes:

• Value Transfer: Move a portion of value from one token to another within the same slot.
• Token Transfer: Transfer an entire token (its ID and full value) to a new owner.
• Transfer From: Allows approved operators to manage transfers, similar to ERC-721. This enables complex financial logic like partial redemption or collateral rebalancing.

ERC-3525 tokens are designed for composability with other smart contracts and standards. They implement ERC-165 for interface detection and can hold rich, structured metadata via the ERC-3525 Metadata JSON Schema. This allows tokens to represent detailed real-world attributes, making them suitable for DeFi positions, insurance policies, and verified credentials.

While both are "semi-fungible," they serve different purposes:

• ERC-1155: A batch standard for efficient management of multiple token types (fungible and non-fungible) in a single contract, optimized for gaming and marketplaces.
• ERC-3525: An individual token standard where each token ID is a stateful container with transferable value, optimized for financial instruments and identity.

The standard's structure enables novel applications:

• Financial NFTs: Representing bonds, options, or insurance policies with decaying or accruing value.
• Loyalty & Membership: Tiered programs where points (value) are tied to a specific member ID (token).
• DeFi Vault Shares: Representing a user's position in a vault, where the value is their share and the slot defines the strategy.
• Real-World Asset (RWA) Tokenization: For assets like invoices where the slot is the issuer and the value is the outstanding amount.

The standard can model tiered loyalty points and dynamic memberships. A retail chain could create a single Loyalty Points slot. Each user's points balance is a unique token ID within that slot, allowing the points to be programmatically split, merged, or upgraded (e.g., from Silver to Gold tier) by adjusting the token's value. This enables complex reward logic without minting new token contracts.

ERC-3525 provides a native structure for game items with stackable attributes. For example, a "Health Potion" slot could contain millions of tokens (IDs), each with a value representing potency or quantity. Players can merge two half-full potions or split a stack, with all actions executed through simple value transfers. This is more efficient than managing individual ERC-721 NFTs for each stackable item.

The standard is powerful for fractionalizing and managing real-world assets. A commercial real estate property can be represented as a slot, with each token ID representing a share. The value denotes the share percentage, and the underlying metadata (properties) can store legal documents, rental income schedules, or appraisal reports. Shares can be programmatically split for further fractionalization or merged for consolidation.

ERC-3525 can model on-chain credit lines and debit accounts. A "Credit Line" slot is issued by a protocol, and each user receives a token ID where the value represents their remaining credit limit. As the user draws down or repays credit, the token's value is adjusted accordingly. This creates a semi-fungible, transferable record of credit that can be used as collateral or settled in secondary markets.

The power of ERC-3525 stems from its two-layer structure:

• Slot: Defines a class of assets (e.g., "US Treasury Bond, 5-Year"). Tokens with the same slot are fungible and interchangeable.
• ID: A unique identifier within a slot. Each ID has its own value (a uint256) and can store custom metadata. This allows for atomic operations like transferring a portion of a token's value or merging two tokens from the same slot, which is impossible with ERC-20 or ERC-721.

An ERC-3525 token is a Semi-Fungible Token (SFT) that combines properties of both ERC-20 (fungible) and ERC-721 (non-fungible) standards.

• Slot: A classification ID that groups tokens with identical properties and rules.
• ID: A unique identifier for each token instance within a slot.
• Value: A fungible, transferable quantity assigned to each token ID.

This structure allows tokens in the same slot to be merged, split, and transferred in amounts, while retaining unique metadata.

The standard's power lies in its built-in arithmetic for managing token value within slots.

• Transfer by Value: Send a portion of a token's value (e.g., 50 units) to another token, either within the same slot or a compatible one.
• Merging & Splitting: Two tokens in the same slot can be merged into one with combined value, or a single token can be split into multiple new tokens.
• Approval by Slot: Grant spending approval for all tokens within a specific slot, streamlining DeFi interactions.

ERC-3525 is ideal for representing complex financial positions on-chain with native composability.

• Bonds & Notes: The slot defines the bond series (issuer, maturity, coupon), the ID is the specific note, and the value is the principal amount. Value can be transferred to represent partial ownership.
• Loyalty Points & Vouchers: A slot for a reward program can contain millions of user-specific token IDs, where the value represents the point balance that can be split and spent.
• Real-World Asset (RWA) Tokens: Fractionalized ownership of an asset class (slot) with individual investor positions (IDs) and transferable stake amounts (value).

The standard is gaining traction in projects focused on structured finance and digital asset management.

• Solv Protocol: A leading platform using ERC-3525 for its Convertible Bonds and financial vaults, representing vesting schedules and convertible notes.
• D/Bond: Uses the standard for its price-yield bonds, enabling programmable fixed-income instruments.
• ERC-3525 is also foundational for on-chain gaming assets (like items with stackable quantities) and soulbound reputation systems where a score (value) is attached to a non-transferable identity (ID).

While both standards can represent multiple token types, ERC-3525 is designed for stateful, composable value rather than simple batch operations.

• ERC-1155: Manages balances of distinct token IDs in a batch. It is fungible per ID but lacks internal value transfer between tokens.
• ERC-3525: Each token ID has its own mutable value storage. The focus is on the arithmetic relationship and transferability of value between token IDs within the same ecosystem of slots, enabling complex financial logic natively in the token.

Implementing ERC-3525 involves extending the core interface to define slot logic and value rules.

• Core Interface: Must implement functions like slotOf(uint256 tokenId), valueOf(uint256 tokenId), and transferValue(uint256 fromTokenId, uint256 toTokenId, uint256 value).
• Slot Design: The contract logic must define what each slot represents and the rules for transfers between slots (if allowed).
• Metadata: Can adhere to ERC-3525 Metadata JSON Schema to describe the properties of slots and token instances.

The standard enables new patterns for DeFi composability where tokens carry their own transferable state.

ERC-3525 tokens have a value (fungible unit) attached to an ID (non-fungible container). This requires careful design:

• Transfer Rules: The standard allows partial value transfers (transferFrom and transferFrom with a specified value). Contracts must enforce that a token's value never goes below zero and that transfers respect authorization.
• Allowance System: The dual-layer allowance system (for IDs and values) is complex. Auditors must check that allowances are correctly decremented for both partial and full transfers to prevent overspending.
• Batch Operations: If implementing batch transfers, ensure atomicity—all transfers in the batch must succeed or fail together to avoid inconsistent states.

SFTs are designed for DeFi composability, which amplifies integration risks:

• Approval to Non-Compliant Contracts: Approving value or tokens to a smart contract that does not properly implement the ERC-3525 receiver interface can lead to permanent loss. Use safeTransferFrom which checks for receiver compatibility.
• External Call Ordering: When an SFT's logic triggers external calls (e.g., to a lending protocol), follow the checks-effects-interactions pattern to prevent re-entrancy and state manipulation before effects are written.
• Oracle Dependence: Financial SFTs (e.g., representing bonds) often rely on price oracles. Use decentralized, time-weighted average price (TWAP) oracles to mitigate manipulation.

Many SFT applications will use upgradeable proxies. This introduces specific threats:

• Storage Collisions: In upgradeable contracts, ensure the new logic contract's storage layout is compatible with the proxy's stored data. A mismatch can corrupt token balances and slots.
• Initialization Attacks: Use a transparent or UUPS proxy pattern with a protected initialize function that can only be called once to prevent hijacking of the contract's initial state.
• Governance Delay: For critical parameter changes (like adding new slot types), implement a timelock on the governance contract to allow users to react to potentially malicious proposals.

Focus testing and audit efforts on the unique aspects of the ERC-3525 standard:

• Property-Based Testing: Use fuzzing tools (like Echidna) to generate random sequences of mints, transfers, and slot changes to uncover edge-case logic errors.
• Invariant Testing: Define and test core invariants, such as: Total supply must equal the sum of all token values and A token's slot cannot be changed without proper authorization.
• Integration Test Suites: Deploy mock versions of expected integrators (wallets, DEXs, lending protocols) to test end-to-end flows before mainnet deployment.
• Formal Verification: For high-value financial logic, consider formal verification of critical state transitions.

The foundational standard for Non-Fungible Tokens (NFTs), where each token is a unique, indivisible asset with a distinct tokenId. ERC-3525 builds upon ERC-721 by adding a slot and value structure, enabling a single token ID to hold multiple, fungible units of value. While an ERC-721 token is a single, atomic item, an ERC-3525 token is a container that can hold and transfer fractional amounts.

The standard for Fungible Tokens, where each unit is identical and interchangeable (e.g., a cryptocurrency). ERC-3525 incorporates fungibility at the value level within a token. A single ERC-3525 token can hold a balance of fungible units, similar to an ERC-20 balance, but that balance is tied to a unique, non-fungible token ID and slot, enabling complex ownership and logic structures.

A standard for managing multiple token types (both fungible and non-fungible) in a single contract. While ERC-1155 handles batches of different token IDs, ERC-3525 focuses on intra-token composability. Key differences:

• ERC-1155: Manages collections of distinct tokens.
• ERC-3525: Enables a single token to have internal state (value) and relational logic via slots, making it ideal for representing financial instruments with layered attributes.

A core metadata attribute in ERC-3525 that defines a token's classification or purpose within a system. Tokens with the same slot are considered to be of the same type and can often interact (e.g., merge values). It enables logical grouping and programmability. For example, in a bond system, all tokens representing "6-Month US Treasury" bonds would share the same slot, while their individual tokenId and value represent specific issuances and holdings.

A standard that gives an NFT its own smart contract wallet. This relates to ERC-3525's vision of tokens as containers. While ERC-6551 makes an NFT an account that can hold assets, ERC-3525 makes a token a data structure that can hold quantifiable value. They can be complementary: an ERC-3525 token, representing a financial position, could be owned by an ERC-6551 token-bound account, creating deeply nested asset ownership graphs.

An application category where NFTs represent financial assets like bonds, insurance policies, or invoices. ERC-3525 is the predominant technical standard for FiNFTs because its slot/value model natively handles the requirements:

• slot: Defines the financial instrument type (e.g., bond series).
• value: Represents the holding amount or face value.
• Transfers: Allow partial transfers of value without fragmenting the core legal instrument (tokenId).