Feat/fractional pool #922
Feat/fractional pool #922
Conversation
| governanceNeeded = dollarForGovernance | ||
| .mul(UBIQUITY_POOL_PRICE_PRECISION) | ||
| .div(getGovernancePriceUsd()); | ||
| } | ||
|
|
||
| // subtract the minting fee | ||
| totalDollarMint = dollarAmount |
There was a problem hiding this comment.
Original Frax contract works the same way.
This approach is wrong and breaks the peg mechanism, given that the amount of dollar minted will always be smaller than the expected by the peg algorithm
The peg mechanism is based on arbitrage opportunity (users must always be able to mint/redeem 1 Dollar token for exactly 1 USD in collateral), not on the amount of collateral.
The result is we have dollar always overbacked by collateral, which will draw dollar price down
I don't understand why overcollateralization is bad. On the contrary, the greater the collateral/Dollar ratio the better the pool's resistance to collateral depeg.
Overall I think that overcollateralization doesn't harm the protocol and USD peg in particular.
@0xadrii Are there any similar issues on sherlock/code4arena ?
@gitcoindev @molecula451 Help
| * | ||
| * @param newCollateralRatio New collateral ratio | ||
| */ | ||
| function setCollateralRatio(uint256 newCollateralRatio) internal { |
There was a problem hiding this comment.
[LOW] - Collateral ratio should be capped
As seen in Frax's code, collateral ratio will always be capped at 100%. For Ubiquity, if a higher value is wrongly set and the dynamic CR is implemented, then it could cause some issues. It is recommended to add a maximum value for newCollateralRatio of 1_000_000.
It would also be good to cap the fees in the setFees function to the max acceptable values, as well as the redemption delay blocks in setRedemptionDelayBlocks.
This PR introduces fractional mint/redeem of the Dollar token based on the collateral ratio which represents how many tokens user has to provide in collateral and governance tokens.
How it worked before:
How it works in this PR
Example 1 (collateral ratio is 100%):
You may see that the behaviour is the same as in the previous code version when collateral ratio is 100%.
Example 2 (collateral ratio is 90%):
The main reason why we need the fractional feature from the start is to incentivise initial investors (who staked collateral to get UBQ tokens) to put liquidity in the protocol. The plan is to set collateral ratio to 95% from the start so that initial investors could mint Dollar tokens with a 5% discount which is both profitable for investors and useful for protocol (i.e. Dollar token) liquidity.
The code works the same way as in one of the popular stablecoins.
Notice:
a) If collateral ratio is increased from 90% to 100% (dynamically or admin set it) then the pool contains 10% of missing collateral so users can deposit collateral to the pool in exchange for Governance tokens (with some premium) until the actual collateral value hits 100%. It is called recollateralization.
b) On the contrary, in case of decollateralization, if collateral ratio is decreased from 100% to 90% then the pool contains 10% of excess collateral. Users can burn their Governance tokens in exchange for collateral until the actual collateral value is 90%.
Initially we plan to set collateral ratio to 95% and leave it at that level. Besides users can override fractional mechanic on mint. But should we want to update collateral ratio from 95% to some other value after the deployment we'll have to add decollateralization and recollateralization methods to the protocol so that users could rebalance the pool.
P.S. Sadly this PR modifies already audited contracts so we'll have to find somebody from the Sherlock's audit to check the updates
P.P.S Diamond storage check workflow is failing which is expected and is ok since the contracts are not deployed yet.
P.P.P.S. I will update mainnet and development deploy script in another PR