DTFs Additional Risks
Goal of this is to document risks that we want to disclose on app.reserve.org about Index DTFs
The Reserve protocol (the “Protocol”) may include coding errors or otherwise not function as intended, which may negatively affect the Protocol and DTFs. Although the Protocol and DTFs have undergone significant technical audits, there is no guarantee that they will be free of errors or otherwise not function as intended.
Because DTFs exist on Ethereum and/or Base, any malfunction, breakdown or abandonment of the Ethereum or Base protocols may have a material adverse effect on DTFs. Moreover, advances in cryptography, or technical advances such as the development of quantum computing, could present risks to DTFs, including their utility, by rendering ineffective the cryptographic consensus mechanism that underpins those protocols.
The prices of cryptocurrencies have historically been subject to dramatic fluctuations and are highly volatile, and the market price for DTFs may also be highly volatile. Several factors may influence the market price of DTFs, including, but not limited to: (1) Global supply of cryptocurrencies generally, including those that may be held as collateral for DTFs; (2) Global demand for cryptocurrencies, which can be influenced by the growth of acceptance of cryptocurrencies; (3) Interruptions in service from or failures of major cryptocurrency exchanges; and (4) Investment and trading activities of large investors.
DTFs may be subject to expropriation and/or theft. Hackers or other malicious groups or organizations may attempt to interfere with the Protocol or with DTFs in a variety of ways, including but not limited to malware attacks, denial of service attacks, consensus-based attacks, Sybil attacks, smurfing and spoofing. Furthermore, because the Protocol is open-source software, hackers or other individuals may uncover and exploit intentional or unintentional bugs or weaknesses in the Protocol.
It is up to the deployer of the DTF to determine what governance model to use to govern the DTF. Some DTFs will have centralized governance, whereas others will have decentralized governance. If governance is sufficiently centralized, it can execute a governance attack on its DTF, which could adversely affect the value of the DTF. Such attacks could be the result of malicious behavior (e.g. rug pull), incompetence (e.g. swapping into a known bad token or swapping into the wrong asset), or poor decisions.
The effectiveness of the Auction Launcher depends on properly executing the Dutch auction mechanism. Poor auction design, such as setting subobtimal prices or decreasing prices too slowly, could result in assets clearing at suboptimal prices or increasing costs for the protocol. Additionally, if the auction parameters fail to adjust to market conditions, such as periods of extreme volatility or liquidity shortages, the mechanism may struggle to clear assets at fair market value.
For collateral backing, some DTFs use wrapped crypto assets, which are tokenized representations of underlying cryptocurrencies issued on different blockchains. While wrapped assets are designed to maintain a 1:1 peg with their underlying assets, they rely on third-party custodians, smart contracts, and/or interoperability protocols, which introduce additional risks. These risks include, but are not limited to, counterparty risk from centralized custodians, smart contract vulnerabilities, liquidity constraints, and potential regulatory scrutiny that could impact the redemption or transferability of the wrapped assets. Market volatility, network congestion, or changes in blockchain consensus mechanisms may also impact the value and accessibility of the wrapped assets. Any of these risks could negatively affect DTFs and their underlying wrapped collateral assets.
Using the Zapper to mint or redeem a DTF may result in slippage and price impact. When executing transactions, especially large ones, automated market makers and decentralized exchanges may adjust pricing based on available liquidity, resulting in a final execution price that differs from the expected price. Additionally, the process of swapping multiple assets to mint or redeem the DTF may create price impact, particularly if such markets are illquid. In volatile market conditions, slippage and price impact risks may be amplified.
Past performance is not indicative of future results. Different DTFs have varying degrees of risk, and there can be no assurance that the future performance of any specific DTF or investment strategy will be profitable, equal to any corresponding indicated historical performance level(s), or be suitable for your portfolio.
We do not have any control over the name or mandate of any DTFs. Accordingly, the basket of assets actually backing a DTF may be very different than what is described in the name or mandate. Images and branding of a DTF may also be misleading. There may be DTFs with the same or substantially similar name, which may lead to confusion about which DTF someone is purchasing.
The regulatory status of cryptocurrencies and blockchain technology is unclear or unsettled in many jurisdictions. It is difficult to predict how or whether governmental authorities will regulate such technologies. It is likewise difficult to predict how or whether any governmental authority may make changes to existing laws, regulations and/or rules that will affect cryptographic tokens, digital assets, blockchain technology and its applications. Such changes could negatively affect DTFs and the Protocol.
In a similar way as how anyone can create a new trading pair on Uniswap, anyone can permissionlessly create a new Reserve stablecoin (RToken) by interacting with Reserve Protocol’s smart contracts. The protocol applies a system of factory smart contracts that allows anyone to deploy their own smart contract instance.
Creating an RToken can be done either by interacting directly with the Reserve Protocol’s smart contracts or any user interface that gets built on top of it. The first user interface for these smart contracts will be released by ABC Labs the company that's leading protocol development. Besides the creation of RTokens, this user interface will also support exploring usage and stats related to RTokens, RToken minting & redeeming, and RSR staking.
The following types of ERC20s are not supported to be used directly in an RToken system. These tokens should be be wrapped into a compatible ERC20 token to be used within the protocol. A concrete example is the use of Static ATokens for Aave V2.
When deploying an RToken, the deployer has the ability to configure many different advanced parameters. The following list goes into detail about what these parameters do and some of the factors the deployer should keep in mind to set them.
As many of these parameters concern the Protocol Operations, we advise reading through that section of the documentation first—as it will give the deployer the necessary context to fully understand all parameters.
The trading delay defines how many seconds should pass after the basket has been changed before a trade can be opened.
A collateral asset can instantly default if one of the invariants of the underlying DeFi protocol breaks. If that would happen, and we would not apply a trading delay, the protocol would react instantly by opening an auction. This would give only auctionLength seconds for people to bid on the auction, making it very possible for the protocol to lose value due to slippage.
The trading delay parameter may only be needed in the early days - before we get to a point where there is a robust market of MEV searchers. We expect that this parameter can be set to zero later on (once a robust market of MEV searchers is established).
