Vulnerability details
function delegateBySig doesn't cover case when delegatee = address(0), malicious users can lock other user's NFT(funds).
The delegateBySig() function does not validate the delegatee address.
when call delegateBySig(delegatee=address(0)), the delegatee is still self, but user checkpoints.votes will be reduced.
it will cause the NFT(funds) of the user being delegate to be locked, can no set other delegatee or NFT transfer
https://etherscan.io/address/0x6050B7040cF4Ae3e60c3c1A5d0367B565a1460C1#writeContract
To create a Liquidity-Swap facility for USX-DF, which enables the protocol to swap its protocol-minted USX for DF liquidity in the market.
Mainnet
LiquiditySwap(CurvePrice(USDC) Pulsar sDF)
Contract Name
Contract Address
Link
implementation
0xe45242483CDC310dE7BEF3cDB8545aB1aF31eB43
Notice:
Gas consumption
Library version (To verify later)
Steps:
Cooperate with product team to confirm features and design implementation
Implementation + Verify
Formal Verification + Audit
Testnet Launch + Bounty Programs
Mainnet Alpha Launch
Feature Requirement
1. Liquidity Management
Measure user's liquidity position, eg: generate one NFT for each user's pool, calculate "liquidity" just like Uniswap V3 does to measure user's deposits and real-time value of the pool. Therefor, third-parties can build further features and derivatives on top of those liquidity positions, just like they do with cToken, LP tokens.
Handle multiple users in the same pool to avoid liquidity fragments, eg: manage assets in one pool of multiple users with the same strategy, like in Uniswap V3, assets of USDC/USDT pool from multiple users with the same fee will goes to the same place(the same contract).
Adopt EIP-3525 if possible, facilitate NFT partial transfer.
2. Multiple Router
Support ERC20 router, support USX in the future.
Bounty Program on Testnet
Target
The bug bounty program is focused around smart contracts of AMM and is mostly concerned with issues stated in the "Impacts and Level" section.
All bug reports must come with a PoC in order to be considered for a reward, bug reports without a PoC will be rejected.
Critical vulnerabilities for smart contracts are further defined by the following conditions. All need to be met in order to get the classification of critical.
Allow attacker(s) to take away collateral tokens for at least 10% in dollar value of collateral tokens from the system.
Are applied to a real situation and triggered through an attack vector rather than theory or hypothesis.