How RSV works

Basics

RSV is backed by a basket of on-chain collateral assets, held by the Reserve Vault smart contract. This basket is, at the moment, fully comprised of USDC — so each RSV is initially redeemable with the Reserve smart contracts for 1 USDC. Since each RSV token is redeemable directly for this basket, value of the RSV token is economically linked to the value of the basket. This anchors RSV at $1.00, as each of the current collateral tokens is redeemable for USD 1:1. This basket can be diversified over time through decentralized rebalancing, which we describe later.

So what can RSV do and how does it work? It comes down to three key features:

  1. RSV Issuance: interact directly with the protocol to lock up collateral and issue new RSV.

  2. RSV Redemption: trade in your RSV for collateral tokens.

  3. Vault Rebalancing: holders can submit proposals to the Reserve Manager smart contract to rebalance the composition of the collateral in the vault.

RSV is the prototype stablecoin that is currently being used in the RPay app. Over time, we intend to replace it entirely with RTokens in the app.

Each of the smart contracts that power RSV have been audited by our friends at CertiK.

Issuance + Redemption

In both cases, someone who wants to interact with our system does the following:

  1. Approves our system to spend some quantity of their funds, using the standard ERC20 interface function.

  2. Calls the “Issue” or “Redeem” function in our smart contracts.

  3. During Issuance, USDC is collected from the user’s wallet and a corresponding quantity of RSV is minted to them.

  4. During Redemption, it happens in reverse: RSV is collected and burnt and the user is compensated with USDC.

Issuing and redeeming RSV can be done either by interacting directly with the RSV smart contract or by using the Register dApp.

Vault Rebalancing

Implicit in the implementation is some notion of what RSV is backed by. We call the process of changing this “Vault Rebalancing”. Here is how it works:

  1. Any Ethereum account can make a “Proposal”.

  2. A Proposal is a suggestion to change what RSV is backed by.

  3. Proposals can be “Accepted” by the governance account. This is an M-of-N multisig contract.

  4. After a Proposal is Accepted, a 24-hour timer begins.

  5. A Proposal can be cancelled by the proposer, any time before execution.

  6. After the 24 hour timer expires, the Proposal can be “Executed” by the governance account, and only by the governance account.

  7. When a Proposal is Executed, some quantity of collateral tokens is withdrawn from the proposer’s account in order to gather the missing funds that are needed to back RSV according to the new Proposal.

  8. Importantly, the Proposer may not have correctly approved the Manager to withdraw the funds from their account, or may simply not have them. If this is the case, then the Proposal fails to execute, but does not get canceled.

  9. If the Proposer did provide the funds sufficiently, the rebalancing transaction leaves them with the excess tokens that are no longer needed to back RSV. The intention is for the governance account to ensure that only Proposals that make economic sense are Accepted.

  10. If the Proposal is executed successfully, RSV takes on a new identity. But while the backing behind RSV may change, our smart contracts guarantee that the entire circulating supply of RSV can be successfully redeemed for the full quantity of collateral tokens.

But wait…there’s more.

There are actually two different types of Proposals. To see why, consider that changes in the circulating supply of RSV are likely to occur during the 24-window between when a Proposal is Accepted and when it is executed. That means that the funds required in order to achieve some target backing may increase in that time.

To deal with this problem, we created two different types of Proposals: Weight Proposals and Swap Proposals.

Weight Proposals

A Weight Proposal consists of the following:

  1. A list of token addresses of length N.

  2. A list of “weights” of length N.

So for example, it might be: [TUSD, USDC] and [0.50, 0.50].

(Here we’ve normalized the weights for readability, but in reality weights are expressed as much larger numbers, usually 10³⁶, in order to maintain precision during calculations.)

Swap Proposals

A Swap Proposal consists of the following:

  1. A list of token addresses of length N

  2. A list of quantities of length N.

  3. A list of booleans indicating whether the quantity is to be added or removed from the Vault.

So for example, a Swap Proposal may consist of [TUSD, USDC], [1000, 1000], [True, False]. This Proposal says to add 1000 units of TUSD to the Vault, and remove 1000 units of USDC from it.

How they work together

Consider the case where the RSV circulating supply is 1 billion. In that case, rebalancing from [33%, 33%, 33%] [USDC, TUSD, BUSD] to [50%, 50%] [USDC, BUSD] would require $333 million worth of capital. That’s a lot. I don’t know about you, but I don’t have that kind of money laying around. One way to deal with this is to make the transition in a series of small steps:

  1. Submit and execute many Swap Proposals to add some amount of USDC and BUSD, while removing some amount of TUSD. For example: [33%, 33%, 33%] -> [34%, 34%, 31%] -> [35%, 35%, 29%]…

  2. After many iterations, we will approach the [50%, 50%, 0%] split we were initially targeting. However, it probably won’t be exactly that. It will probably be slightly off. In addition, even if it is in fact zero, TUSD needs to be eliminated as a token address in order to avoid bloat.

  3. This is accomplished by submitting and executing a Weight Proposal, explicitly specifying the desired [50%, 50%] split, and eliminating the third token. This is the step that finally removes the TUSD token from the basket and ensures any remaining small quantities are transferred out.

Users will be able to use both types of proposals interchangeably. We think Swap Proposals may be easiest to think about, but Weight Proposals are crucial for maintaining precision in the long-term.

Auth and other Controls

The system also has an Owner, currently set to an M-of-N multisig, with the following controls:

  1. Pause the system. When the system is paused, Issuance, Redemption, and Proposal actions cannot occur. This control is called “emergency” and is only intended for situations that demand it.

  2. Pause Issuance. Redemption remains functional in this case. We only anticipate having to use this control if RSV grows too rapidly. Similarly, a max supply on RSV can also be set.

  3. Pause all transfers of RSV.

  4. Designate and specify a seigniorage amount on Issuance. This is currently set to 0.

  5. Change the 24 hour delay between Proposal Acceptance and Execution.

  6. Upgrade the Manager smart contract.

  7. Set auth permissions on the Vault.

  8. Set auth permissions on RSV.

Note: Due to these last 3, it is possible for Owner to get access to the Vault funds.