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.