- Join Sherlock Discord
- Submit findings using the issue page in your private contest repo (label issues as med or high)
- Read for more details
mainnet, Arbitrum, Optimism, Base
Any standard token, including USDT
None
None
No, fee-on-transfer tokens are not supported.
No, rebasing tokens are not supported.
Restricted. The protocol should be able to handle any changes enacted by Uniswap Governance (i.e., new fee tiers or changes to the protocol fee).
Restricted. The governor
address should not be able to steal funds or prevent users from withdrawing. It does have access to the govern methods in Factory
, and it could trigger liquidations by increasing nSigma
. We consider this an acceptable risk, and the governor itself will have a timelock.
There is a RESERVE
address, to which a portion of all interest accrues. It should be able to take any action and behave normally.
We also have a built-in referral program. If you enroll as a "courier" and attach the courier ID to your users' deposits, you will receive a portion of their interest. Couriers can take any action in the protocol except claiming rewards.
Also, if a courier credits another courier for their deposit, 100% of the first couriers earnings will be passed through to the other one. This edge case should not break anything or impact any other users.
Q: Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?
The Lender
complies with ERC4626 and EIP2612. Notes on our 4626 implementation are available here: https://coda.io/d/_dJtHvRlIBOx/Standard-Compliance_su6Wx
After a Borrower has been warn
ed, but before it's liquidated, there's an opportunity to make it healthy and avoid liquidation. If this is done via a call to Borrower.modify
, the warning will be cleared, and further interactions are normal. However, if it's done by a 3rd-party via Lender.repay (with the borrower set as the beneficiary), the warning will not be cleared.
https://drive.google.com/file/d/1aWEkCTTcuEnupf6nbIsqWy38igsj9-Hx/view?usp=sharing
Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, input validation expectations, etc)?
We expect interested parties to watch Borrowers and call warn
/liquidate
when possible. Same goes for the emergency pause
method in Factory, and the update
function in the VolatilityOracle.
Q: In case of external protocol integrations, are the risks of external contracts pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.
Uniswap cannot be paused.
Q: Do you expect to use any of the following tokens with non-standard behaviour with the smart contracts?
We use solmate's SafeTransferLib, so the protocol should work with tokens that are missing return values.
https://docs.aloe.capital/aloe-ii/overview https://docs.aloe.capital/aloe-ii/auditor-quick-start https://aloelabs.github.io/aloe-ii/index.html
aloe-ii @ c71e7b0cfdec830b1f054486dfe9d58ce407c7a4
- aloe-ii/core/src/Borrower.sol
- aloe-ii/core/src/Factory.sol
- aloe-ii/core/src/Ledger.sol
- aloe-ii/core/src/Lender.sol
- aloe-ii/core/src/RateModel.sol
- aloe-ii/core/src/VolatilityOracle.sol
- aloe-ii/core/src/libraries/BalanceSheet.sol
- aloe-ii/core/src/libraries/Exp.sol
- aloe-ii/core/src/libraries/LiquidityAmounts.sol
- aloe-ii/core/src/libraries/Log2.sol
- aloe-ii/core/src/libraries/MulDiv.sol
- aloe-ii/core/src/libraries/Oracle.sol
- aloe-ii/core/src/libraries/Positions.sol
- aloe-ii/core/src/libraries/Rewards.sol
- aloe-ii/core/src/libraries/TickMath.sol
- aloe-ii/core/src/libraries/Volatility.sol
- aloe-ii/core/src/libraries/constants/Constants.sol
- aloe-ii/core/src/libraries/constants/Q.sol