The Reserve protocol allows anyone to create stablecoins backed by baskets of ERC-20 tokens on Ethereum. Reserve stablecoins are called RTokens.

As with any smart contract application, the actual behavior may vary from the intended behavior, and it's safest to wait for an application to be in use for a long period of time before trusting it to behave as expected. This overview and subsequent documentation describes the intended behavior.

Once an RToken configuration has been deployed, RTokens can be minted by depositing the entire basket of collateral backing tokens, and redeemed for the entire basket as well. Thus, an RToken will tend to trade at the market value of the entire basket that backs it, as any lower or higher price could be arbitraged.

RTokens can be insured, which means that if any of their collateral tokens default, there's a pool of value available to make up for the loss. RToken insurance is provided by Reserve Rights (RSR) holders, who may choose to stake their RSR on any RToken. Staked RSR can be seized in the case of a default, in a process that is entirely mechanistic based on on-chain price-feeds, and does not depend on any governance votes or human choices.

RTokens can generate revenue, and this revenue is the incentive for RSR holders to stake. Revenue can come from transaction fees, revenue shares with collateral token issuers, or yield from lending collateral tokens on-chain. Governance can direct any portion of revenue to RSR stakers, to incentivize RSR holders to stake and provide insurance. If an RToken generates no revenue, or if none of it is directed to RSR stakers, it probably won't have any RSR staked on it, and thus won't be insured in the case of a collateral token default.

Each RToken is governed separately, and each can have an entirely different governance system. The initial RTokens the core team is deploying will have relatively simple governance systems, which will probably evolve over time. That evolution is up to those that hold power in the initial governance systems.

Governance defines not just one basket to back an RToken, but a series of baskets arranged in a tree-like structure. So there's a current basket, and a series of backups that are selected algorithmically in the case of a default. A collateral token is considered to have defaulted if it's gone down in value more than a defined amount for a long enough time, relative to any of its available backup tokens further down in the tree-like structure.

For the kinds of RTokens the core team is imagining, default will be an extremely rare "black-swan" situation, not something that occurs regularly. But still, it could happen, and that's the purpose of the insurance mechanism.

Governance can update the basket configuration regularly. When the current basket is updated, or in the case of a default, the protocol makes on-chain trades to reach the new basket composition. This trading is modularized so that it can happen in different ways over time as on-chain liquidity evolves. Accessing existing AMMs and running batch auctions are the main anticipated methods for on-chain trade in the near term.