Semi-Fungible Tokens (SFTs) are now available on StarkNet!

4 min readDec 20, 2022

An open-source ERC3525 contract in Cairo.

TL;DR:

— Carbonable implemented the ERC3525 Semi-Fungible Token in Cairo.
— The repository is open source (reviewers welcome).
— ERC721 compatible while combining features from ERC1155 and ERC20.
— Represent diverse real-world assets in a single contract.

📢 Announcement

We are excited to announce a Cairo implementation of Semi-Fungible Tokens! At Carbonable, we open sourced our implementation of EIP-3525 that was finalized early September. The implementation is based on the Solidity version from Solv-protocol whose team co-authored the EIP, and we are taking steps to standardize the implementation for StarkNet.

🤌 But, what are SFTs?

EIP-3525 defines a new standard to solve what EIP-20 and EIP-721 couldn’t.
Now, we can represent different types of financial assets that can be transferred by portions, in only one contract.

Indeed, ERC3525 tokens have a fungible “balance”, like an ERC20, while having a non-fungible ID, like a NFT. This makes them semi-fungible in a more elegant way than previous standards could.

A real-life example of something semi-fungible is “pizza”. Pizza can be cut in slices and sold separately, and sliced even further in case more people join the party. Slices are not born equal, a slice of pizza with truffle might be more expensive than an equally-sized slice with pineapple.

In DeFi, applications are numerous and also come in different flavours:

Now, you can design an $50 gift voucher that your users are able to split in a $30 voucher to give their friend and keep $20 to themselves.
Now, you can accumulate in-game currencies to dollar-cost-average the next level weapon.
Now, you can even buy a portion of a tokenized real-estate property, stake one part to get monthly rent income and keep the other to resell.

🤯 Why are SFTs useful?

The design of ERC3525 allows you to neatly represent stocks, bonds, vouchers, equity shares, gaming assets, … and other ideas galore. For instance, here’s how you could show the wallet portfolio of a user:

User Wallet:
╔══════╦══════════╦═══════╗
║ SLOT ║ TOKEN_ID ║ VALUE ║
╠══════╬══════════╬═══════╣
║ USD  ║        1 ║    69 ║
║ USD  ║        2 ║    20 ║
║ EUR  ║        3 ║    42 ║
║ BTC  ║        4 ║  0.02 ║
╚══════╩══════════╩═══════╝

This user owns two tokens (ID 1 and ID 2) in the same slot (USD), they can transfer some value portion to another user or to themselves just like UTXOs in Bitcoin.

When depositing a token for lending, a user might transfer a portion of value to a SFT owned by the lending protocol, and received deposit tokens back. This allows users to claim interests as a value transfer, in tokens or deposit tokens (whether the user chose to auto-compound or not).

The final picture could look like this after USER1 sent $30 to USER2 and deposited ₿0.02 and $20:

╔═════════════╦═══════════╦═══════╦══════════════════╗
║    SLOT     ║   USER1   ║ USER2 ║ LENDING PROTOCOL ║
╠═════════════╬═══════════╬═══════╬══════════════════╣
║ USD         ║ [30, 0]   ║ [30]  ║  [1337420]       ║
║ EUR         ║ [42]      ║       ║                  ║
║ BTC         ║ [0]       ║       ║  [911]           ║
║ BTC deposit ║ [0.02001] ║       ║                  ║
║ USD deposit ║ [2.07]    ║       ║                  ║
╚═════════════╩═══════════╩═══════╩══════════════════╝

ERC3525 features

ERC-3525 = ERC-20 quantitative operations + ERC-721 compatibility.

In code, the structure of an ERC3525 has 3 layers: (ID, SLOT, VALUE). While the ID corresponds to a token_id and VALUE corresponds to a fungible balance, the slot part is new!
Slots enable ERC3525 to be a meta collection: each slot can tell apart different assets, and value transfers can only be made between tokens in the same slot.

The notion of ownership has also been taken a step further. The owner of an ID is an address, however the owner of a VALUEis an ID! This allows to create “receptacles” of value that can be transferred regardless of the owner. This shift of perspective enables more granular features:

we can now transfer value ID to ID ;
approvals are made at the VALUE and the SLOT level ;
SFTs can be split and merged back.

🙋Ok, why not use ERC20?

Well, sure you could, but you would need to redeploy a new contract for every asset and to store metadata separately. Not very elegant.

🙋Ok, why not use ERC721?

Well, you could, but then you would also need one contract per asset and tokens can only hold a fixed amount of value.

🙋Ok, why not use ERC1155?

Aha, you got me, you can use one ERC1155 contract to represent several assets and emulate fungibility with a huge supply. However users can only own one balance per type of asset, they cannot split a $30 voucher into a $20 and a $10.

Food for thought

As ERC3525 is compatible with ERC721, marketplace will be able to display SFTs out of the box. However, since the value of a token is a dynamic variable stored in the contract, additional care should be taken by marketplace to display accurate data.

In an upcoming article, we’ll discuss about how to handle Metadata dynamically with ERC3525 and even store or generate all Metadata on-chain. This is a must for any serious decentralized project, and part of Carbonable’s choice of using ERC3525 for trustless and transparent design.

Stay updated and keep in touch:

🌍 Website: carbonable.io
📧 Email: reachout@carbonable.io
🐦 Twitter: https://twitter.com/Carbonable_io
💼 LinkedIn: https://www.linkedin.com/company/79714509
👾 Discord: https://discord.gg/pHnAtgg54W

Credits

This article was written by Tekkac with editorial help from Guillaume and CypherChappie.