Service credit using ERC-3525
Web3 projects have not embraced credit issuance perhaps because of infrastructural and regulatory challenges. On infrastructure, until recently there has been a lack of flexible smart contract standards. What remains is user-friendly credit issuance and a flexible redemption process. Until 2017 many projects minted their own ERC-20 fungible tokens, which served as funding vehicles and, in many cases, credit issuance: one had to acquire a project’s tokens to access some service offerings. In late 2017 though, regulators curtailed that practice due to fraud associated with ICOs. Since then, Web3 projects have relied on ERC-721, the Non-fungible Token standard, and its successor, ERC-1155 to tokenize their offerings . While ERC-1155 can represent fungibility and non-fungibility alike, it does so by binding fungible value to wallet address rather than to token IDs. This type of binding makes ERC-1155 unsuitable for representing semi-fungible service credit.
ERC-3525, a relatively new Ethereum Semi-fungible Token (SFT) standard ratified in December 2022 is ideal for representing credit. Each ERC-3525 token has a Token ID, a Value, and a Slot ID. To understand how these fields are used to tokenize credit, consider a service that lists offerings that may differ by time, venue (virtual vs physical), coverage or other features. The Token ID identifies an offering to be sold to a customer. Although, in some cases, two customers purchase equivalent offerings, in general this is not the case, so we can use a unique Token ID to identify an offering issued to a customer. The value tracks how much credit is available on the token. As with an NFT, the owner of the SFT can transfer the token to a new owner (a token-to-address transfer); unlike NFTs, ERC-3525 enables the owner of the SFT to transfer value from his token to another SFT (a token-to-token transfer) as long as the tokens have the same Slot ID.
Slots maintain credit differentiation in the secondary market. Imagine a merchant, with stores in the US and Canada, used ERC-3525 to implement their gift cards. The merchant applies different rules to US and Canadian stores so they use a different slot ID for each country. You bought your gift card in Canada, while I purchased mine in the US. Then if you give me your wallet address then I can transfer my token to you. However if you give me your token Id I and I attempt to transfer some of my credit to your token, the value transfer would fail since the tokens are on different slots. The merchant differentiated their credit by country, but we can imagine a project electing to differentiate credit by season, or luxury vs basic offerings, or promotional vs standard offerings, or any grouping of token Ids that meets their needs.
Actually, some aspects of the operational model of the traditional gift / prepaid card are worth emulating in Web3. The process works as follows. A customer pays an amount of money to the merchant or card network provider. The funds are held in a bank account and a card with equivalent credit value is issued to the customer. At some point in the future, the customer redeems the card by using it to pay for service. When that happens the transaction value is transferred from the linked bank account to the merchant’s bank account and credit balance on the card is updated. If it is an open loop card then the customer can spend it in credit with any merchant on the network, while in a closed loop, the customer can only redeem the card at the merchant that issued the credit. The notable features are
- credit value is linked to real value
- the merchant does not access real value until the customer redeems the credit