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
- 15
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 15 closed, publicly disclosed Size reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Front-running / MEV, 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
- Front-running / MEV 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: Credit can be sold forcibly as `forSale` setting can be ignored via Compensate
In the Size peer-to-peer credit protocol, a lender's credit position can be sold against their explicit wishes because the Compensate action hardcodes forSale=true on any newly created credit position. When a borrower runs Compensate with a reserved credit-position ID, the contract mints a fresh credit marked as forSale=true and re-issues the compensated credit to the original lender under that new position, overriding both the lender's per-position forSale=false flag and the global allCreditPositionsForSaleDisabled preference. A buyer can then settle the purchase through BuyCreditMarket at the lender's own active borrow offer, so the forced sale executes regardless of the lender's intent. The trade only happens when profitable, so harm scales with interest-rate volatility, and the team confirmed the flaw and fixed it in a pull request by threading the forSale flag through the position-creation path instead of hardcoding it.
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.
Size: Fragmentation fee is not taken if user compensates with newly created position
Size's `executeCompensate` function is designed to charge a fragmentation fee whenever a borrower splits their credit position by compensating debt with a newly created credit position via the `RESERVED_ID` path. The flaw is that a freshly minted credit position gets `credit = futureValue = amountToCompensate`, so the computed `exiterCreditRemaining = credit - amountToCompensate` is always zero, and the fee-charging branch is never entered. A user can therefore split their debt credit into a new position and dodge the collateral-token fee entirely, depriving the protocol of intended fee revenue. The Size team confirmed the root cause and mitigation and fixed it in an upstream pull request.
Size: The collateral remainder cap is incorrectly calculated during liquidation
Size's liquidation path incorrectly caps the protocol's share of collateral remainder by multiplying the debt-in-collateral amount by the full liquidation collateral ratio (130%) instead of by just the excess above full repayment (30%). As a result, an overdue borrower holding more collateral is charged a larger protocol fee than an equally-indebted borrower with a lower collateral ratio, even though both are liquidated under identical conditions. This inverts the intended incentive structure and penalizes well-collateralized positions, discouraging users from maintaining healthy collateral ratios. The report includes a reproduction test and a one-line fix that subtracts PERCENT before multiplying.
Size: Sandwich attack on loan fulfillment will temporarily prevent users from accessing their borrowed funds
When a borrower sells credit on Size they receive Aave variable-pool borrow aTokens rather than the underlying borrowed token, and the protocol's only available-liquidity guard is a balance check on the Aave variable pool that does not actually reserve or remove the liquidity. Because of this gap, an attacker can deposit Aave liquidity in a front-run, have the loan execute while liquidity superficially appears sufficient, then withdraw the liquidity in a back-run, leaving the borrower unable to withdraw their borrowed funds until liquidity returns to the pool. The validated liquidity can also disappear through ordinary external removal. The finding was acknowledged by the Size team, which argued MEV attacks belong outside the protocol layer, but the judge retained it as Medium for highlighting the irrational validation process.
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.
All reports in this group
- Size: Neither `sellCreditMarket()` nor `compensate()` checks whether the credit position to be sold is allowed for saleLogic error$0
- Size: Risk of overpayment due to race condition between `repay` and `liquidateWithReplacement` transactionsLogic error$0
- Size: Inadequate checks to confirm the correct status of the sequence/`sequencerUptimeFeed` in `PriceFeed.getPrice()` contractLogic error$0
- Size: `withdraw()` users may can't withdraw `underlyingBorrowToken` properlyLogic error$0
- Size: Multicall does not work as intendedLogic error$0
- Size: Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrectLogic error$0
- Size: `executeBuyCreditMarket` returns the wrong amount of cash and overestimates the amount that needs to be checked in the variable poolLogic error$0
- Size: Users may incur an unexpected fragmentation fee in the `compensate()` callFront-running / MEV$0
- Size: When `sellCreditMarket()` is called to sell credit for a specific cash amount, the protocol might receive a lower swapping fee than expectedLogic error$0