From d4eba7fa9393a5912e921af9ae28c45c114c25a3 Mon Sep 17 00:00:00 2001 From: Taylor Brent Date: Fri, 6 Sep 2024 21:24:45 -0400 Subject: [PATCH] docs cleanup --- docs/build-on-top.md | 17 ----------------- docs/collateral.md | 4 +++- docs/system-design.md | 16 ---------------- 3 files changed, 3 insertions(+), 34 deletions(-) delete mode 100644 docs/build-on-top.md diff --git a/docs/build-on-top.md b/docs/build-on-top.md deleted file mode 100644 index 8a777f5168..0000000000 --- a/docs/build-on-top.md +++ /dev/null @@ -1,17 +0,0 @@ -# Building on Top of Reserve - -TODO -- this document is a work in progress. - -## Overview - -Reserve uses a long-lived Tenderly fork as the main testing environment. Since the Reserve Protocol is a meta-protocol it relies on functional building blocks that are not all present on testnets such as Goerli or Sepolia. For this reason it makes the most sense to use a fork of mainnet. - -Unfortunately it would be bad practice to share the RPC publicly. Please reach out at protocol.eng@reserve.org to request we share the RPC privately with you. - -## Chain - -We re-use the chain ID of 3 (previously: ropsten) for the Tenderly fork in order to separate book-keeping between mainnet and the fork environment. - -- [Core Contracts](../scripts/addresses/3-tmp-deployments.json) -- [Collateral Plugins](../scripts/addresses/3-tmp-assets-collateral.json) - - Note that oracles require special logic in order to be refreshed and for these plugins to function correctly. diff --git a/docs/collateral.md b/docs/collateral.md index 9a98938c24..1d767a1d9c 100644 --- a/docs/collateral.md +++ b/docs/collateral.md @@ -388,9 +388,11 @@ Should never decrease. The plugin should monitor this value for decrease in its Should be gas-efficient. +Should return a nonzero value in the range of 1e9 to 1e27. + ### targetPerRef() `{target/ref}` -Should never revert. Must return a constant value. Almost always `FIX_ONE`, but can be different in principle. +Should never revert. Must return a constant nonzero value. Almost always `FIX_ONE`, but can be different in principle. Should be gas-efficient. diff --git a/docs/system-design.md b/docs/system-design.md index 22128c989f..3c5188d5c8 100644 --- a/docs/system-design.md +++ b/docs/system-design.md @@ -36,22 +36,6 @@ Some of the core contracts in our system regularly own ERC20 tokens. In each cas 1. During minting, the `RToken` transfers collateral tokens from the caller's address into itself and mints new RToken to the caller's address. Minting amount must be less than the current throttle limit, or the transaction will revert. 2. During redemption, RToken is burnt from the redeemer's account and they are transferred a prorata share of backing collateral from the `BackingManager`. -## Protocol Assumptions - -### Blocktime = 12s - -The protocol (weakly) assumes a 12-second blocktime. This section documents the places where this assumption is made and whether changes would be required if blocktime were different. - -#### Should-be-changed if blocktime different - -- The `Furnace` melts RToken in periods of 12 seconds. If the protocol is deployed to a chain with shorter blocktime, it is possible it may be rational to issue right before melting and redeem directly after, in order to selfishly benefit. The `Furnace` should be updated to melt more often. - -#### Probably fine if blocktime different - -- `DutchTrade` price curve can handle 1s blocktimes as-is, as well as longer blocktimes -- The `StRSR` contract hands out RSR rewards in periods of 12 seconds. Since the unstaking period is usually much larger than this, it is fine to deploy StRSR to another chain without changing anything, with shorter or longer blocktimes -- `BackingManager` spaces out same-kind auctions by 12s. No change is required is blocktime is less; some change required is blocktime is longer - ## Some Monetary Units Our system refers to units of financial value in a handful of different ways, and treats them as different dimensions. Some of these distinctions may seem like splitting hairs if you're just thinking about one or two example RTokens, but the differences are crucial to understanding how the protocol works in a wide variety of different settings.