astariaxyz / astaria-core Goto Github PK

The system will need a helper contract that can allow users to validate a loan at the time of the purchase so the user pays a lower price

The purpose of this test is to ensure that a non-delegate/non-strategist is incapable of incrementing a PublicVault nonce

• New PublicVault
• PublicVault.incrementNonce() (by rando)
• assert nonce is 0

The purpose of this test is to ensure the strategist is capable of incrementing a PublicVault nonce

• New PublicVault
• PublicVault.incrementNonce() (by strategist)
• assert nonce is 1

The purpose of this test is to shake out rounding errors when incrementing and decrementing the slope. Currently there is a rounding error when incrementing and decrementing PublicVault slope.

• Produce a test that induces the failure
• assert that the rounding is correct
• remove the rounding error compensation here
• adjust contracts to make the assertion pass after rounding error compensation is removed

testZeroizedVaultNewLP()

The purpose of this test is to test the LPs joining, then all LPs withdraw from the vault. Assertion is to show that the LP shares in the next epoch mint the. correct amount.

1. New LP1 -> 50 eth, withdraw epoch 0
2. get LP1 balance for later comparison
3. New lien1 (14 days, 10 ETH, 150%)
4. lien1 repaid 10 ETH
5. warp to end of epoch0
6. assert processEpoch does not revert
7. Assert PV.slope is zero
8. Assert PV.totalSupply is 0
9. Assert withdrawReserve is 50 ETH
10. Assert LA not deployed
11. Assert yIntercept is 0
12. PV.transferWithdrawReserve()
13. assert LP1 balance is 50 ETH
14. New LP2 -> 50 eth, withdraw epoch 0
15. Assert LP1 initial balance is equal to LP2 current balance
16. New lien2 (14 days, 10 ETH, 150%)
17. warp to end of epoch1
18. Assert lien2 getOwed is 10.57534246575 ETH
19. repay lien2 10.57534246575 ETH
20. Assert PV.yIntercept is 50.57534246575 ETH
21. Assert lien2 calulateSlope() is zero
22. Assert PV.slope is 0
23. Assert LA not deployed
24. processEpoch() epoch 1
25. Assert withdrawReserve 50.57534246575 ETH
26. Assert PV.totalSupply is 0
27. Assert PV.totalAssets() is 0
28. Assert PV balance is 0
29. PV.transferWithdrawReserve()
30. Assert LP2 balance 50.57534246575 ETH

The purpose of this test is to ensure that makePayment() flow is blocked off after liquidation.

• New LP
• New lien (50 eth, 150%, 14 days)
• commitToLien()
• warp 14 days
• liquidate
• assert makePayment for lien reverts

• new PublicVault

• new LP

• commitToLien()

• attempt flash action as borrower

• assert that collateraltoken is the owner of the underlying asset

• new PublicVault

• new LP

• commitToLien()

• attempt flash action as borrower

• attempt to modify the state of the v3 position

• assert reversion on modification

Any instance to merklization or signing needs to be replaced in the test suite with astaria-sdk

The purpose of this test is to ensure the borrower cannot take out a new lien with a duration of zero. Since a new lien with duration of zero would put the borrower instantly in liquidation.

• New LP
• New lien with duration zero
• assert that commitToLien reverts

Create scenario where the collateral is liquidated

• scenario 1: overbid and validate that all parties received the correct amounts
• scenario 2: underbid and validate that all parties received the correct amounts

what if expected is exactly equal to totalAssets()

gasProfilingTests()

• new lien
• new LP
• withdraw w/ WithdrawProxy already deployed
• withdraw w/o WithdrawProxy already deployed
• liquidate w/ 1 lien
• liquidate w/ 5 liens
• liquidate w/ 1 lien w/ LA
• liquidate w/ 5 liens w/ LA
• processEpoch

• new PublicVault 14 day epoch
• new LP
• new Lien (50 ETH, 150%, 14 days)
• commitToLien() (10 ETH)
• warp 14 days
• liquidate()
• bid 5 ETH
• borrower pays the cancellation reserve
• assert borrower owns the collateraltoken
• assert PublicVault balance is 10.575342465745600000 ETH

I don't know what happens in the case of the liquidator, but we should probably asset their balance as well

The purpose of this test is to ensure the delegate is capable of incrementing a PublicVault nonce

• New PublicVault
• PublicVault.incrementNonce() (by delegate)
• assert nonce is 1

https://github.com/spearbit-audits/astaria/pull/8#pullrequestreview-1191834436

• New PublicVault (13 day epoch)
• New LP
• New lien (14 days, 150%, 50 ETH)
• New borrow 10 ETH
• warp 13 days
• liquidate
• bid 5
• assert liquidator fees
• assert publicvault amount

• New PublicVault (13 day epoch)
• New LP
• New lien (14 days, 150%, 50 ETH)
• New borrow 10 ETH
• warp 13 days
• liquidate
• bid 20
• assert liquidator fees
• assert publicvault amount

The purpose of these two tests is to ensure that the signature test is correct. If an ecrecover is returned with the address of strategist or delegate the test should succeed.

test 1

• New LP
• Construct a new merkle
• Sign merkle with the strategist wallet ecrecover(signature) should the strategist address
• Assert that commitToLien() succeeds

test 2

• New LP
• Construct a new merkle
• Sign merkle with the delegate wallet ecrecover(signature) should the delegate address
• Assert that commitToLien() succeeds

Lots of undocumented new functions/outdated natspec for old functions, should patch up before audit

multipleVaultsWithLiensOnTheSameCollateral()

1. New PV1 with epoch length of 14 days
2. New PV2 with epoch length of 13 days
3. New PV3 with epoch length of 12 days
4. New PV4 with epoch length of 11 days
5. New PV5 with epoch length of 10 days
6. PV1 lien1 (14 days,1 ETH, 150%) on CT1
7. PV2 lien2 (13 days, 2 ETH, 150%) on CT1
8. PV3 lien3 (12 days, 3 ETH, 150%) on CT1
9. PV4 lien4 (11 days, 4 ETH, 150%) on CT1
10. PV5 lien5 (10 days, 5 ETH, 150%) on CT1
11. warp 11 days
12. liquidate() lien4
13. assert calulateLienSlope() lien1 - lien5 is equal to zero
14. assert PV1 - PV5 PV.slope is zero
15. assert PV1 PV.yIntercept 1.045205479452054794 ETH
16. assert PV2 PV.yIntercept 2.090410958904109588
17. assert PV3 PV.yIntercept 3.135616438356164382
18. assert PV4 PV.yIntercept 4.180821917808219176
19. assert PV5 PV.yIntercept 5.22602739726027397

https://github.com/spearbit-audits/astaria/pull/8#pullrequestreview-1190982646

• new PublicVault
• new LP
• commitToLien()
• attempt flash action as borrower
• in flash action contract transfer the underlying asset without returning it
• assert reversion

The purpose of this test is to ensure that the all parties are properly repaid in the event of a lien buyout

• New PublicVault 14 day
• New LP 50 ETH
• New Lien (50 eth, 150%, 14 days)
• commitToLien 10 eth
• warp(block.timestamp + 5 days)
• buyout lien
• assert buyer has the lien token
• buyoutAmount = 10 + (1.5 * (5/365) * 10) <- interest accrued + (1.5 * (9/365) * 10 * 0.1 ) <- buyout (use wad math)
• assert that the publicvault weth balance of buyoutAmount
• assert that the publicvault totalAssets() equals buyoutAmount
• assert that the publicvault yIntercept equals buyoutAmount
• assert PV.slope is 0
• assert that the lien counter for epoch 0 equals 0
• signalWithdraw
• warpToEpochEnd
• redeem
• assert LP balance is 40 eth + buyout

The goal of this test is to put the LiquidationAccountant into a hung state where a liquidation that occurred was claimed and the second liquidation could not be claimed.

blockingLiquidationsProcessEpochTest()

1. New LP1 -> 50 eth, withdraw epoch 0
2. New lien1 (14 days, 10 ETH, 150%)
3. New lien2 (14 days, 10 ETH, 150%)
4. Warp to the end of epoch 0
5. Liquidate lien1
6. bid 20 ETH
7. assert LA.claim() reverts (will not revert in current form)
8. liquidate lien2
9. bid 20 ETH
10. assert LA.claim() does not revert
11. assert processEpoch does not revert (will revert in current form)
12. Assert PV.slope is zero
13. Assert withdrawReserve is 30
14. Assert withdrawRatio is 1e18
15. Assert balance of LA is 21.15068493151 ETH
16. LA.claim()
17. PV.transferWithdrawReserve()
18. assert LA, PV balances are zero
19. assert LP1 balance is 51.15068493151 ETH

• New PublicVault 14 day epoch
• New Lender (50 eth)
• New Lien (14 days, 50 ETH, 150%, liquidationInitialAsk 100 ETH)
• commitToLien 50 ETH
• New Lien (25 days, 50 ETH, 150%, liquidationInitialAsk 100 ETH)
• assert reverts on commitToLien 50 ETH (new lien + old lien total potential debt exceeds lien[0].liquidationInitialAsk)

The purpose of this test is to ensure that a borrower cannot borrow more than the specified lien.amount.

• New LP
• New lien (10 ETH, 150%, 14 days)
• commitToLien() (10.1 ETH)
• Assert that commitToLien() fails

Validate revert for liquidationInitialAsk < amount borrowed

• New PublicVault 14 day epoch
• New Lender (50 eth)
• New Lien (10 days, 50 ETH, 150%, liquidationInitialAsk 40 ETH)
• assert reverts commitToLien 10 ETH

Validate revert for liquidationInitialAsk == 0

• New PublicVault 14 day epoch
• New Lender (50 eth)
• New Lien (10 days, 50 ETH, 150%, liquidationInitialAsk 0 ETH)
• assert reverts commitToLien 10 ETH

The purpose of this test is to ensure that a borrower can take out a lien of an amount lower than lien.amount.

• New LP
• New lien (50 ETH, 150%, 14 days)
• New lien with an amount lower than lien.amount (10 ETH)
• Assert that commitToLien() does not revert
• Assert that PublicVault.slope is amount.mulDivDown(lienDetails.rate, 1e18);
• Assert that PublicVault.yIntercept is 50 ETH
• Assert that PublicVault.last == block.timestamp
• Assert that totalAssets() is 50 ETH
• Assert that PublicVault.balanceOf(borrower) == PublicVault.totalSupply()
• Assert weth9.balanceOf(PublicVault) is 40 ETH
• Assert that weth9.balanceOf(borrower) is 10 ETH

• new PublicVault
• new LP
• commitToLien()
• attempt flash action as borrower
• assert that collateraltoken is the owner of the underlying asset

sherlock-audit/2022-10-astaria-judging#264

The purpose of this test is to ensure that a correct merkle branch presented to commitToLien() results in a new lien.

• New LP
• New lien (50 ETH, 150%, 14 days)
• Construct new merkle
• Sign merkle as a delegate
• New lien with an amount lower than lien.amount (10 ETH)
• Assert that commitToLien() does not revert
• Assert that PublicVault.slope is amount.mulDivDown(lienDetails.rate, 1e18);
• Assert that PublicVault.yIntercept is 50 ETH
• Assert that PublicVault.last == block.timestamp
• Assert that totalAssets() is 50 ETH
• Assert that PublicVault.balanceOf(borrower) == PublicVault.totalSupply()
• Assert weth9.balanceOf(PublicVault) is 40 ETH
• Assert that weth9.balanceOf(borrower) is 10 ETH

Underlying NFTs for CollateralTokens will appear in the OpenSea UI like the other NFTs in the same collection using a Timed Auction

LienDetails will have an additional field uint256: liquidationInitialAsk a wad value 1e^18 in WETH. It will represent the starting price for the timed auction in the event of liquidation.

When a liquidation is initiated where there are multiple liens in the LienStack for the same CollateralToken liquidationInitialAsk of LienStack[0] will be used as the starting price.

Timed Auctions will begin at block.timestamp of the liquidation transaction and will go until block.timestamp + 3 days, or until a single bid is made. Price will start at liquidationInitialAsk descending to 0 over 3 days.

If a bid is made the auction ends immediately and all liens are either settled, partially settled, or unsettled before going to deletion.
If no bid is made a call (by anyone) that transfers the NFT to the liquidator and all liens remain unsettled before going to deletion.

https://github.com/spearbit-audits/astaria/pull/8#pullrequestreview-1190982924

The purpose of this test is to test that the finalActuionEnd() value in the withdraw proxy is being set into the future

Strategists can call shutdown(), this is a one way event which disables new deposits and new loan origination, leaving withdraw as the only choice for depositors.

Exit flow's remain unaffected.

Submodule cannot install and the CI is failing. Fix the CI so that CI runs on any new branch an is blocking for merge on develop or master.

• A contract needs to be created that can handle the auctioning off of NFTs for liquidation
• An implementation of liquidate() in NFTBondController needs to be made

As an open research question, can we make Loan structs into a merklelizable value that requires us to only store a single bytes32 value.

This would require the user each time to submit a merkle proof to validate data and has data availability considerations. However, each clean slot of storage for each loan costs 20,000 gas where a merkle tree requires 638 for each order of the tree. This could significantly reduce thee gas profile without risking security.

As stated before this has data availability implications.

https://ethereum.org/se/developers/tutorials/merkle-proofs-for-offline-data-integrity/

The purpose of this test is to ensure that the all parties are properly repaid in the event of a lien buyout

• New PrivateVault 14 day
• New LP 50 ETH
• New Lien (50 eth, 150%, 14 days)
• commitToLien 10 eth
• warp(block.timestamp + 5 days)
• buyout lien
• assert buyer has the lien token
• buyoutAmount = 10 + (1.5 * (5/365) * 10) <- interest accrued + (1.5 * (9/365) * 10 * 0.1 ) <- buyout (use wad math)
• assert that the publicvault weth balance of buyoutAmount
• assert that the publicvault totalAssets() equals buyoutAmount
• assert that the publicvault yIntercept equals buyoutAmount
• assert PV.slope is 0
• assert that the lien counter for epoch 0 equals 0
• signalWithdraw
• warpToEpochEnd
• redeem
• assert LP balance is 40 eth + buyout

sherlock-audit/2022-10-astaria-judging#293

Ensure that there is sufficient checks to prevent abuse on buyout and commit to liens for adding liens against another valid stack.

If account is a PrivateVault txn will revert

      s.ASTARIA_ROUTER.isValidVault(account) &&
      IPublicVault(account).supportsInterface(type(IPublicVault).interfaceId);

Assert that the new lien cannot exceed current epoch

• New PublicVault 14 day epoch
• LP 50 ETH
• warp 3 days
• New lien 30 days
• commitToLien
• assert stack[0].point.end == block.timestamp + 28 days
• assert stack[0].lien.details.duration == 28 days

Root signing is currently done outside of the astaria-sdk. Utilize the methods from astaria-sdk to ensure correct root signing in both instances

Our current || check means that rate or duration can get worse, change to &&. Maybe allow one to stay the same if the other improves?

• New PublicVault with epoch length 0
• assert that it reverts
• New PublicVault with epoch length > 45 days
• assert that it reverts

Wrapper contract needs to conform to ERC721 interfaces with additional functionality:

• tokenIds are computed using input data that is salted with user details
• validates hashes and marshals in new tokens
  -- (ERC20, ERC1155, and ERC721)

sherlock-audit/2022-10-astaria-judging#49

The purpose of these two tests is to ensure that the signature test is correct. Is an ecrecover is returned with address(0) or an alternate address.

test 1

• New LP
• Construct a new merkle
• Sign merkle in such a way that is does not validate ecrecover(signature) should return address(0)
• Assert that commitToLien() fails

test 2

• New LP
• Construct a new merkle
• Sign merkle with the incorrect wallet ecrecover(signature) should return an address that is neither the delegate or the strategist
• Assert that commitToLien() fails

The purpose of this test is to ensure that a lien with a rate of zero cannot be initiated. This check is necessary because later in liquidation a lien.rate of 0 is an indication the lien is being liquidated.

• Setup a new LP
• Setup a new lien with a rate of 0
• Assert commitToLien fails