Points, airdrops, jackpots, native staking yields, and gas revenue sharing — this is what Blast promises. This highly anticipated Ethereum L2, an EVM-compatible optimistic rollup, was announced on November 21, 2023, by Tieshun Roquerre, aka Pacman, and launched on February 29, 2024.
Between its announcement and launch, Blast accepted ETH deposits via a one-way bridge, offering native yield and Blast Points accumulation, which promised entry into a future airdrop for early adopters. Despite criticism from commentators, including one of its major financial backers, Paradigm, this strategy boosted Blast’s popularity, attracting $600 million in its first week post-announcement. By January 2024, over $1 billion in deposits were recorded, and at the time of writing this article, Blast’s TVL is $3.16 billion, making it the fourth-largest EVM L2. This level of rapid growth and high TVL is unprecedented.
Blast’s Core Features and Yield Model
Blast definitely has impressive growth and marketing, but how does it work? Blast’s main attraction is its native yield capability for ETH and stablecoins. This is achieved in two ways. For the ETH side, users can deposit their ETH onto Blast in exchange for liquid L2 tokens. The deposited ETH is then automatically staked into Lido staking pools via Blast smart contracts, earning an interest rate of 4%. For stablecoins, users bridge them to Blast for USDB (Blast’s official stablecoin), which generates yield through MakerDAO’s T-bill protocol with a 5% interest rate. USDB can be redeemed for DAI when bridged back to Ethereum. Both methods use auto-rebasing to adjust supply value through smart contracts instead of being manually adjusted by humans. This enhances price stability and efficiency, in addition to mitigating market volatility.
Besides the yield generation, Blast rewards users with points based on their ETH/USDB balance. They also reward dApps with points based on their TVL. These points determine airdrop eligibility and allocation size. Blast Gold is awarded to dApps built on the chain to reward them for using Blast-native features, among other factors, and is distributed manually every 2–3 weeks or during jackpot events. Blast encourages dApps to distribute 100% of their accumulated gold and points back to their user base, but this is not an enforced requirement. Finally, points and gold can also be earned through inviting other users to Blast or Blast-associated dApps
A full breakdown of Blast’s smart contract architecture is beyond the scope of this article, but to give you an idea of it, please enjoy the following high-level diagram. If you would like to dig into the specific contracts, including access to their Etherscan pages, please refer to this site and scroll to the section titled “Smart contracts”.
Third-Party Dependencies: The Core Risk
Now we have a basic understanding of what Blast is and how it works. It sounds promising, doesn’t it? An innovative marketing strategy that rewards users and dApps while providing incentives for ecosystem growth and longevity. Well, that’s correct. It’s a genius product with an all-star team, generous financial backing, and a solid performance history. So, what’s the issue?
The problem lies in its intrinsic design. Blast’s main selling point is its native yield capabilities, which are handled by third-party DeFi protocols, specifically the Ethereum L1 dApps Lido and MakerDAO. Unfortunately, relying heavily on third parties introduces inherent risks. If any yield-generating pools or protocols on Lido or MakerDAO are compromised, the associated tokens of Blast users in those pools will be compromised as well. This is a security issue tied directly to third-party integrations. Blast’s dependence on Lido and MakerDAO’s security standards to protect its users’ funds could lead to significant financial issues for Blast users, including the potential for data breaches and security breaches.
Security Concerns Beyond Design
Blast has encountered other security issues as well. According to HTX Square, one of the most prominent issues is that Blast’s LaunchBridge contract (0x5f…a47d) is not a rollup bridge, but rather a “custodial contract protected by a 3/5 multisig address.” Jarrod Watts of Polygon Labs uncovered an additional concern regarding these multisig addresses, which he breaks down in this thread, they are newly created and their owner’s identities remain unknown. CryptoHopper goes on to question the legitimacy of Blast’s claim of being an L2, stating, “Blast lacks the necessary validity proofs for an L2 state root and does not have an anti-fraud mechanism in place.” The lack of an anti-fraud mechanism, along with cloud services and other additional security concerns, is further corroborated by L2Beat’s Blast Risk Summary pictured below.
The Importance of Continuous Security Assessments and Audits
Let’s revisit the intrinsic design issue. Lido and MakerDAO are giants in the Ethereum yield generation space, and they’ve taken many of the necessary steps to protect their contracts and infrastructure. Blast made a wise choice in building its major capability with these platforms. However, as we all know, the Web3 space is plagued by prolific security issues. Despite Lido and MakerDAO’s best efforts, continuous monitoring and security assessments are critical because cyber attacks and data breaches are inevitable in the current threat landscape. You might think this is common sense in this industry, but how could it happen in this situation? I wondered the same thing. Here’s what I found.
While digging through the documentation for Lido and MakerDAO, I noticed that MakerDAO has not published a security audit of its smart contracts in three years. Some of their contracts’ most recent public audits even go back five years. This raised concern for me because smart contracts can be susceptible to newly discovered vulnerabilities and should undergo regular risk assessments and secure controls reviews. To highlight just how many new vulnerabilities have been found in the world of smart contracts, I ran a quick query for smart contract CVEs in the NIST National Vulnerability Database. The results returned 584 records published between 2018 and 2024. While specific contracts may not be susceptible to all of those CVEs, they are likely susceptible to some. Thankfully, MakerDAO has a public bug bounty program through ImmuneFi, launched February 10, 2022, to help cover the security gaps in their contracts.
The Need for Proactive Collaboration and Security
Maintaining the security of smart contracts requires a multi-faceted approach, including both pre-deployment audits, periodic security audits, and bug bounty programs. Each method has its unique advantages and plays a crucial role. Pre-deployment audits identify and address vulnerabilities like business logic errors and other cyber threats before a smart contract goes live. Periodic audits tackle new vulnerabilities and risks from operational changes over time.
These audits are structured and systematic, providing thorough evaluations, detailed reports, and mitigation strategies. Bug bounty programs engage a wide pool of researchers for security testing, enhancing real-time threat detection, and offering potential cost savings by paying only for verified vulnerabilities. Additionally, the diverse skills of bug hunters can uncover a range of issues. However, the quality of submissions may vary, and bug hunters may overlook business logic flaws in favor of focusing on technical vulnerabilities, which grant them bug payouts. Despite these challenges, bug bounty programs provide continuous insights and foster a community-driven approach to security.
Here’s a chart to help visualize the many differences between these two approaches:
Conclusion: Building a Resilient Web3 Ecosystem
So, let’s recap. Blast’s core yield generation capability depends heavily on integration with the established yet third-party DeFi protocols, Lido and MakerDAO. While this choice leverages the strengths of these protocols, it also inherits risks that need to be managed. If any of these third-party protocols are compromised, it would directly affect the security and financial stability of Blast users. To mitigate this, Blast must prioritize the security of any third parties it integrates with. This sounds simple enough, but how exactly can they do that? One of the best ways is for Blast, or other large projects, to collaborate closely with their third-party partners to develop and agree upon their security standards. Regular communication and joint security testing can help validate these standards and improve upon them over time. Additionally, it’s advisable to ensure that all third-party partners are utilizing regular security audits and bug bounty programs to keep their contracts battle-tested.
Larger projects usually have the power to work with their partners to develop and execute on joint security standards, but many small-to-medium-sized projects do not have that type of influence. Don’t worry, there are ways for these projects to stay safe when integrating with third parties as well. First, smaller projects need to be meticulous when choosing their third-party providers. Proactively vetting third-party options for stringent security standards can save projects many headaches in the long run. If the third-party options do not meet a project’s required standards, developing in-house solutions might be a safer alternative, provided that the project has the resources to do so. Although this requires more effort and investment, it allows for complete control over the security measures. Finally, forming partnerships or alliances with other projects can help smaller companies collectively advocate for better security practices with larger third-party providers. A united front can have more influence than individual efforts.
Relying on third-party integrations is not a bad thing. In some cases, it is a necessity. I applaud Blast for utilizing their connections to build a better blockchain, but it is of utmost importance to have security at the forefront when building, especially when dealing with user funds. Relying on third-party integrations carries its own set of risks, but thankfully, there are ways to manage them. Thoroughly vetting providers, collaborating to develop standards, and maintaining continuous monitoring and adaptation of them over time can significantly mitigate third-party risks and help build a more secure blockchain ecosystem for us all.
At Resonance Security, we don’t just secure code, we secure ecosystems. From risk assessments to continuous monitoring, we help projects like Blast identify, understand, and mitigate cyber threats before they become catastrophic.
If you’re building on Web3, don’t wait for a headline-grabbing hack. Book a FREE consultation with our security experts today and take the first step toward a stronger, more resilient security posture.
About the Author
Grace Dees is the Cybersecurity Business Analyst at Resonance Security. She specializes in the intersection of traditional and Web3 security.
In her role at Resonance, Grace excels in bridging the gap between technology and business objectives. Whether that’s assisting in security auditing or fostering cross-functional collaboration to deliver impactful solutions aligned with client needs, she is dedicated to driving business success through a holistic approach.
.png)