The Service token
Credit is semi-fungible. To see why, consider a Fitness trainer. Credits she grants to access her virtual class may not necessarily transfer to her in-studio sessions. So two credits issued by this creator are not fungible. On the other hand if two of her tokens each hold $30 worth of credits that can be applied to her virtual session, then those credits are functionally equivalent - and therefore fungible. Web3 projects have historically relied on Ethereum’s ERC-20 fungible token standard, ERC-721 non-fungible standard, and more recently - the ERC-1155 multi-asset token standard. Of these three standards, only ERC-1155 can represent fungibility and non-fungibility alike, but it does so by binding fungible value to wallet address rather than to token IDs. This binding makes ERC-1155 an unsuitable standard for smart contracts that mint credits tokens. ERC-3525, a new Ethereum semi-fungible token standard ratified in December 2022 is ideal for representing service credit. Each ERC-3525 token has a Token ID, a Value, and a Slot ID. A creator or project will likely have offerings that differ by time, venue (virtual vs physical), coverage or other features; each token ID associates to an offering issued to a customer. The value tracks how much credit is available on the token. As with an NFT, a holder of a 3525 token may sell / transfer the token to another person; unlike NFTs, 3525 tokens enables the holder to transfer value from their token to another token with the same slot ID. For instance, you may have a special promotional or charity offering which you do not want to honor existing credit redemptions; then you would assign the promotional tokens to a new slot ID.
The service smart contract
Each of these types has its own smart contract class that inherits from the Service contract, which inherits from the parent ERC-3525 contract.
Slot networks
The ERC-3525 standard introduced the SlotID. Token holders can only conduct token-to-token value transfer for tokens on the same slot. To understand why this feature is important, consider the scenario where an artist deploys a Time credit contract and mints tokens for two types of offerings: one set of tokens grant followers access to 1-on-1 virtual meetings with the artist while another set, worth twice as much, grants access to live-streams of his concerts. All tokens were minted on the same slot. Suppose that I hold a 1-on-1 meeting token while John holds a concert streams token. I decide to sell my token to John, then John gets to meet with the artist instead of me. This is a token-to-address transfer, which is the typical transfer mode for NFTs. If instead of selling my token I decide to transfer a fraction of my 1-on-1 credits to John’s concert streams token (of course John will accept the transfer). Since concert stream credits are worth twice as much as 1-on-1 credits this transfer creates value (for John) at the artist’s expense. To avoid such a scenario the artist assigns the two sets of tokens to different slots.
The ERC-3525 standard contract mints tokens to any slotId. A contract instance, once deployed, keeps an internal registry of slots and a list of tokens minted on each slot in order to enforce the same-slot value-transfer rule. Each request to mint a token must include a slotId; thus for Service contracts, each service offering and credit issuance must be associated with a slot. If a new slotId accompanies a mint request, then the new slot and its accompanying list is added to the contract instance’s registry. This setup works fine if the contract instance exists in isolation. For our case however, creators collaborate, and more importantly, users do not consume services in isolation. Thus to enable a token holder to, for example, access offerings from multiple providers using a single token, Meritic introduced a slot registry contract to ensure that slots, once registered, are unique across creator contract instances.
The slot registry is a smart contract running on the blockchain so anyone can register a slot. By default, every slotId is added to the registry. There are two types of slots: contract slots and network slots. Contract slots have tokens minted by a single contract instance. Network slots have tokens minted from multiple contract instances (across different services).
Service contracts must be approved to mint a token on a network slot. If you register a slot then by default, all your contracts are approved to mint to that slot. After registering a slot, the slot creator can approve any service contract instance to mint on the slot. Approval notices are sent to the administrators of the approved contracts. The contract admins then have to register their approved contracts as members of the slot before minting a token on the network slot.
