Discounted Cash credit

For Cash credit tokens, a project may issue credit at discount by, for example, requiring a minimum bid of 70 USDC to own a token with 100 USDC of credit. In Meritic’s implementation, each cash token is minted with a discount factor of $d$%. When the customer redeems $X$ units of credits then

$$Y = \left(1 - \frac{d}{100}\right) X \hspace{2pt} \text{ USDC }$$

is unlocked from the contract underlying pool and transferred to the project's revenue address.

Secondary market transactions

A common type of secondary market transaction occurs when one sells/transfers his token - ownership to another party. Such transactions may occur on centralized marketplaces, decentralized exchanges, or peer to peer wallet transfers. For such transactions, the only change that occurs is the smart contract updates the token owner address with the wallet address of the new token holder. The token ID, Slot ID, and credit value remains unchanged. If the transfer was as a result of a sale, then the credit value of the token (should) inform the secondary market selling price, but that selling price does not affect the credit value in the token.

As mentioned earlier, ERC-3525 introduced a new transfer mode: token-to-token value transfer for tokens with the same slot ID. The token holder transfers a fraction of their credit to another token (that may or may not be owned by someone else). When credits are transferred between tokens, the contract underlying asset pool remains unchanged. However we must consider the possibility that the two tokens have different discount factors, in which case the discount factor of the destination token, $d_d$, must be updated. If the source token, with discount factor $d_s$, is transferring $X$ units of credit to the destination token, which has $Z$ units of credit before transfer, then after value transfer the destination token has discount factor of

$$d_{d,new} = 1 - \frac{(1 - d_s) X + (1 - d_d)Z}{(X + Z)}$$

For such value transfers, Meritic requires that the credit values be of the same type (monetary credit value cannot be transferred to time credit value).

Discounted Time Credit

Consider a token sale where a customer pays 100 USDC for 1 hour of service credit. As previously explained, the service smart contract holds the stable asset until the customer redeems the credit hour. Time credit contracts do not use discount factors directly. Instead, when a token is minted, the smart contract calculates $r$, the per-second time-value rate using the minimum bid price (lets assume the minimum bid equals the sale price of 100 USDC) and the time credit value (1 hour). If the token is given out for free then the time-value rate is zero.

Time redemption occurs when the holder uses the service for some $X$ units of time (converted to seconds) available on the token. A commensurate underlying asset value of :

$$Y = r X \hspace{2pt} \text{USDC}$$

is released from the contract’s asset pool and transferred to the project's revenue address.

As with Cash credit, if the token owner conducts a secondary transaction that requires transferring the time token to a new owner then the service contract updates the token owner's address while keeping the time-value rate and other token properties unchanged.

Also a time token may receive $X$ time-credits (converted to seconds) via token-to-token value transfer. In such a case, the smart contract must consider the time-value rate $r_s$, of the source token, $r_d$ the time-value rate of the destination token, and $Z$, the amount of time credit (in seconds) in the destination of the destination token prior to transfer. After value transfer, $r_d$, becomes:

$$r_{d,new} = \frac{(r_s X + r_d Z)}{ X + Z}$$