Jun 10, 2024
Useful Links
Website: reserve.org | app.reserve.org
Documentation: Protocol Docs | Github | Audits | Intro video
Contracts: deployed contracts
RTokens: Electronic Dollar (eUSD) | ETHPLUS (ETH+) | Web 3 Dollar (USD3)
Introduction
This report is conducted by the Reserve independent risk and research team operated by Llama Risk as part of a series on RToken risk assessments. In this report, we introduce the Reserve protocol and the RToken standard.
This series will comprehensively cover all relevant risk factors of RTokens. Our approach involves quantitative and qualitative analysis to help users gain insight into risks associated with individual RTokens.
As Reserve introduces a standard for issuing RTokens, our review involves comparative analysis, where applicable. Risks are categorized into:
Collateral Basket Risk - risks related to the underlying collateral basket making up the RToken
Governance Risk - risks related to the governance framework employed by the RToken
Parameter Config - risks related to the parameter configuration of the RToken.
Market Risk - risks related to market liquidity and volatility of the RToken
These risk categories will be summarized for each RToken we review and are meant to assist Reserve protocol users in selecting RToken exposure that matches their risk appetite and to assist decentralized lending and stablecoin platforms in making onboarding decisions.
Section 1: Protocol Fundamentals
This section introduces relevant background information about the Reserve protocol and mechanics behind Reserve RTokens.
1.1 Introduction to Reserve Protocol and RTokens
The Reserve Protocol is a decentralized platform that facilitates the creation of RTokens, a class of stablecoins, flatcoins, and indexes backed by a diverse basket of yield-bearing assets, and maintaining over-collateralization through Reserve Rights (RSR) tokens staked on specific RTokens. ABC Labs is the main developer of the Reserve Protocol.
RTokens are minted when users deposit a specified basket of ERC-20 tokens into the protocol and can be redeemed at any time for the underlying collateral. The Reserve Protocol maintains the stability of RTokens through collateral diversification, dynamic basket management, and a unique revenue-sharing model that incentivizes RSR holders to provide additional over-collateralization.
The protocol's architecture consists of two main components: core contracts and plugin contracts. Core contracts, such as the Main, BackingManager, BasketHandler, Furnace, and RevenueTrader, form the backbone of the Reserve Protocol and are responsible for key functions such as collateral management, basket rebalancing, and revenue distribution. Plugin contracts, conversely, are modular, allowing for the integration of various assets and collateral types into the ecosystem.
1.2 Reserve Protocol
1.2.1 Objectives
Overall, Reserve Protocol offers an expansive framework for bringing RTokens to market that explores a multitude of characteristics in terms of collateral backing, reference assets, governance structure, and parameter configuration, that target users based on their propensity toward risk. The protocol aims to provide a stable, scalable, and transparent alternative to traditional fiat currencies and volatile cryptocurrencies, fostering greater financial inclusion and economic stability in the digital asset ecosystem.
A unique feature of RTokens is their permissionless deployment, supported by a host of configurable parameters, a customizable collateral basket, and a supplied governance framework. The aim is to minimize friction in deploying RTokens such that there may be a diverse set of RTokens that compete on adoption based on their range of risk profiles and trust assumptions.
The protocol is designed overall to balance resiliency with flexibility, placing responsibility for the balance on stakeholders of each specific RToken, and ultimately to allow market forces to define the most successful RToken designs. For instance, there are automated emergency levers built into the protocol to programmatically offload exposure to defaulted collateral types. There is also the possibility for governance to define default conditions and assign emergency collateral types. The various design features are consistent between RTokens, although configuration decisions are assigned by the RToken creator and subsequently by its governance. Exploration of these design features and implications of various configuration choices is therefore significant to anyone choosing to take exposure to any RToken.
1.2.2 Key Components and Architecture
The Reserve Protocol's architecture consists of two main components: core contracts and plugin contracts.
Core Contracts
Core contracts form the backbone of the Reserve Protocol and are responsible for the system's essential functions. The main core contracts include:
Main: The central contract that manages the registration and interaction of other core contracts.RToken: The ERC20 token with elastic supply and a governable exchange rate to basket units.BackingManager: Manages the collateral backing RTokens, including revenue distribution through minting additional RToken and facilitating auctions.BasketHandler: Manages the composition and rebalancing of the collateral basket for each RToken.Furnace: Handles the distribution of revenue generated by the collateral to RToken holders.RevenueTrader: Facilitates trading revenue assets for RTokens or RSR, supporting the protocol's revenue-sharing model.stRSR: The RSR staking contract where RSR holders can stake on an RToken to provide overcollateralization in exchange for revenue share and governance rights.
The interrelationship between contracts is shown in the example token flow diagram for ETH+ below.
Source: ReserveRisk Diagram | Date: 3/13/24
Plugin Contracts
Plugin contracts are modular components that define how the core contracts should treat an ERC20 token. These contracts are not upgradeable, but governance can swap in a new plugin for a given ERC20 if it chooses or needs to. This can be done without upgrading the core contracts. The main types of plugin contracts include:
Asset and Collateral contracts: These contracts support the ERC-20 tokens with information needed to use them as collateral for RTokens. They provide a common interface for the core components to price, claim rewards on, and refresh the status of ERC20s that are registered for use by an RToken.
Trade contracts: Managed by the Broker contract, Trade contracts are responsible for managing the execution of auctions, enabling the rebalancing of collateral baskets and the exchange of revenue assets.
See below how Collateral Plugins may be contributed by various developers which are then integrated into the collateral baskets of RTokens deployed by various entities or individuals. End users generally interact with RTokens on secondary markets, potentially engaging in arbitrage directly against redemptions on Reserve.
Source: Reserve
1.3 RTokens
1.3.1 What are RTokens?
RTokens, as have been introduced above, are the stablecoins, flatcoins, or indexes created through Reserve Protocol that typically (though not necessarily) exhibit yieldbearing properties. They are backed by a governance-defined set of basket assets. The basket can be composed of a common target asset (e.g. all USD collaterals), or it can consist of multiple target assets (e.g. USD and ETH), thereby making it an index of its underlying collaterals. Key features of RTokens include collateral diversification and basket management, yield distribution through an increasing exchange rate, and incentivized over-collateralization.
Each RToken is backed by tokenized assets, such as stablecoins, cryptocurrencies, and real-world assets. The token's governance system determines the composition of the collateral basket, which can be adjusted in response to market conditions and risk factors identified by the stakeholders. RTokens generate yield for their holders by accruing interest and fees from the underlying collateral, distributed through a programmatic revenue-sharing model.
It's important to note that RTokens are highly configurable, although their foundation is in the same RToken framework. Aside from collateral basket variation, there are a variety of access controls and parameters that may influence the efficiency or resiliency of a specific RToken in various market scenarios. Therefore it is important that RToken holders and stakeholders understand the mechanisms and implications of their RToken's specific configuration.
1.3.2 RToken Use Cases
RTokens have many potential use cases and applications within the DeFi ecosystem. Some of the main use cases for RTokens include:
Stablecoins: RTokens can be a reliable and transparent alternative to traditional stablecoins, providing users with a stable store of value and medium of exchange resistant to censorship and inflation.
Yield generation: RTokens allows users to earn passive income by holding the tokens and benefiting from the yield generated by the underlying collateral. This can attract investors seeking to optimize their returns in a low-yield environment.
Collateral for lending: RTokens can be used as collateral for lending and borrowing on DeFi platforms, enabling users to access liquidity without selling their tokens. The stability and yield-generating properties of RTokens make them an attractive collateral option for lenders and borrowers.
Payment and remittance: RTokens can be used as a means of payment and remittance, particularly in regions with unstable local currencies or limited access to traditional financial services. The low transaction costs, fast settlement times, and borderless nature of RTokens make them well-suited for cross-border payments and micropayments.
Portfolio diversification: RTokens can diversify investment portfolios and hedge against market volatility. Holding a basket of uncorrelated assets, RTokens can help mitigate the risk of individual asset failures and provide a more stable return profile.
1.3.3 Creating RTokens
The Reserve Protocol enables the permissionless creation of RTokens through its factory smart contracts. A variety of reference assets can be deployed, ranging from fiat to cryptocurrencies. Collateral baskets can be composed of yield-bearing tokens that have a suitable collateral plugin deployed (e.g. the wstETH collateral plugin may allow the protocol to price wstETH based on the stETH:ETH market price and its internal rate).
Source: Reserve
Reserve offers a UI to deploy RTokens on app.reserve.org. The following steps are involved in the creation of new RTokens:
1) RToken Deployment: Deployment of the RToken involves a unique configuration with the following components:
General Data: Basic information is assigned, including the deployment network, token name, and a written description of the token's mandate.
Collateral Basket: a primary (and emergency) basket of tokenized assets is selected to serve as collateral for the RToken. The basket's composition should be diversified, liquid, and stable, focusing on assets that generate reliable yield.
Revenue Distribution: revenue distribution splits yield from the underlying basket to RSR stakers and RToken holders.
Parameter Configuration: An advanced set of parameter settings influence various aspects of RToken performance, including auction sensitivity, limits on mints/redeems, and parameters involving behavior during emergencies.
2) Governance setup: The creator defines the governance structure for the RToken. This may involve setting up a dedicated DAO, and defining the privileged roles of specific addresses to take protective actions. This also includes specifying parameters such as required quorum and delay on execution. Reserve recommends its own Governor Anastasius (formerly Governor Alexios), a fork of OpenZeppelin Governor, for handling on-chain DAO operations.
The creator deploys the necessary smart contracts for the RToken, including the token contract, the collateral management contracts, and any auxiliary contracts required for yield generation and distribution. These do not need to be deployed individually. Rather, Reserve recommends to deploy through the Deployer.sol contract, which involves two calls to the contract, one of which is shown below for eUSD deployment:
Source: eUSD deployment on Feb-23-2023
1.3.4 RToken Lifecycle and Mechanics
Minting and Redemption
RTokens are minted when users deposit a specified basket of ERC-20 tokens as collateral into the RToken being minted. The BasketHandler contract determines the composition of the collateral basket and can be adjusted through governance mechanisms. To mint RTokens, users must provide the required proportion of each collateral token, as defined by the basket configuration.
Source: Reserve Protocol
Redemption of RTokens occurs when users return their RTokens to the protocol in exchange for the underlying collateral. Reserve Protocol aims to maintain a 1:1 peg between the RToken value and the collateral basket's value, ensuring that users can always redeem their RTokens for the equivalent value of the underlying assets.
Source: Reserve Protocol
Collateralization and Over-Collateralization
The Reserve Protocol maintains the stability and value of RTokens through collateralization and over-collateralization. Collateralization refers to backing each RToken with a basket of tokenized assets, providing a solid foundation for the token's value. The protocol trades at rates such that the collateral basket is always sufficient to cover the value of the minted RTokens, preventing under-collateralization and maintaining the token's peg.
Over-collateralization is achieved through Reserve Rights (RSR) tokens, which RSR holders stake to provide additional protection against collateral defaults and market volatility. When an RToken's collateral value falls below a certain threshold, the protocol automatically triggers an auction to replace the defaulted collateral with a pre-designated emergency collateral and an auction of staked RSR to recapitalize the collateral basket and maintain the token's peg.
Revenue Sharing and Distribution
One of the unique features of the Reserve Protocol is its revenue-sharing model, which incentivizes RSR holders to contribute to the stability and growth of the ecosystem. The collateral assets backing RTokens generate yield through various DeFi protocols and strategies, such as lending, staking, and liquidity provision.
Governance mechanisms determine the exact distribution ratio and can be adjusted to optimize the balance between RToken rewards and RSR staker rewards. RToken holders receive their share of the revenue through an increase in the internal RToken to collateral exchange rate, while RSR stakers receive rewards through an increase in the stRSR to RSR exchange rate.
The `Furnace` contract distributes this revenue among RToken holders. Revenue received by the Furnace is gradually distributed by using a half-life ratio distribution scheme that increases the RToken exchange rate over time. This is a protective measure to mitigate opportunistic frontrunning of large fee distribution events by minting and redeeming immediately following auctions. RSR stakers similarly accrue revenue through the `stRSR` contract.
Source: Reserve Protocol
Governance and Roles
Each RToken has its own governance system, which is responsible for managing the token's collateral basket, revenue-sharing model, and other token-specific parameters. RToken governance is typically conducted through on-chain voting and off-chain discussion forums.
Governance in the Reserve Protocol is designed to be customizable for individual RTokens, although Reserve has an out-of-the-box governance framework it recommends. Governor Anastasius is an on-chain system that allows Reserve RSR holders to gain proportional governance power by staking their tokens on an RToken. At the time of writing, Governor Anastasius is the latest iteration, with the predecessor being called Governor Alexios. We henceforth refer to the governance framework as "Alexios" for simplicity, but note Reserve is currently in a transition process toward Anastasius.
RSR serves multiple purposes when staked on an RToken:
It overcollateralizes the RToken and is the second line of defense to recapitalize in case of a collateral default (after emergency collateral has been traded into a basket to replace a defaulted collateral).
It grants proportional voting power in any votes pertaining to the RToken on which it is staked.
It may earn a portion of the RToken revenue in return for accepting the risk of default and the responsibility to govern the RToken.
The governance system (usually Governor Alexios) has significant power to upgrade the RToken code, modify the collateral basket, and modify parameters. It is essential its ownership access controls are secure, and involve a reasonable timelock on voting snapshot, period, and execution. Alexios can be configured with these values, and by default is set to:
Voting snapshot delay: 2 days
Voting period: 3 days
Execution delay: 3 days
In addition to the Ownership role, RTokens include a Guardian role and Pauser, Short Freezer, and Long Freezer roles that can be set to multiple addresses.
Guardian
The Guardian can reject governance proposals, even if they pass. This role is typically a multisig or trusted EOA and serves as a protective backstop that may be necessary in case of malicious governance takeover. RTokens may be susceptible to governance attacks if they fail to attract a diverse set of stakeholders, making mitigations like the Guardian and reasonable delays on execution a necessity.
Pauser | Short Freezer | Long Freezer
These roles can be assigned to multiple addresses and are intended to offer additional backstop protections with nuance in their trust level. Each role disables different functions, and in the case of short/long freezers, will take effect for different durations. Addresses performing these roles may be bots, and the design is intended to be tolerant of false positives. The Pauser role is considered especially tolerant because it cannot disable redemptions. Whereas the Freezer roles do disable redemptions, they are time-limited and forfeit their Freezer role upon use (6x uses for Long Freezers). This dynamic restricts disruptions potentially caused by compromised addresses without significantly inhibiting efficiency in case of legitimate emergencies.
System States and Auctions
The Reserve Protocol incorporates various system states and auction mechanisms to ensure the stability, security, and efficiency of the RToken ecosystem. These states and auctions help to mitigate the impact of collateral defaults, market volatility, and other adverse events on the protocol and its users.
The main system states of an RToken include:
Fully Collateralized: When the RToken is fully collateralized and the collateral basket in equilibrium, allowing 100% redeemability.
Fully Funded: When the RToken is technically fully collateralized but the collateral basket is not in equilibrium (due to a change in basket makeup or deviation in collateral value accrual), preventing 100% redeemability.
The system strives for full collateralization, and because redemptions necessitate an equal value of all basket assets to be withdrawn, full collateralization is required for full redeemability. When the values of the basket assets are out of the predefined balance beyond a certain threshold, the system will initiate an auction to attempt to bring the basket back to full collateralization.
The Reserve Protocol utilizes two main types of auctions to facilitate the re-collateralization process and maintain the stability of RTokens:
Dutch auctions: A falling-price auction mechanism used to sell off the higher weighted asset fairly and efficiently. Dutch auctions start at a high price and gradually decrease until a buyer is found, ensuring that the protocol can quickly liquidate assets and minimize the impact of defaults. This is the preferred auction type because the pricing curve is resistant to price manipulation and execution is speedier than batch auctions, ensuring better pricing for the protocol. The DutchTrade.sol is designed to handle 4 cases:
Price manipulation of the exchange rate up to 1000x (a defense against any potential price manipulation)
Price movement of up to 50% during the auction
Typical case: no significant price movement; clearing price within expected range
No bots online; manual human doing bidding; additional time for tx clearing
Batch auctions: A multi-unit auction mechanism used to sell larger quantities of assets in a single transaction. Batch auctions are done on Gnosis EasyAuction and allow multiple buyers to participate and purchase assets at a uniform clearing price, reducing the overall transaction costs and improving the system's liquidity. This is a fallback auction type. It is less efficient, requiring the auction to take place over the entire designated window, although may be useful when price manipulation is suspected and manual trading is warranted.**Collateral default state**
When one or more collateral tokens in an RToken's basket fail to maintain their expected value, the protocol attempts to remove exposure from the defaulted asset. This involves an auction to offload the defaulted asset in exchange for the designated emergency collateral type.
The system will likely experience a basket shortfall following such an event, so after collateral rebalancing has been performed, the protocol will respond by attempting to recapitalize. The protocol will auction off RSR staked on the RToken to replenish the collateral basket and restore the RToken's peg. There is a substantial unstake delay from the stRSR contract to prevent stakers from anticipating potential recapitalization events.
Source: Reserve Protocol
1.3.5 Collateral Baskets and Asset Management
The collateral baskets backing each RToken are critical to its stability and in establishing its unique risk profile. Each RToken's basket comprises a diversified mix of tokenized assets chosen for their stability, liquidity, and yield-generating potential. Typically the basket composition will include derivatives of the underlying token, for example, a deposit receipt on a lending platform for an underlying stablecoin that earns interest from borrower demand. There are, therefore, compounding risks associated not only with the underlying asset, but also the composability within various DeFi protocols, and in the diverse array of exposures within the overall RToken collateral basket.
To demonstrate the potential for complex associations within a collateral basket, see the hyUSD RToken on Ethereum below. As of March 25, hyUSD assumed exposure to a basket of stablecoins (eUSD, USDT, DAI, USDC, FRAX), lending platforms (Morpho, Aave), a DEX and yield optimizer (Curve, Convex), and a protocol-native savings contract (MakerDAO). As shown below, the layers of risk exposure within the overall basket can become quite complex to assess.
Source: Reserve App | Date: 3/25/2024
By contrast, RTokens may choose a more conservative approach to the collateral basket composition, as it the case with USD3. It may target a relatively lower yield as a trade-off to strengthen its risk profile. USD3 consolidates its basket within a small number of well-regarded stablecoins and battle-tested DeFi protocols.
Source: Reserve App | Date: 6/3/2024
An RToken's governance system determines the exact composition of the basket, which can be adjusted over time to optimize the balance between stability and returns. There are considerations RToken governors should understand, as the Reserve Protocol employs various asset management strategies to ensure the health and performance of RToken collateral baskets, and these behaviors can be modified through governace actions. These strategies include:
Programmatic price monitoring: The protocol monitors the price of the basket assets through plugin contracts that use a combination of on-chain and off-chain data sources, and typically involve the use of external price oracles. Understanding the oracle and overall market risk of each collateral type is significant to assessing their resiliency and establishing sensible parameters for triggering protocol rebalances.
Rebalancing: When the composition of a collateral basket deviates from its target allocation beyond a threshold defined in the RToken parameters, the protocol enables a rebalancing process to auction assets and restore the desired balance. This helps to maintain full collateralization and redeemability of the basket over time.
Yield optimization: The protocol employs various yield-generating strategies through collateral selection, such as lending, staking, and liquidity provision, to maximize the returns generated by the collateral assets. The generated yield is distributed to RToken holders and RSR stakers according to the token's revenue-sharing model. Stakeholders are entrusted to identify suitable risk/reward attributes of the collateral basket when accounting for composability risk of the onboarded collateral types.
Risk management: The protocol incorporates risk management mechanisms, such as circuit breakers through the assignment of privileged pause and freeze roles, to mitigate the impact of collateral defaults, protocol manipulation attempts, and other adverse events on the RToken. There should be transparency in the design of risk management systems, as these may be off-chain monitoring systems operated by bots to proactively identify unusual activity involving the RToken.
Monetary Units and Basket Dynamics
The Reserve Protocol specifies three monetary units within each Collateral plugin. Together, they allow the RToken to correctly price each Collateral and, consequently, itself. These references allow the protocol to recognize the intended correlation between various assets in the RToken basket and identify default trigger conditions. The main monetary units in the protocol include:
Unit of Account: The internal reference currency used to price all collaterals. This is used, for example, to compare the difference in collateral values and determine when an auction can begin. By default, this is set to USD for all RTokens.
Target Unit: The underlying asset that the collateral/RToken is intended to keep a peg with (or appreciate against) over time. Each collateral specifies a target unit, although an RToken may be an index made up of collaterals with different target units. For example, in ETH+ and its collateral basket, the target unit is ETH.
Reference Unit: Collateral types in RTokens are generally yield bearing receipt tokens for a reference token. The reference unit measures the value accrual from yield generation to compute revenue. The reference and target unit may diverge slightly from exchange rate variation on secondary markets, but if the deviation is significant and longstanding enough, this will trigger a default. For example, for a Compound collateral token cUSDC, the reference unit is USDC while the target unit is USD.
1.3.6 Current RTokens
The Reserve Protocol offers diverse RTokens across Ethereum and Base chains, providing users with various options for stable, yield-generating, and overcollateralized digital assets. These RTokens cater to different user preferences and risk profiles, enabling a wide range of use cases.
The flagship RToken has historically been eUSD, a USD stablecoin backed by the most liquid stablecoins with exposure to the most battle-tested DeFi lending platforms. In recent times, there has been increased growth in ETH+, backed by a conservative set of liquid staking assets. Along with the increased market demand for ETH staking yield, and a general risk-on market attitude, ETH+ has experienced rapid growth in 2024.
The range of RTokens currently available on the Reserve Protocol demonstrates a modest range of stable, yield-generating, and overcollateralized digital assets. To date, only USD and ETH RTokens have come to market, and no general index RTokens. This is likely due to the dominance of USD stablecoins and DeFi integrations that create a wide variety of yield generation opportunities across a wide range of DEXs, lending platforms, and stablecoin platform-native yield. ETH staking has likewise experienced a boom in various liquid staking and restaking opportunities.
While it may be possible that there will be a more diverse array of RTokens that span currencies, commodities, and asset types, USD and ETH are currently the most sensible selections for maximal RToken innovation. As the DeFi ecosystem continues to evolve and mature, new RTokens will likely emerge, further expanding the options available to users and driving the adoption and growth of the Reserve Protocol.
Section 2: Technological Risk
This section covers aspects related to security practices and development activity in the Reserve Protocol and elaborates on technical risks pertinent to RTokens and parameter decisions of individual RTokens.
2.1 Reserve Protocol Technology
2.1.1 Protocol Audits
Over the past years, several security firms have audited the Reserve codebase, namely Trail of Bits, Solidified, Ackee, Halborn, Code4rena, and Trust Security. The audit reports can be found here. Trust Security performed the latest audit between January 9 and October 9, 2023. The audit covered 77 Solidity files from the Reserve Protocol repository, totaling 7,041 lines of code.
The audit was conducted on the codebase at commit hash 722fea63e9fd30802b1278bc9763c9b0fed80d71. The mitigation review, which checked the fixes implemented by the Reserve Protocol team, was performed on the codebase at commit hash 3a4ac7c5f1f8cb269b2dfe941700fd5f41dc90ed.
Key findings:
25 total findings: 4 High severity, 13 Medium severity, 8 Low severity
All findings have been fixed or acknowledged by the Reserve Protocol team
3 findings were acknowledged (1 High severity, 1 Medium severity, 1 low severity)
High-severity findings include:
MorphoNonFiatCollateral deployed with incorrect price feed configuration
Vulnerability allowing an attacker to steal rewards in MorphoAaveV2TokenisedDeposit
Incorrect hasPermission() function called in CusdcV3Wrapper._deposit()
Not all reward tokens claimed in CurveGaugeWrapper
One acknowledged and unfixed high severity finding concerns claiming of reward tokens in the CurveGaugeWrapper. Reserve has explicitly stated in the contract that it will only claim CRV and any other reward tokens to the gauge should be lost.
The Trust Security report details all findings along with additional recommendations, centralization analyses, and a description of systemic risks.
The Reserve team attests that no unaudited changes have ever been deployed. Version 3.4.0 was recently audited by Solidified (Oak Security) and Trust, and the team plans to recommend upgrading RTokens in the coming weeks (as of early-May 2024).
2.1.2 Bug Bounty Program
The Reserve Protocol introduced a bug bounty initiative with a $5 million fund starting on April 27, 2023. This initiative encourages the identification and confidential reporting of system vulnerabilities. Managed directly by the Reserve team, rewards are quoted in USD but paid out in USDC and RSR, ensuring contributors are compensated according to the program's stipulations at the time of report submission. This bug bounty program is the formal agreement for all bug reports and responsible disclosure processes.
Below is the payout structure for the bug bounty program, detailing the reward levels based on the severity of the discovered vulnerabilities. All payouts require a Proof of Concept (PoC) to be eligible.
Source: Immunefi
2.1.3 Immutability
The Reserve Protocol's smart contracts use the ERC-1967 proxy pattern, allowing the RToken implementation contracts to be upgraded by the contract owner. Note that ownership of RTokens is not monolithic; rather it is isolated to each RToken, for which they define access controls individually. While this upgradability allows the system to evolve and adapt over time, it also means the contracts are not completely immutable.
For example, this recent governance proposal upgraded the ETH+ RToken's implementation contracts to version 3.0.0 of the protocol. To help mitigate potential risks associated with upgradeable contracts, the ETH+ RToken has a "Guardian" role assigned to a 3-of-4 multi-signature wallet controlled by the core Reserve Protocol development team. This Guardian can veto any governance proposal, even if it receives enough votes to pass. There is, furthermore, a timelock on vote execution that allows RToken holders multiple days to exit in case of malicious or undesired governance actions.
2.1.4 Developer Activity
DefiLlama tracks the Reserve GitHub for development activity, including the number of daily unique developers and daily commits. Developer activity can be a useful indicator in tracking the pace of development, although it may provide only a cursory view into the diversity of developer contributions and the depth and scope of code commits.
Source: DefiLlama
A list of developers and their contributions can also be found directly on the Reserve Protocol GitHub repo.
Source: Github
2.2 RTokens Technology
2.2.1 RToken Backing Parameters
There are a number of advanced RToken parameters that influence the execution of auctions, place restrictions on minting/redeeming RTokens, and place restrictions on RSR unstaking. These parameters can be divided in terms of protocol optimizations and emergency backstops. The Reserve team has recommended parameter settings that RTokens generally adhere to, but it is important that stakeholders understand how parameter decisions influence the RToken behavior, as governance has control over parameter adjustments.
Protocol Optimizations
These parameters may be considered optimizations that serve to optimize the execution of RToken auctions such that slippage is reduced and auctions execute in a timely manner.
Basket Protections
These parameters may be considered protective measures that aim to mitigate or prevent malicious or unusual interactions with the RToken.
2.2.2 RToken Other Parameters
Additional RToken parameters include emergency backstop actions, handling of rewards distributions, and limits on auctions.
Section 3: Counterparty Risk
This section further explains governance, access control, and potential centralization vectors, subject to decisions behind individual RToken strategies. It also elaborates on legal considerations regarding the overall Reserve Protocol.
3.1 Governance
3.1.1 Governance Scope
Each RToken created on the Reserve Protocol has its governance isolated from other RTokens and controlled by the Reserve Rights (RSR) token holders who choose to stake their RSR on that particular RToken. This means that the governance of each RToken operates independently from one another.
Reserve offers a default governance framework called Governor Anastasius (the latest iteration of Governor Alexios), which RToken deployers can use. Governor Anastasius/Alexios is a modified version of OpenZeppelin Governor, enabling full on-chain governance. The default governance setup involves the following risk mitigation parameters:
Proposal creation to voting snapshot delay: 2 days
Voting period: 3 days
Execution delay after a successful proposal: 3 days
Governance of an RToken extends to contract implementation upgrades, changes to the collateral basket, and control over the variety of parameters that manage auctions and the revenue distribution model for the RToken.
Because there is fragmentation of governance across each RToken, there is an increased risk of a malicious governance takeover, possibly requiring a relatively small amount of capital to secure majority governance power. To mitigate this risk, certain privileged externally owned addresses (EOAs) and multisig wallets can be authorized with a protective influence over an RToken's governance and operations, as defined in the protocol's system states and roles. This importantly includes the Guardian role, which is authorized to veto potentially harmful governance actions.
ABC Labs, the team behind the Reserve Protocol, is actively working on a meta-governance system for the larger RToken ecosystem. The system will add a layer of security to individual RTokens, while also providing stronger mechanisms to bootstrap and incentivize them.
3.1.2 Access Control
The protocol delineates five core roles designed to balance control over the system without introducing unacceptably centralized trust assumptions. These roles are defined in all RTokens:
OWNER: The principal decision-maker, capable of comprehensive system adjustments and upgrades. This should be an on-chain DAO for most RTokens.
PAUSER: Authorized to pause/unpause the RToken system, ensuring rapid response to external events.
SHORT_FREEZER: Empowered to enact short-term freezes on the system, immediately responding to detected vulnerabilities.
LONG_FREEZER: Holds the authority for long-term system freezes, optimizing for zero false positives and acting in critical scenarios.
GUARDIAN: Can veto proposals post-approval as a final check against potentially harmful governance actions. This should usually be assigned to a multisig, as a balance between efficiency and security.
Each role can be held by any Ethereum address designated by the RToken deployer/RToken owner and has the ability to put their RToken’s system into emergency states in the case of an attack, exploit, or bug. System states like "Paused" and "Frozen" are instituted through these roles to safeguard the system, ensuring the integrity and stability of the RToken's operation.
Source: Reserve
The owner of the RToken, being responsible for critical actions within the system, should include a timelock mechanism that is activated upon the approval of a proposal. The timelock introduces a deliberate delay between a proposal's endorsement and its enactment, granting RToken holders adequate time to react to impending alterations.
3.1.3 RSR Governance Tokens
The amount of RSR tokens a participant has staked on a particular RToken serves as their voting weight on the RToken (assuming the RToken uses the default Governor Anastasius/Alexios framework). stRSR holders are allowed to propose and vote on upgrades, collateral basket modifications, and/or parameter modifications to the RToken on which they are staked.
Reserve Rights (RSR) possesses a capped total supply of 100 billion tokens, with 50.6 billion currently in circulation (as of March 2024). The undistributed portion, amounting to 49.4 billion tokens, is allocated to two specific wallets: the Slow Wallet and the Slower Wallet.
The Slow Wallet is under the control of Confusion Capital, an entity unveiled in January 2024 tasked with overseeing funds for the broader Reserve Ecosystem's development. It is a locked wallet with hard-coded 4-week withdrawal delay conditions. Likewise, the Slower Wallet is also managed by Confusion Capital. The same withdrawal delay applies with extra restrictions - no more than 1% of the total supply of RSR can be withdrawn in any 4-week period.
3.2 Legal
3.2.1 Legal Structure
Reserve Protocol currently operates without a formal legal framework or entity designed to safeguard the interests of token holders or provide legal protections. Discussions within community forums have yet to suggest any imminent plans to establish such a structure.
The first user interface that leverages the Reserve Protocol's smart contracts is accessible via app.reserve.org. It was developed by ABC Labs, an organization that plays a pivotal role in shaping the legal and operational framework surrounding the Reserve Protocol.
A search conducted through OpenCorporates revealed multiple entities bearing the name ABC Labs. The one incorporated in Delaware, recognized for its favorable conditions for startups and tax benefits, captured our attention due to its expansion into three additional states. However, the lack of public access to detailed information about ABC Labs' shareholders and directors limits our sight of the company's ownership structure.
3.2.2 Licenses
The Reserve Protocol is architected as a decentralized platform enabling the permissionless creation of asset-backed, yield-bearing, and overcollateralized stablecoins on the Ethereum blockchain. Its design facilitates unrestricted interaction with a suite of smart contracts or through independent front-ends, empowering users to launch their preferred tokens.
The legal and regulatory framework specifically tailored to decentralized protocols still needs to be defined. Nonetheless, the Financial Action Task Force (FATF) has initiated efforts to classify certain DeFi arrangements under the definition of Virtual Asset Service Provider (VASP), potentially invoking AML/CFT obligations. Regulatory scrutiny could extend to individuals possessing administrative keys, participants in governance structures (including governance token holders and DAO members) based on their influence and control over protocol modifications, application managers interfacing with DeFi arrangements, promoters of DeFi initiatives, and those responsible for protocol updates or profit/fee models. Regulatory responses are expected to vary by jurisdiction, setting a foundational basis for oversight.
The International Organization of Securities Commissions (IOSCO)'s stance, closely aligned with that of the Financial Action Task Force (FATF), emphasizes identifying individuals and entities that exert control or significant influence over DeFi arrangements or activities. These entities, called Responsible Persons, play pivotal roles that could bring them within the ambit of regulatory oversight. IOSCO's guidelines highlight a comprehensive range of actors potentially considered Responsible Persons, including founders and developers, those with administrative rights to smart contracts and a protocol, those who have or take on the responsibility of maintaining/updating the protocol or other aspects of the project, such as access rights, those who are promoting the use of the protocol through, for example, providing a user interface or otherwise facilitating interaction with the protocol, and releasing updates to the protocol, etc.
While IOSCO's recommendations are advisory, the organization's influence is significant enough to impact national regulatory frameworks.
Conversely, protocols that achieve genuine decentralization may argue against imposing regulatory burdens. Although "legal decentralization" lacks a formal definition, insights can be gleaned from the Howey test's fourth criterion regarding protocols with U.S. touchpoints. It is argued that if a system is "sufficiently decentralized," applying securities laws to its digital assets may be deemed unnecessary. A highly decentralized operation, lacking a central authority or management, challenges the identification of an issuer or registrant for SEC purposes, rendering securities law applications impractical.
However, app.reserve.org presents a distinct scenario through its explicit dependency on ABC Labs, which has a presence in the USA. As stated on its website, app.reserve.org is an open-source project curated by ABC Labs, marking it the inaugural dApp to interact with the Reserve Protocol and its associated RTokens.
Given that app.reserve.org can be used to interact with or view information related to RTokens; it is imperative to scrutinize the protocol operations it supports, including deploying and redeeming RTokens. Assuming the Reserve Protocol's decentralization is adequately established to negate VASP classification, app.reserve.org could be a gateway to a suite of services potentially subject to diverse regulatory standards and specific licensing prerequisites.
The legal architecture of Reserve Protocol is constructed with regard to the clarification provided on the status of DApp Developers within the FinCEN Guidance on Convertible Virtual Currencies (CVC). According to this guidance, the act of developing a Decentralized Application (DApp) does not in itself constitute the role of a money transmitter, even if the DApp's functionality includes issuing a CVC or facilitating financial transactions denominated in CVC.
In adherence to this principle, the team revealed that ABC Labs, in its role as a DApp developer, is positioned such that it does not engage in activities classified as money transmission, provided it neither utilizes nor deploys the DApp for such purposes.
3.2.3 Enforcement Actions
Based on the available information from the searches, there is no direct mention of lawsuits brought by regulators specifically against the Reserve Protocol or ABC Labs. The search results did not reveal any recent regulatory enforcement actions or announcements targeting Reserve Protocol or ABC Labs by the Securities and Exchange Commission (SEC) or the Commodity Futures Trading Commission (CFTC).
3.2.4 Sanctions
In the context of international sanctions compliance, the role of U.S.-based entities, such as ABC Labs, which maintains the front-end for the Reserve Protocol, garners particular scrutiny. The Illicit Finance Risk Assessment of Decentralized Finance, conducted by the U.S. Department of Treasury, underscores the AML/CTF obligations, alongside sanctions compliance for DeFi services connected to the U.S. Such entities, recognized as U.S. persons, are mandated to adhere to the economic sanctions programs overseen by the Treasury's Office of Foreign Assets Control (OFAC). These compliance requirements remain steadfast, irrespective of the transactions conducted in virtual assets or traditional fiat currencies.
The current state of the protocol interface, which lacks a compliance program, presents a vulnerability the impact of which is hard to estimate. In theory, regulators may initiate actions against protocols deemed non-compliant with sanctions program. Reserve has not been subject to any such actions in conjunction with our findings in 3.2.3.
3.2.5 Liability Risk
When examining the potential legal liability faced by the Reserve Protocol and affiliated entities, it is essential to delineate the relationship between the user and the service provider. A legal risk analysis aims to identify the counterparty in this relationship, which is crucial for understanding legal obligations and potential liabilities.
app.reserve.org, highlighted as the primary dApp to interface with the Reserve Protocol and ABC Labs, recognized as the maintainer of this interface, is of particular interest. The absence of publicly available Terms and Conditions (T&C) for app.reserve.org introduces significant legal uncertainties. With explicit T&Cs, determining the platform operator's responsibilities becomes easier, leaving a gap in defining the legal relationship and obligations towards users.
The absence of stipulated governing law or choice of forum clauses complicates users' pursuit of traditional legal remedies, such as lawsuits or arbitration. This lack of clarity undermines consumer protection mechanisms, leaving users with limited dispute recourse.
The lack of explicit disclaimers and liability limitations further exposes the operator to potential legal claims. With these provisions, delineating the bounds of liability for losses incurred by users due to operational failures or inaccuracies within the dApp becomes easier.
Risk notifications are provided in the protocol documentation and positioned into three categories - Smart Contracts, Collateral Assets, and Interfaces. Users are encouraged to proactively seek clarification and engage with the community via Discord to deepen their understanding of potential risks.
The notifications highlighted address essential risk categories. Nonetheless, the legislative landscape regarding the requisite structure and content of material disclosures for DeFi products and services must be clarified. In a traditional financial context, disclosures are pivotal in ensuring that investors and users are fully informed about the potential risks, costs, and operational frameworks of the financial products or services they engage with. These disclosures typically include information about the issuer, detailed risk assessments, cost structures, governance mechanisms, applicable legal frameworks, and comprehensive financial data or other relevant specifics tailored to the product or service.
Currently, there needs to be standardized disclosure requirements tailored to the offering or sale of crypto assets in DeFi, as set forth by any competent authority.
3.2.6 Adverse Media Check
Upon conducting searches for adverse media and potential regulatory concerns related to Reserve Protocol, app.reserve.org and ABC Labs LLC, the specific entities themselves, did not yield direct results in the context of money laundering, corruption, sanctions exposure, threat financing, or other unlawful activities within the searched content.
Section 4: Risk Disclosures Summary
This section compiles pertinent risk considerations that may be inherent to the Reserve Protocol or subject to individual RToken strategies, defining their unique risk profile.
4.1 RToken General Risk Disclosures
Each RToken strikes a balance in terms of strategy aggressiveness versus how much risk it considers acceptable. A general RToken mandate is stored in each RToken contract that expresses generally the goal of the RToken to assist governance stakeholders in conforming their decisions to embody a particular risk profile. Regardless of a declared mandate, each RToken should strive to eliminate unnecessary risks and, indeed, its stakeholders are incentivized to promote confidence through transparent and responsible management. This section lays out several of the primary risk considerations for RToken strategies as well as general RToken risk considerations.
4.1.1 Collateral Basket
There are several layers of risk present in the selection of the collateral basket, relevant to all RTokens:
Reference Asset Peg Risk
The reference asset refers to the underlying stablecoin or pegged asset within the RToken collateral basket. There are a wide variety of pegged assets issued by centralized issuers in various jurisdictions or decentralized protocols. each with unique designs. Each asset has its own risk profile and may lose its peg, either temporarily or permanently.
Additional considerations include:
There may be counterparty risks associated with collateral tokens that can result in restrictions by issuers or custodians that can affect asset transferability and protocol interaction.
The health of reserves backing pegged assets is critical and requires due diligence. Centralized issuers may have varying degrees of regulatory oversight that restricts management of the reserves or requires regular audits
Decentralized stablecoins are susceptible to a host of risks that range from smart contract bugs to reliance on external oracles or involve centralization vectors in operational management.
Pegged assets may not be readily redeemable, or otherwise may struggle to maintain their peg on secondary markets depending on structural design decisions or market-related scenarios that make them vulnerable to manipulation. RToken default events can be triggered from such scenarios, which may result in a shortfall that requires recapitalization.
DeFi Composability Risk
DeFi composability is an inherent aspect of RTokens' ability to generate yield. RTokens depend on external protocols, inheriting their risks, including those related to smart contracts and governance. In some cases, there may be multiple layers of contracts involved in optimizing yield, for example, a yield optimizer built on a DEX venue. Each layer increases the risk surface area which may lead to partial or total loss of funds.
Basket Diversification
Diversification of the collateral basket is a strategy to distribute risk such that the default of one collateral type cannot result in a total loss to RToken holders. However, the yield potential may not necessarily compensate for the additional risk surface area, especially given the frequency and scale of hacks in DeFi historically.
RSR Overcollateralization
RTokens greatly benefit from the additional assurance of being overcollateralized by RSR staked on the RToken. Various factors related to the RSR token and staker behavior may affect the RToken's ability to recapitalize in case of a collateral default. Stake behavior may be influenced by revenue earned on the RToken individually or in competition with other RTokens. Extraneous factors influencing the market for RSR may result in illiquidity or rapid depreciation that makes recapitalization unviable.
Oracle Risks
Reserve collateral plugins depend on external oracles for price data can negatively affect protocol operations if the data is inaccurate, either due to manipulation of the price source or manipulation/failure of the oracle itself. In case of inaccurate oracle reporting, an RToken may incorrectly determine a collateral has defaulted and trigger an auction. Monitoring the oracle behavior and its continued efficacy is important to maintain the smooth operation of the RToken.
4.1.2 Governance and Access Control
Governor Anastasius/Alexios
Governor Anastasius (preceded by Governor Alexios) is the preferred RToken governance framework that allows RSR holders to stake on their preferred RToken for governance power. It is expected that all RTokens of any repute will likely opt for this framework as it offers a convenient avenue for decentralized governance with built-in risk mitigation features. There are, however, governance risk factors to note:
RToken governance is fragmented, meaning each RToken has a unique set of stakeholders that only govern the RToken they stake on. Fragmentation reduces the diversity of independent stakeholders and may make governance more susceptible to takeover by a single entity or individual. ABC Labs attests to be developing a meta-governance framework that may offer additional protection to individual RTokens.
Decentralized governance is generally required to sacrifice speedy execution in favor of user assurances. Shortening the timelock on execution may allow the RToken to respond quickly to emergencies, but may make it more susceptible to governance attack (i.e. an actor attempts to quickly pass a malicious vote for personal gain). By opting for a long timelock, the protocol becomes more dependent on special pauser/freezer roles to act in an emergency.
Special Roles
Special roles include the Short Freezer, Long Freezer, Pauser, and Guardian. Each RToken may have a unique strategy in how they assign these roles and employ off-chain monitoring tools to make the best use of these roles. Ultimately, they all control slightly different functionalities to serve the same purpose of being an emergency backstop to prevent the loss of RToken funds. They are designed with a distribution of powers to limit their potential disruption to the protocol and maximize efficiency in their emergency action. There are some considerations to note:
Freezers and Pausers can consist of multiple addresses and they are likely to include EOAs that are operated by bots. This may increase the chance of triggering a false positive or in having the address compromised. Pausers, in particular, are designed to have some tolerance for false positives, as they do not disable RToken redemptions.
The Guardian plays an important role in governance by vetoing potentially malicious governance actions. As mentioned above, RToken governance fragmentation and behaviors around RSR staking may increase the risk of governance attacks, and the Guardian is intended to deter any attempt. The Guardian should be configured such that it is reasonably secure via multisig, but is efficient enough to veto when needed.
In general, the emergency backstops may be necessary to quickly respond to prevent loss of funds in the collateral basket. These roles tend toward a centralization vector, where the protocol depends on these entities to operate swiftly and correctly. This presents a tradeoff in the RToken system that involves centralized actors with limited access control to mitigate harm to the RToken system while entrusting them to act when necessary.
4.1.3 Parameter Selection
RTokens should be configured with parameters that anticipate expected behavior and balance efficiency gains with prudent protective measures. Parameter decisions influence:
Aspects of the protocol auctions include the necessary thresholds when an auction is triggered, the length and frequency of the auction, and slippage tolerance. Improper setting may result in excessive auctioning, an inability to execute a legitimate auction, or auctions with poor execution. Losses from auctions may result in a basket shortfall that requires recapitalization.
Conditions for RSR stakers, including the delay on unstaking, proportion of fee revenue, and the "withdrawal leak" (the amount of RSR that can be unstaked before triggering a basket price update). These conditions on stakers may strike a balance between offering attractive incentives to stakers versus providing sufficient assurances to RToken holders of the RSR overcollateralization buffer.
Issuance and Redemption restrictions are intended to place reasonable limits that are likely only to occur due to an exploit. The restrictions do not completely prevent losses but may limit certain exploits, such as an MEV leak that allows an attacker to siphon collateral basket funds through arbitrage in large volume. This mitigating limitation may allow special roles and governance time to step in by freezing protocol actions and implementing upgrades to patch the vulnerability.
4.1.4 Auctions Risk
Auctions may not execute as intended, causing the protocol to realize a loss that results in a basket shortfall and a need to recapitalize from RSR staked on the RToken. There may be several scenarios where auctions do not perform as intended:
MEV searchers or manual auction participants are not operating an efficient market, resulting in trades executing at less favorable rates.
High blockchain gas fees increase the cost of execution, resulting in less favorable rates for the protocol.
Auctions can involve fairly substantial delays in execution, and the automated design for triggering and executing auctions in the RToken system generally involves multiple delay periods. The lengthened exposure may result in less favorable execution, especially in default scenarios when the collateral marked for offloading may be rapidly depreciating.
There may be oracle price manipulation that prevents the Dutch Auction from properly identifying the fair price of the auctioned asset. Batch auctions can be used as a fallback, which are designed to operate properly even during oracle manipulation, with the caveat that they remain open for the full auction duration.
4.2 Conclusion
The information in this report provides a general outline of Reserve Protocol and the RToken standard, along with general risk considerations pertinent to all RTokens. The report serves as a reference to supplement subsequent risk reports covering specific RTokens as they are assessed for suitability as collateral asset onboarding to third-party lending platforms and decentralized stablecoins.
Subsequent evaluations of individual RTokens will include a custom scoring system that considers the risk profile of the RToken in terms of both inherent risks due to its configuration and observed market and adoption trends that may give insight into its suitability as a collateral asset. The score will be divided into several categories:
Collateral Basket: The relative asset risk exposure in the makeup of the collateral basket, accounting for historical modifications to the basket.
Parameter Config: The parameter configuration of the RToken, accounting for historical modifications to parameters.
Governance: The governance model employed by the RToken and observed trends in governance participation, actions, and RSR overcollatralization.
Market: The RToken usage in DeFi markets, accounting for current and historical liquidity depth, adoption trends and consideration of any historical depeg events.
We will provide general guidance on the risk profile of the RToken based on our analysis of these categories along with a category score based on comparative analysis of the overall RToken market.