ERC-3525 defines semi-fungible tokens (SFTs): each token has a unique ID like an NFT, a slot that groups tokens with the same characteristics, and a value that can be split or transferred between tokens in the same slot. This “ID–slot–value” model fits financial instruments remarkably well: two bonds with the same issuer, coupon and maturity share a slot, so their face values can be combined or divided, yet each position remains an identifiable object with its own history.
Key takeaways
- Every ERC-3525 token is ERC-721-compatible, so wallets can display it, but it also carries a numeric value.
- Slot = category (e.g. “Issuer X, 5% coupon, 2029 maturity”); tokens in the same slot are fungible in value.
- Value transfers: move part of a token’s value to another token in the same slot, or to an address (creating a new token).
- Natural fit for bonds, vesting plans, invoices and structured products where positions differ in size but share terms.
The ID–slot–value model
| Element | Meaning | Bond example |
|---|---|---|
| Token ID | Unique position | Investor A’s holding #1042 |
| Slot | Shared characteristics | Issuer X 5% notes due 2029 |
| Value | Quantity within the slot | 250,000 nominal |
Key functions include slotOf(tokenId), balanceOf(tokenId) (value), valueDecimals(), approve(tokenId, operator, value) and two value-transfer forms:
transferFrom(fromTokenId, toTokenId, value)— move value between two existing tokens of the same slot.transferFrom(fromTokenId, to, value)— move value to an address, minting a new token for the receiver.
Standard ERC-721 transfers still move the entire token.
Why SFTs suit finance
- Partial transfers of a position (sell 40% of a bond holding) without fractional NFT wrappers.
- Merging positions with identical terms to simplify cap tables.
- Rich per-position metadata — purchase date, lock-up, vesting schedule — while value stays fungible within a slot.
- One contract, many instruments — each slot is an issuance or tranche.
Real-world use cases
Bonds and notes
Each issuance or tranche is a slot; investor positions are tokens; coupons are paid pro-rata to value. Compare with ERC-3475, which takes a class/nonce approach.
Vesting and lock-ups
A token holds the total grant; slot metadata defines the schedule; value can be claimed or transferred as it vests.
Invoices and receivables
Invoices from the same debtor with the same terms can share a slot, letting financiers buy portions of receivables. See private credit tokenization.
Structured products and insurance
Policies or notes with shared terms but different sizes map directly to slot and value.
Considerations
- Compliance: ERC-3525 has no eligibility rules; add transfer checks covering both whole-token and value transfers.
- Integration: many tools understand ERC-721 transfers but not value transfers; plan custom indexing.
- Accounting: reconciliation should track value per slot, not token counts.
- Audit: value-transfer paths and implicit minting deserve careful review.
ERC-3525 vs alternatives
| Need | ERC-3525 | Alternative |
|---|---|---|
| Positions with shared terms and variable size | ✔ native | ERC-1155 (IDs as terms) |
| Many tranches with partitions | ✔ slots | ERC-1400 partitions |
| Simple fungible units | Overkill | ERC-20 |
| Regulated eligibility | Needs extension | ERC-3643 |
Worked example: a bond issuance as ERC-3525
An issuer launches €10m of 5% notes due 2029 (slot #7). Three investors buy positions:
| Token ID | Holder | Slot | Value (nominal) |
|---|---|---|---|
| 101 | Investor A | 7 | 5,000,000 |
| 102 | Investor B | 7 | 3,000,000 |
| 103 | Investor C | 7 | 2,000,000 |
Investor A sells €1m to Investor D: transferFrom(101, D, 1_000_000) reduces token 101 to €4m and mints token 104 to D with €1m in slot 7. Later Investor C buys €500k from B and merges: transferFrom(102, 103, 500_000). Coupon payments are computed per token by value within slot 7.
Slot design patterns
- One slot per issuance or tranche — the most common for bonds.
- Slot per maturity date — useful for laddered note programmes.
- Slot per vesting schedule — each grant schedule is a slot; tokens hold amounts.
- Slot per invoice debtor and terms — receivables financing.
Store slot metadata (coupon, maturity, currency, documents) via the metadata extension so integrators can read terms.
Distributions by value
A coupon engine for ERC-3525 iterates over tokens in a slot (or uses snapshots) and pays value × rate × period to each token owner. Because positions are tokens, payment history can be attached per position — useful for investors who bought part-way through a period.
Compliance hooks to add
- Check eligibility of the receiver on both NFT-style transfers and value transfers.
- Prevent value transfers that would create positions below minimum denominations.
- Restrict transfers during record dates if your corporate-action process needs a stable register.
Frequently asked questions
Yes. Tokens follow ERC-721, so wallets display them; showing value and slot needs SFT-aware interfaces.
ERC-1155 tracks fungible balances per ID per account. ERC-3525 makes each position a unique token that also holds a value transferable within its slot.
Yes. Slots represent issuances or tranches and values represent nominal amounts, enabling partial sales and coupon distribution by value.
Not natively. Add identity and transfer restrictions to every transfer path, or implement an interface such as ERC-7943.
No. Value can only move between tokens of the same slot, which keeps different instruments separate.
Support is narrower than for ERC-20 or ERC-721; confirm with your custodian and plan indexing.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
