Blast Integration Bugs - Part 1
"With each new great protocol, comes new integration bugs" ~ Uncle Nirlin
Introduction
Uncle Ben once said “With great power comes great responsibility”, but today Uncle Nirlin is going to teach you an even more interesting lesson.
”With each new great protocol, comes new integration bugs”
At least this has been the case with all big projects, integrations are hard, and if the codebases you are integrating with are complex it’s even harder. That’s why I said quite a few times, that we need more integration-specific auditors, like Windhustler for layer zero and Stargate and Jeiwan for uniswap.
So what could go wrong when integrating with blasts yield and points mechanism? Well, there are quite a few things, let’s break them down one by one. A small note for people who are living under the rock and don’t know what blast is
Blast only Ethereum L2 with native yield for ETH and stablecoins (for now just usdb → usd-blast)
Where does yield come from? If you don’t know the source of yield, you are the yield. In the case of blast, it comes from staking the eth in LIdo and for USDB it comes from the makerDao T-bill protocol. You can read more about this here: https://docs.blast.io/about-blast\
Integration Bugs 101
1. Yield for smart contracts is not accrued by default
For EOA accounts on blast, the yield is accrued automatically for WETH and USDB, one may assume that is the case for the smart contracts too which is not.
Smart contract accounts have three Yield Modes for their rebasing mode:
Void (DEFAULT): ETH balance never changes; no yield is earned
Automatic: native ETH balance rebases (increasing only)
Claimable: ETH balance never changes; yield accumulates separately
Smart contracts must interact with the Blast yield contract located at 0x4300000000000000000000000000000000000002 to change their Yield Mode.
2. Yield for the USDB and WETH is accrued by default for the Smart contract
Blast got you here haha, Unlike native eth, native stablecoin yield is accrued by default. This can lead to bugs specifically when the devs might assume that the native stablecoin yield will be also similar to the native ETH yield It can be enabled by calling configure on USDB and WETH
How it could go wrong?
A protocol that has critical logic that is dependent upon the balance of WETH or USDB and might not realize it is auto-accruing and can run into criticals easily.
3. No claim functions exposed
One of the bugs that I came across while auditing a protocol on blast was the protocol engineers set the yield to be claimable in the constructor but forgot to expose the claim functionality for the owner. For a smart contract yield can be set to claimable as follows:
But if there are no claim functions like the following and no option to revert to auto accruing of yield, all the yield will be lost
5. Multiple Claims In Single Functions
Consider a function that has a function named claimAll that can be only called by the owner of the contract and this contract calls all the claim functions for native eth, WETH , USDB and gas like this :
How it could go wrong?
But if the contract is not meant to hold any WETh at all it will never accrue any yeild and this function will always revert leading to a permanent DOS. Came across this bug in Abracadabra MIM swap audit with guardians.
Instead, split each claim into its individual function as follows:
6. Weird WETH behavior on blast L2
The WETH contract deployed on blast is not a standard weth99 contract and it doesn’t have the following check on transferFrom
So something like the following code snippet will always revert on Blast because it will check for the allowance, but works fine on mainnet, so a developer might assume the same behavior on Blast and the protocol could run into DOS. This bug was also found in mim-swap code4rena contest.
Conclusion
Here ends the part 1, in part two I will explore 5 more blast integration bugs that are bit more complex than these and are hard to catch, until than happy learning. Contact me on Twitter for any questions: 0xnirlin