Resonance Reflections: Third-Party Dependency vs. Risk on Blast

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 TVL Since Project Announcement

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”.

Diagram of Blast’s Smart Contract Architecture
Diagram of Blast’s Smart Contract Architecture

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. Blast’s dependence on Lido and MakerDAO’s security to protect its users’ funds could lead to significant financial issues for Blast users.

Blast has encountered other security concerns 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 additional security concerns, is further corroborated by L2Beat’s Blast Risk Summary pictured below.

Blast Risk Summary From L2Beat

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, security is never perfect, and compromises can still occur. 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 their smart contracts in three years. Some of their contracts’ most recent public audits even go back five years. This raised concern to me because smart contracts can be susceptible to newly discovered vulnerabilities and should be audited periodically to protect against those new discoveries. 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.

Maintaining the security of smart contracts requires a multi-faceted approach, including both pre-deployment and periodic security audits, as well as bug bounty programs. Each method has its unique advantages and plays a crucial role. ​​Pre-deployment audits identify and address vulnerabilities and business logic errors 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:

Security Audits vs Bug Bounty Program Comparison Chart

So, let’s recap. Blast’s core yield generation capability depends heavily on integration with the established 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 they integrate 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’s 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, providing 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.


“About Blast.” Blast Developer Documentation, Mintlify, Accessed 12 June 2024.

@PacmanBlur (Tieshun Roquerre). X,

“Blast.” L2BEAT, L2BEAT, 2024,

“Blast: Deposit | Address 0x5f6ae08b8aeb7078cf2f96afb089d7c9f51da47d | Etherscan.” Etherscan, Etherscan, 2024,

“Decoding Blast: Potential Risks and Controversies.” HTX Square, HTX, 20 Dec. 2023,

“Introduction.” Lido Docs, Lido, Accessed 12 June 2024.

Kessler, Sam. “Blast’s One-Week, $600m Haul Shows Promise of Yield, Pitfalls of Hype.” CoinDesk, CoinDesk, 9 Apr. 2024,

Knight, Oliver. “Blast Hits $1.1B in Deposits More than a Month Before It’s Due to Go Live.” CoinDesk, CoinDesk, 9 Apr. 2024,

“MakerDAO Bug Bounties.” Immunefi, Immunefi, 10 Feb. 2022,

“MakerDAO Technical Docs.” Maker Protocol Technical Docs, GitBook, 2023,

“MCD Security Audits.” MakerDAO Security, GitBook, Accessed 12 June 2024.

Morales, James. “Blast TVL Surges to $2.7 Billion — Emerges as Top Three L2 Following Mainnet Launch.” CCN, CCN, 7 Mar. 2024,

Morales, James. “Makerdao Explores Incorporating Tokenized T-Bills into Dai Collateral.” CCN, CCN, 8 Sept. 2023,

Morales, James. “What Is Blast? Staking-Focused L2 Attracts over $400m in 3 Days despite Multisig Security Concerns.” CCN, CCN, 24 Nov. 2023,

“NVD Search Results — Smart Contract.” NIST National Vulnerability Database, National Institute of Standards and Technology , 2024,

Singh, Jagjit. “What Are Rebase Tokens, and How Do They Work?” Cointelegraph, Cointelegraph, 9 Mar. 2024,

“The State of the Layer Two Ecosystem.” L2BEAT, L2BEAT, 2024,

Trummer, Anthony. “Product Security Audits vs. Bug Bounty.” Doyensec Blog, Doyensec, 2 May 2024,

Watts, Jarrod [@jarrodWattsDev]. “”Blast is just a 3/5 multisig…” I spent the past few days diving into the source code to see if this statement is actually true. Here’s everything I learned:” X, 23 November 2023,

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.

our certifications
OSCP certificationOSCE CertificationOSWE certificationCART CertificationAzure certifcationCyclone CertificationCARTP CertificationCRTP Certification

Let's Get Started.

Safeguard your applications, smart contracts and digital assets to stay ahead of potential threats.

Get started