# Resupply Finance: Auditor Roadmap

Resupply is a CDP-based lending protocol with the aim of allowing simple, low-risk, leveraged yield farming while encouraging the use of value-added ecosystem protocols' underlying stables like Curve's crvUSD and Frax's FRAX. Resupply is a modified fork of Fraxlend, from which some naming is inherited (e.g. we use "pair" to refer to each collateral deposit contract).

## Core Protocol

### Collaterals and Oracles

- Collaterals should all be 4626-compliant lending positions that use crvUSD and Frax as the supply token. Such as tokenized deposits from Curve's Llama Lend and Frax's Fraxlend.
- Collaterals will all be considered stable - i.e. the system will trust that the `underlying` asset (FRAX, crvUSD) has a price of $1.
- This simplifies a lot of the logic, as well as facilitating the goal of increasing crvUSD and FRAX adoption.

### Fees:

- Borrow interest rates will be half the APR of the lending product, half the “risk free rate” using sfrax as an oracle, or 2%, whichever value is greater.
- Mint fees are programmed in but currently undecided if it will be used. Further, it's plausible that having a mint fee present can serve as an economic defense against certain scenarios.
- There will also be redemption fees, which are shared between:
- borrowers (who receive in terms of an extra debt write off)
- the protocol (received as debt tokens, forwarded to governance stakers).
- Planned, but not yet implemented is a `RedemptionFeeCalculator.sol` which is designed to dynamically modify the redemption fee based on time-since-last-redemption. The aim is to prevent a situation where some pairs get redeemed against far more frequently than others.

### CDP logic:

- Users will create collateralized debt positions, deposit their chosen collateral into the "pair" (term for the contract which holds collateral and issues debt), and mint (up to a debt cap) in accordance with the pair's parameters.
- The CDP's logic is a modified fork of Fraxlend.
- Changes include:
- "single supplier" issuance of a stablecoin, rather than user supplied liquidity (removed isolated pairs).
- Introduction of an Insurance Pool
- Modified liquidation flow: liquidations are funded from a pool of deposits rather than from the liquidator himself
- Redemptions: a peg stability mechanism which allows for permissionless exhange of system stablecoin for user collateral.
- Reward system for issuing token incentives to users
- Underlying based interest rates instead of utilization based
- Oracles
- Change in how admin fees are handled

### Insurance Pool + Liquidations:

- The Insurance Pool is a vault-like contract to which users supply system stablecoin (reUSD) in exchange for shares.
- Deposits will be incentivized, as they are required for the system to execute liquidations in the event of user positions becoming unhealthy, or bad debt accruing to a pair.
- Liquidations tap into the insurance pool to pay off debt of the liquidated user in exchange for collateral. Thus no flashloans or swaps are needed on behalf of the caller. Just a simple execution that removes debt from the pool and transfers collateral.
- After liquidation is complete:
- the Insurance Pool share price will decrease as a result of losing backing assets
- Insurance Pool depositors will have new collateral-underlying available to claim
- the collateral will move to the Liquidation Handler contract which attempts to withdraw all the underlying tokens. If there is not enough liquidity it will wait for the next call to withdraw.

### Redemptions:

- Similar to Liquity (and other forks like Prisma), redemptions serve as a floor mechanism by allowing anybody to redeem collateral from the system in exchange for units of debt tokens that the system prices at $1.
- Unlike Liquity/Prisma, its implementation should maximize capital efficiency, while minimizing pain and sophisticated management for the user. For this reason, Resupply is introducing a novel redemption mechanism which targets debt holders in a socialized way based on shares rather than individualized way based on sorting.
- Because FraxLend pairs use shares to denominate debt, it is a nice starting point for us to evenly distribute redemptions across all users' remaining debt for a given pool. Erasing debt is straightforward from a FraxLend implementation perspective, but applying it equally to collateral required a few changes.
- Beyond expressing debt as shares, the other key component is the introduction of a debt write-off "token". This is not a transferrable token. It is minted during a redemption and distributed to debt holders proportionally to represent the amount of collateral which was taken. Thus, actual collateral should now be represented by the userCollateral mapping subtrated by the value of their write off tokens.
- Debt write off tokens will be distributed via established logic within rewards distribution in other systems.
- Additionally, fee to redeem, so it's not exactly 1:1. For instance, if 1 reUSD returns 0.99$ in collateral, the borrower pool receives the remaining 0.01$ as profit. The token would have a soft floor below 1. This redemption fee can also be dynamic, growing as it is used, creating a "buy the dip" period for users who prefer to buy and hold or pay back, as opposed to buying and redeeming.
- The spread should include a protocol fee. Some or most of the gains go back to the pool users, while the protocol can take a percentage.
- Other factors, beyond platform revenue, may necessitate fees on redemptions. For example, if redemptions were 1:1, you could force collateral to withdraw and create high lending rates for the remaining depositors.
- As with liquidations, the underlying may not be fully redeemable at any given time due to it being a lending product. In current implementation, redeemer may choose which pool to redeem from.

## Governance

### Tokenomics:

RSUP tokens will be minted in two phases:
1. **One-time** mint at token generation event (TGE).
- RSUP governance tokens will be distributed to predetermined groups of stakeholders.
- The chart below outlines a hypothetical TGE distribution scenario.
- All TGE tokens will be distributed via vesting in `VestManager.sol`. Different groups have different vesting durations and allocations. The clock on vesting begins for all user vests at the system start time, regardless of when claims are made.
- Convex and Yearn will each receive their TGE tokens to a speacial-purpose `PermaStaker.sol` contracts which are limited only to staking.
2. **Continuous** emissions will be distributed as unlocked tokens (no vest), to incentivize actions which promote the health of the system.
- Emissions are are defined in `EmissionsController.sol`, which will serve as the sole RSUP token minter.
- The emissions rate and schedule will be controlled by the RSUP DAO and can be adjusted on an as-needed basis via governance proposals.


### Emissions

- The system gives emissions to contracts called `Receivers`, which can be any contract that complies with the basic interface.
- To register a receiver for emissions, governance must call `EmissionsController.registerReceiver(receiver)`. Once registered, and given a weight, it can begin accumulating emissions each epoch.
- Receivers can be built directly into a contract that serves some other purpose, or alternatively, we have a factory (`SimpleReceiverFactory.sol`) which can deploy generic receivers to be used for nearly any use case.
- The diagram below describes the intended emissions flow to two main targets: Insurance Pool deposits, and Borrowers.
- 

#### Borrow rewards
- Borrow rewards aim to be entirely algorithmic, incentivizing the pools that generate the most revenue.
- All protocol pairs claim their emissions from the same contract, according to weights set in `SimpleRewardStreamer.sol`. Each pair is given a "weight" according to its rate of revenue contributed (interest earned to the protocol) since it's last checkpoint.

### Ownership and Configuration

- `Core.sol` is the main owner of all contracts. It is a simple contract with execute function that allows for arbitrary calls.
- A single `Voter.sol` contract exists separately from Core. While Core owns all contracts, the voter is able to execute any transaction as if it were Core.
- Operator contracts may be introduced by the DAO at any time. These contracts may be granted more granular access to Core. An example may be a guardian operator, which is a contract with access to the `pauseProtocol()` function.
- Access is given to operators based on target + function selector combinations. And can optionally be limited by adding pre and post hooks.
### Governance Staking
- Stakers of RSUP tokens earn protcol revenue, and perform governance voting. Unstaking is subject to a cooldown period in which no rewards are granted.
- The staking contract works on an epoch system. The epoch length with likely be set to 1 week.
- Rewards are distributed immediate upon staking, and cesase immediately upon unstake.
- New stakes must endure a warm up period (e.g. 1 epoch) before they are granted goverance voting power.
- Technically, governance voting is still possible while in cooldown due to how the weights are snapshotted.