• lock up synths
• count up weight based on getValueInBase()
• allow harvesting interest

DEPLOYER should be able to over-ride DAO in all contracts until purged

Not all the pools should receive incentives/lending/protection, else can be attacked.

Anchor pools: only listed pools (hard to attack).
Asset pools: only deepest X, where X is set by governance. Individual pools can be removed by governance.

An inflation event can cause loss of the peg from USDV->VADER.

DAO can bump maxSuppply, no more than 10% at a time.

VADER should send emissions to the RESERVE.

RESERVE should be init'ed with the addresses of ROUTER, VAULT, LENDER.

These contracts can request funds (limited), and RESERVE will send.

This removes complicated RESERVE logic from the rest of the system.

If VADER supply goes too high, should add penalty for redeeming back to it, which increases the closer to maxSupply

Have some requests for this in the near future to cater to non EOA and enterprise accounts.

Currently all the contracts use pragma solidity ^0.8.3. The ^ leaves some wiggle room. I don't see what difference it would make, but pragma solidity 0.8.3 (no ^) would make it clear exactly which solc had compiled the sources.

https://docs.soliditylang.org/en/v0.5.10/natspec-format.html#natspec-format

Adjustable limits for:

• USDV Staking
• Anchor Pools
• Asset Pools

https://docs.soliditylang.org/en/v0.8.3/contracts.html#visibility-and-getters

contracts

Router

• has all logic

Vault

• has all assets

Implementation

add liquidity

• forwards to vault, adds member
• member share in vault
• deposit data in vault

remove liquidity

• redeems based on member share

IL Protection

• redeems via Router
• calc IL protection, add baseAmount
• send to member

swap

• calls underlying swapFrom swapTo functions in VAULT
• adds incentives
• updates priceAnchor in Router

priceAnchor

• logic in Router
• pool data in VAULT

    function addLiquidity(address base, address token, address member) external returns(uint liquidityUnits) {
        require(token != USDV && token != VADER); // Prohibited
        uint _actualInputBase;
        if(base == VADER){
            if(!isAnchor(token)){               // If new Anchor
                _isAnchor[token] = true;
            }
            _actualInputBase = getAddedAmount(VADER, token);
        } else if (base == USDV) {
            if(!isAsset(token)){               // If new Asset
                _isAsset[token] = true;
            }
            _actualInputBase = getAddedAmount(USDV, token);
        }
        uint _actualInputToken = getAddedAmount(token, token);
        liquidityUnits = iUTILS(UTILS()).calcLiquidityUnits(_actualInputBase, mapToken_baseAmount[token], _actualInputToken, mapToken_tokenAmount[token], mapToken_Units[token]);
...

It looks as if base is expected to be VADER or USDV. If it's neither of those, which looks possible, then _actualInputBase would be 0 in the call to calcLiquidityUnits. Is that OK?

DAO should be able to change params in each contract

getFunds is not a safe function. Anyone can call it, have their VADER locked in contract, without minting USDV. Maybe this function should be private?

https://github.com/vetherasset/vaderprotocol-contracts/blob/main/contracts/USDV.sol#L189

To prevent emissions eroding into the supply of VADER and causing a deadlock into the future, the maxSupply should be responsive to how much has been burnt (or minted back).

Note: This does prevent an inflation-risk in the protocol if there is a successful attack on the anchorPrice that allows someone to mint, depress price, burn, repeatedly.

Slip-based fees should slow this down, but the DAO can also respond by increasing usdv.blockDelay() to slow down the attack cycle.

If RESERVE is 0, this line can revert and block all transfers, add a check to skip =0

https://github.com/vetherasset/vaderprotocol-contracts/blob/main/contracts/USDV.sol#L194

Currently the Lending code is in the ROUTER.

It should be separate. It can ask the RESERVE for borrowed funds, then use that to swap as debt.

This should keep the ROUTER small and the system more modular.

Solidity 0.8 is safe math, so this overflow check can be omitted to save gas.

https://github.com/vetherasset/vaderprotocol-contracts/blob/main/contracts/Vether.sol#L72

Implementation

Draw Debt

• Members deposit collateral into Vault, which has a reserve.
• Member choose to borrow debtAsset from collateral.
• SwapValueInBase(collateral) is sensed, corresponding base amount taken from reserve, swapped to debtAsset.
• debtAmount is stored.

Pay Back

• Member pays back debtAsset into vault, decrement debtAmount.
• Swapped to Base, returned to reserve.
• collateral can be redeemed

Interest

• Every cycle, take interest from all collateral, sync to the corresponding pool
• Members have a share of the interestPaid
• If collateral - interestPaid <= 1.01 * debtAmount then member can be purged for a fee

Liquidate

• If collateral - interestPaid <= 1.01 * debtAmount then member can be liquidated for a fee

In case of attacks, can increase the delay to convert/redeem

Currently member share of the interest rates are not computed correctly.

Implementation

The share of interest should be tracked by an accumulator which multiplies time by collateral sizing valueTime. This is updated each time a member borrows or repays, and their share of the interest corresponds to their share of the accumulated valueTime.

interestShare = memberValueTime / (systemValueTime + accumulatedValueTime)

Example

Eg, 100 of X is borrowed at time 0 by Member A. Store collateralValue, and set the accumulator to 0.
Interest can be charged at any time, keep a track of this.
100 blocks later, Member B enters, with 100 of X. 100 blocks later, Total Interest Paid is 10.
Member B goes to withdraw. How much of the interest is theirs?

// Time:0
collateral = 100 //Member A
accumulatedValueTime  = 0 * 0 = 0

// Time:100
collateral = 200 //+ Member B
accumulatedValueTime  = 100 * 100 = 10000
systemValueTime = accumulatedValueTime = 10000

// Time:200
collateral = 200
systemValueTime = 10000
accumulatedValueTime  =  100 * 200 = 20000
memberValueTime = 100 * 100

interestShare = memberValueTime / (systemValueTime + accumulatedValueTime)
interestShare = 100 * 100 / (10000 + 100 * 200) = 10000 / 30000 = 0.33 = 33% share

memberValueTime -= memberValueTime
systemValueTime -= memberValueTime
outstandingInterest -= interestShare

Should Synth decimals equal token decimals?

https://github.com/vetherasset/vaderprotocol-contracts/blob/main/contracts/Synth.sol#L15

Add comments in code to explain the system

Remove ANCHOR-synth staking, so the only stablecoin to earn on is USDV, not USDT.v or USDC.v.

Also disable the option of creating SYNTHS from USDT, USDC, as well as allowing them to be used as collateral, thus, the only way to short something in the system (ie, borrow an asset with a stablecoin, this is shorting it) is to borrow against USDV.

So:
Synth-creation:

• Asset pools

Interest-Bearing:

• Asset-SYNTHS
• USDV

Loan Collateral:

• Asset-SYNTHS (longing the collateral asset)
• USDV (shorting the debt asset)
• VADER (longing VADER)

USDV should be a first-class citizen in the system, with all attention focussed on it.

USDV

• USDV is simple ERC20
• USDV mint/burn based on balance (ask ROUTER for price) (same as VADER)
• Need to think about FlashProof

VAULT

• Vader sends funds to VAULT
• Check incentives is based on VAULT activity
• VAULT sends funds to ROUTER

10BP (0.1%) on all transfers, as the totalSupply increases from 1m to maxSupply, the FoT increases to 100 BP (1%).