Investigate and confirm the behaviour for new staking users for uad-contracts and diamond

[gitcoindev]

Right now the behaviour for new staking users is this one:

1. User deposits 1000 UAD3CRV LP to https://etherscan.io/address/0xc251ecd9f1bd5230823f9a0f99a44a87ddd4ca38 for 1 week
2. User waits for 1 week
3. User withdraws 1000 UAD3CRV LP and gets 178 UAD3CRV LP + 72 UBQ. User would expect to get 1000 UAD3CRV LP instead of 178.

Originally posted by @rndquu in #752 (comment)

[gitcoindev]

I extracted this to a separate issue, will post finding for both uad-contracts and diamond-based staking contract.

[0x4007]

I'm assuming its because I moved collateral out of the contract which I know affects the withdrawal amounts.

[ubiquity-os]

# Issue was not closed as completed. Skipping.

[rndquu]

I'm assuming its because I moved collateral out of the contract which I know affects the withdrawal amounts.

Do we plan to move it back to the staking contract?

[0x4007]

Yeah I think we need to migrate to v2 somehow. It was mostly removed because of some problem discovered in Sherlock if I recall correctly.

[rndquu]

Yeah I think we need to migrate to v2 somehow. It was mostly removed because of some problem discovered in Sherlock if I recall correctly.

Staking contracts weren't part of the Sherlock audit.

[0x4007]

Then I don't remember why some was moved

[rndquu]

Then I don't remember why some was moved

Then perhaps we should reopen this issue?

[0x4007]

It isn't clear to me if we redid the staking yet and if we should migrate? If so perhaps we should make a new issue instead.

[rndquu]

It isn't clear to me if we redid the staking yet and if we should migrate? If so perhaps we should make a new issue instead.

What we have right now:

1. MasterChefV2.1 contract (i.e. old staking) which seems to be working fine (almost)
2. StakingFacet (i.e. new staking) which:
   a) is not used right now
   b) not fully covered with tests so it's hard to say that it works as the original MasterChef
   c) ideally requires an audit

The only issue with the MasterChefV2.1 contract (old staking) is current github issue with missing LP tokens. If this issue is the result of owner actions or some other expected behavior then it makes sense to save development time and simply use the old staking contract.

That is why we'd better to find out the root cause of missing LP tokens and then decide whether we should proceed with the old staking or migrate to the diamond's StakingFacet contract.

[rndquu]

As far as I understand the root cause for missing liquidity is the uADPriceReset method and the following transactions:

• https://etherscan.io/tx/0x784725b27d9c4d5ea699c7e8b94fb6b90bc409033aac1982421a6397ba3618f4
• https://etherscan.io/tx/0x834a3bce583ab0c502bc463e540a29bdbf685cce51e87a299c02edf3c95cfb96
• https://etherscan.io/tx/0x13839568b6ad980872e2c6fbbfc0151f4c17f120c2bb2fef1d3c7026a7b8f86d
• https://etherscan.io/tx/0xd04a9ad1d0c180e91963feb98a615419cf31cfa68efe4f2e9bd9249ebdbbe4a2
• https://etherscan.io/tx/0x99b1ccdef075b3718cf3a9f62b71f00a25eaa2525dd0084cd1a32c1610a3cb00
• https://etherscan.io/tx/0x9526c910a572f61b366b822372bd260a0fa88730b8de83394e11524c61b78319

The uADPriceReset method works this way:

1. Bonding manager calls uADPriceReset with a specific amount
2. BondingV2 withdraws uAD token from the 3CRV/uAD curve pool in exchange for the 3CRV/uAD LP tokens (which users staked)
3. BondingV2 transfers uAD to the treasury address

So the main purpose of the uADPriceReset method is to increase the uAD price.

I suppose all of the transactions above were executed in order to keep uAD close to 1$ peg.

Anyway the staking contract liquidity is not lost, it just sits in the form of uAD tokens in the treasury.

When all staking positions are expired in the old staking we should put the 3CRV/uAD LP token liquidity back in the staking contract so that users who staked were not affected. Not sure how it affects exact rewards when you put tons of liquidity in the end, this requires a research.