Author: Jarrod Watts, Polygon Developer Relations Engineer, Founder of evmkit.com; Translation: Golden Finance 0xjs
Someone said “Blast is just a 3/5 multisig…”
I spent the past few days digging into the source code to see if this claim was true.
Here’s what I saw:
1. A new wallet 0x52c31 deploys two contracts: 1. 0xa01: Blast Deposit proxy contract; 2. 0x5f6: Blast Deposit implementation contract.
If you are not familiar with these “proxy contract” settings, we will come back to this later.
2. 0x52c31 After deploying these contracts, the ownership is transferred to the Gnosis Safe smart contract.
Gnosis Safe or “Safe2” contracts are the most popular and trusted multi-signature smart contracts. They require a majority of signatories to execute a transaction.
3. There are now 5 signatories in the Safe contract that owns the Blast contract.
This means that a majority (i.e. 3/5) of the signers are required to execute transactions on behalf of this Safe contract. These 5 wallets are all very new wallets, but the owners are unknown.
4. So the 3/5 multi-signature contract is now the "owner" of the Blast Deposit contract.
As we mentioned, the Blast Deposit contract consists of two contracts: the proxy and the implementation.
What does it actually mean to be their "owner"?
5. For regular smart contracts, you cannot change the code once deployed to the blockchain. Proxy smart contracts allow you to perform "upgrades" (changes) to smart contracts without replacing the entire contract. This is often used to fix bugs or add features.
6. The Blast agent implements OpenZeppelin's UUPSUpgradeable contract. This includes functions such as "_upgradeTo" that allow changes to the logic of the implementation contract. This means that the contract that the user interacts with is able to maintain the same contract address.
7. The worst case scenario for this upgradability is that the (multi-signature) owner changes the logic of the contract to something malicious.
That sounds a bit scary, right? … In fact, these “auxiliary features” are used by most L2s today.
8. Optimistic Rollups like Optimism and Arbitrum also have this feature.
According to L2Beat:
The code that protects the OP Mainnet and Base systems can be changed at will without notice.
Arbitrum One’s upgrade would require approximately a 12-day delay, but the Council could approve it without delay.
9. The same is true in the zkEVM world
According to L2Beat:
The code protecting the Linea, Scroll, and zkSync systems is subject to change without notice.
Polygon zkEVM upgrades have a ~10 day delay (unless emergency state is activated)
10. The reason these Rollups have multi-signatures that can perform upgrades is to achieve interim security while the technology matures. As L2Beat outlined in its L2 Phase blog, the final stages of the Rollup should limit the ability of these security committees to address “serious flaws.”
11. The capacity of the Security Council decreases over time. However, the visibility of its members is important.
For example, Polygon PIP-29 proposes 13 members to manage “narrowly scoped, time-limited changes to the system’s smart contracts.”
12. So while it is indeed possible for Blast to perform a code upgrade via multi-signature and steal funds instantly, *currently* many other L2 solutions have the same capability.
So far, I've been defending Blast. But here comes the bad news... Let's move on.
13. Blast is not L2.
Blast is just a smart contract with two functions: 1. Accept user funds. 2. Invest user funds in protocols such as Lido.
No testnet, no transactions, no bridges, no Rollups, and no transaction data sent to Ethereum. This is not L2.
14. By depositing money into the Blast contract, you are essentially trusting 3-5 strangers to stake your funds for you.
Unless these 3-5 people decide to do the right thing in the future, you will not be able to withdraw this money at any time. Again, there is no bridge here.
15. This is really crazy to me...
You cannot get your money back from Blast until:
A 3/5 multisig consisting of strangers deployed a new contract;
This contract has the function to extract funds from it;
They transfer all funds to the new contract.
16. But it could be worse.
I can tell you that they don’t even need to perform an “upgrade” to steal all the funds in the contract, and the funds deposited by users cannot be withdrawn by others.
Let’s continue watching.
17. The function “enableTransition” requires the “mainnetBridge” contract as a parameter.
The function of this "mainnetBridge" contract: Get all staked ETH and DAI.
So, what does this “mainnetBridge” contract look like?
18. It can be absolutely anything! Blast approves any “mainnetBridge” contract to spend the maximum possible amount of LIDO and DAI…
Surely there must be some limitations to the correctness of this contract? Well, yes, let’s look at the code.
19. Below is the assertion statement in the “_setMainnetBridge” function.
It... Checks if there is any code at that address! Yes, as long as it is not an EOA address; it has approved all funds in the contract. The total amount of funds is currently over $200 million.
20. It can therefore be assumed that they can:
1. Create an extremely simple smart contract and set it as the mainnetBridge contract;
2. Let the smart contract receive all pledged ETH and DAI (200 million+)
Call the smart contract to withdraw all funds to the EOA wallet.
21. The two main threats we found are:
Malicious code was upgraded with 3/5 multi-signature approval to steal funds.
Create a malicious smart contract and set it as the “mainnetBridge” smart contract to steal funds, again via 3/5 multi-signature.
22. Will this actually happen? Personally, if I had to guess, I don’t think the funds will be stolen.
Regardless, I actually think the idea of Blast native gains is a pretty interesting tradeoff.
23. So while I personally think sending funds to Blast in its current state is risky, it is ultimately the user's decision to send or not, I am just sharing what I see here.
I still wish the best to the Blast team and everyone who has made a deposit.
