Size — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Size, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Size reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Size
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Size: Borrower is not able to compensate his lenders if he is underwater
Size's compensate() function contains a post-condition that reverts unless the caller's collateral ratio is healthy at the end of the transaction. This makes it impossible for an underwater borrower to improve their position incrementally across multiple compensation calls: a borrower holding several healthy credit positions who needs to compensate more than one lender to reach a healthy CR is blocked on the first call because they are still underwater after that single compensation. As a result the borrower is forced to dump credit positions at unfavorable prices via the market, or face liquidation. The project confirmed the issue and fixed it by comparing the collateral ratio before and after compensation so the call only reverts when the ratio worsens.
Size: Size uses wrong source to query available liquidity on Aave, resulting in borrow and lend operations being bricked upon mainnet deployment
Size's CapsLibrary.validateVariablePoolHasEnoughLiquidity checks available variable-pool liquidity by reading the underlyingBorrowToken balance of the Aave variablePool contract address. On live Aave v3 deployments all supplied liquidity is actually held in the corresponding AToken contract, not the Pool, so this balance is effectively zero and the check always reverts, bricking both buyCreditMarket and sellCreditMarket on mainnet. The bug went undetected because the test suite uses a PoolMock that transfers supplied assets into the mock pool itself, diverging from real Aave behavior. The finding was confirmed by the Size team and fixed by querying the AToken address via getReserveData; the judge downgraded it to Medium since there is no direct fund loss.