Blockchain Protocol Security Audit for Rollups and Sidechains

Summary: So, it looks like decision-makers are starting to prioritize rollups and sidechains a lot more these days. But here’s the kicker: the security of these systems hinges on some pretty complex stuff. We're talking about things like proof systems, how data is made available, the paths for forced inclusion, who gets to upgrade what, and the rules around MEV. It’s all about those nitty-gritty details! This guide is your go-to audit playbook, packed with useful checks, real-life examples, and the freshest best practices. You can easily dive in and start using these tips right before you launch or move things over.

Why this matters now

In 2024 and 2025, we saw some really impressive advancements with Ethereum rollups! Hey, have you seen what's been going on lately? EIP-4844 really made a huge impact by cutting down those L2 data availability costs - pretty impressive, right? Plus, Optimism just launched its permissionless fault proofs, which is a game changer. Oh, and Arbitrum has got its Stage-1 guarantees all sorted out, so that’s a big win for them. Not to mention, we’ve got some alternative data availability solutions like Celestia, EigenDA, and Avail that have either hit the mainnet or are in beta right now. It's an exciting time in the space! These updates are pretty huge! They're going to shake things up when it comes to fees, keeping the system running smoothly, handling exits, staying resistant to censorship, and finding new ways to upgrade.

When you're checking out a rollup or sidechain, it's super important to make sure that the security audit at the protocol level digs a lot deeper than just the usual “smart contracts are audited.” It's super important to have solid proof that the entire system is secure from start to finish, even when things get a little hectic. And don’t forget, this also covers the governance and operational sides of things! (blog.ethereum.org).

---

1) Snapshot of the landscape (as of December 15, 2025)

So, EIP-4844, which is also known as Dencun, officially launched on March 13, 2024. It brought along some exciting new features, including the introduction of blobs and a whole new data-gas market! Recent data from the real world shows that rollup fees have taken a nosedive, dropping nearly 71%. Even more surprising, the cost per MiB has fallen by about 82%! That's quite a significant change! Just a heads up, do keep an eye on those demand spikes. They can definitely cause some price fluctuations. These days, keeping an eye on cost risks has become really important for L2 operations. (blog.ethereum.org).

Hey everyone! I've got some awesome news about the OP Stack! Governance has given the thumbs up, and we now have permissionless fault proofs live on OP Mainnet. This is a big deal because it’s part of Stage 1+ and introduces some exciting diversity among provers with Cannon written in Go and Kona in Rust. Exciting times ahead! Base has introduced a 7-day withdrawal challenge period, which is pretty cool. They’ve also clarified the finality semantics, helping decision-makers feel more confident in their choices. (blog.oplabs.co).

• According to L2BEAT’s most recent evaluation, Arbitrum One is currently sitting at Stage 1. It comes with a 10-day exit window because of a few delays that piled up. The BoLD dispute design from Arbitrum is really stepping up when it comes to guaranteeing censorship resistance. They've added this cool feature called a "Delay Buffer" that you can tweak, which makes it easier to speed up how quickly things get forced in during those annoying times of lingering censorship or outages. (l2beat.com).

So, if you're diving into Alt-DA options, there are some cool options to check out! First up, we've got Celestia, which uses DAS along with 2D Reed-Solomon coding and pruning windows--pretty techy stuff! Then there's EigenDA, which mixes erasure coding with KZG and focuses on stake-weighted quorums. And let's not forget Avail, where KZG is combined with DAS and features app-IDs and light clients. Lots of intriguing possibilities! Each of these comes with its own set of trust levels and operational assumptions, so it's really important to give them a careful review. Don't skip that step! (docs.celestia.org).

---

2) Audit scope that actually catches rollup and sidechain failures

Check it out! Here’s the checklist that 7Block Labs uses for those important pre-launch and migration audits. This is especially handy when working with rollups--think OP Stack, Arbitrum, and zk stacks--plus Ethereum-related sidechains like Polygon PoS and L3s. It's our go-to guide for making sure everything runs smoothly!

2.1 Settlement, upgrades, and emergency powers

Alright, let’s kick things off by mapping out all the upgrade authorities and what their specific thresholds are. For example, the Optimism Security Council has to hit a minimum of 75% approval from its members. On the flip side, the Arbitrum Security Council works a bit differently; they need at least 9 out of the 12 members to give their thumbs up. The folks at the Polygon Protocol Council have decided on a draft threshold of 7 out of 13. It's super important to figure out which contracts they can actually work with and what timelocks they need to stick to. Also, we really need to make sure there's some solid evidence that we're sticking to the Stage-1 rules. That means we've got to have at least a 7-day exit window in place, and we need at least 75% of the security council on board to block or mess with messages coming from L2 to L1. If you want to dive deeper into this, just head over to gov.optimism.io for all the details!

Alright, now let’s jump into what “emergency state” really means. It's really important to figure out which functions are on pause and who has the power to hit that pause button. Take Polygon’s zkEVM, for instance. If there's ever a need to kick things into emergency mode, it can be triggered by either the owner or the security council. But here’s the twist: even someone with a non-deterministic state proof can step in and activate it. When that happens, it puts a stop to both sequencing and bridging. Even though this is meant to keep everyone safe, it can definitely create some trust issues with the operators while things are on hold. Don’t forget to write this down really well in your risk memo! If you're looking for more details, check this out: docs.polygon.technology. It’s got a ton of great info!

• Finally, let’s take a moment to go over those exit windows from start to finish. We should really think about a few things like contract timelocks, how long the challenge periods are, and the rhythm for batching things together. It's super important to make sure users can get to their assets on their own, just in case the team goes AWOL. L2BEAT has put together a solid framework for 2025 that really outlines what to expect for Stage 1 and Stage 2. It’s definitely worth checking out and using as a benchmark in your report! If you need it, here’s the link: l2beat.com. Check it out!

Deliverables You Should Ask For:

• Think of it as a user-friendly map that clearly shows you the special roles, time constraints, and functions you can call on.
• Here’s a rehearsal runbook for emergency upgrades that includes timestamps matched up with on-chain events.

2.2 Proof systems, from “training wheels” to prod

• Optimistic Rollups: Just a quick reminder to double-check that fault proofs are actually permissionless in production, not just in testnets. It’s an important detail! Hey, just a quick reminder about the OP Stack! Make sure to highlight the governance approval and that it’s now live on the mainnet. It’s a big deal!
  It’s definitely worth taking a look at the challenger incentives and griefing caps too! You know, just to stay in the loop.
  Also, make sure there's a good mix of implementations, like Kona and Cannon, and double-check that the block-gas limits work well for proving. (blog.oplabs.co).

Hey, just wanted to give you a quick heads up--Arbitrum One is currently listed as Stage-1 over on L2BEAT. Hey! Just a heads up to check out the BoLD parameters--stuff like the Delay Buffer and inclusion windows. Make sure your chain (Orbit/L3) is set up with some good default values. (l2beat.com).

• ZK Rollups: Get into the nitty-gritty of the prover pipeline, and don’t forget to check out ZKsync’s Boojum. Also, keep an eye on those claims for the 2025 Atlas/Airbender. It's important to keep tabs on the throughput and the hardware setup too! Oh, and don’t forget to consider what happens if the provers hit a snag and stall. It’d be smart to have some backup plans in place, like dummy executors or some kind of emergency mode, just to keep things running smoothly. (docs.zksync.io).

What to test: Alright, so when it comes to dealing with tough disputes and those complicated bisection trees, it’s super important to stay vigilant. Make sure you’re keeping an eye out for those watchdog challengers, especially when DoS attacks are on the radar.

• "Prover diversity" exercises: Start by shutting down the main prover, but don’t worry! Just make sure that the backup system or an alternative setup can still get everything done within the service level agreement (SLA).

2.3 Data availability (DA) assumptions and cost risk

• Ethereum blobs (EIP-4844): What's really exciting about this is that the fees stay super low until we reach a certain level of demand. But beware--once that happens, the price for data-gas can spike unexpectedly, sometimes in just a matter of hours! It's definitely a good idea to set up alerts and have some budget cushions ready for those unexpected blob price spikes. Trust me, it’ll save you a lot of headaches down the road! Oh, and make sure you run a few tests in staging, just in case! It’s a good idea to use calldata or alt-DA as a backup. Trust me, it’ll save you some headaches later on! (ethresear.ch).
• Celestia: So, this system uses a Decentralized Availability Sampling (DAS) approach combined with 2D Reed-Solomon codes and also incorporates light-client sampling. Pretty cool, right? Hey, just wanted to give you a quick heads-up about the 30-day sampling/pruning window (CIP-4). If your business is looking to tap into data that's older than 30 days from light nodes, it’s smart to think about using archival nodes and setting up some retrieval service level agreements (SLAs). Trust me, it’ll save you a lot of hassle down the road! (docs.celestia.org).
• EigenDA: So, here’s the deal--it's all about blending erasure coding with KZG commitments and adding in those stake-weighted quorum attestations. Sounds techy, right? But it's pretty interesting how all these pieces come together! Just make sure you really understand the coding rate γ and the safety and liveness thresholds. They're super important! It's a good idea to keep an eye on the quorums you depend on and understand the slashing model that backs them up. (docs.eigencloud.xyz).
• Avail: This is the spot where KZG and DAS come together. It also includes app-IDs, which means clients can easily pull data specifically from their own namespace. If you’re thinking about connecting your app-chain state to the EVM, make sure to take a moment to review the light-client integration and the relayer trust model. It’s really important! (docs.availproject.org).

2.4 Sequencer, liveness, and forced inclusion

• OP Stack: Let’s dive into how the forced-transaction process, specifically the “deposit to OptimismPortal,” behaves when there’s downtime. We should really get a clear picture of that. So, we're anticipating a maximum drift of about 30 minutes and a sequencing window that could stretch up to 12 hours. It's key to demonstrate that deposits reach their final destination in a reliable manner, and they can even prompt withdrawals, even if the sequencer isn't playing ball. (docs.optimism.io).
• Arbitrum: Alright, let’s take a look at the settings for the delayed inbox and force-inclusion. Just so you know, they usually default to about 24 hours or 5760 L1 blocks. Let's take a moment to check out the SDK setup, too. It's really important to keep track of how changing these parameters impacts censorship resistance. (docs.arbitrum.io).
• Incident-informed SLOs: So, here’s the scoop - OP Mainnet has had a few “unsafe head stalls” lately, mostly because of some hiccups with L1 nodes or blob availability. Over on Base, they’ve been dealing with a few delayed transactions and some missed blocks as well. To really tackle these kinds of issues, it's super important to set up solid Service Level Objectives (SLOs), get proper alerting in place, and plan for staged failovers. (status.optimism.io).

2.5 Bridges and token escrows

Hey, just a quick reminder: it's really key to keep messaging security and token escrow security separate from each other. Hey there! Looking ahead to 2025, L2BEAT has some interesting updates. They’re suggesting that when we look at Stage assessments, we should really focus on the messaging bridge. This is important because escrows can provide some different types of guarantees. Just something to keep in mind! Hey! Just a friendly reminder to update your inventory and user disclosures to keep everything in sync. You can check it out here: forum.l2beat.com. Thanks!

Hey, so when we talk about “fast withdrawals” or those committee-based exits like AnyTrust or Orbit, it’s super important for users to have a backup plan. You never know when something might go sideways, right? If there are any issues with the committee, they should definitely be able to switch over to the standard, challenge-secured withdrawals. (docs.arbitrum.io).

2.6 MEV, ordering policy, and preconfirmations

• Arbitrum Timeboost is seriously a game changer! It lets chains snag some MEV while tackling those annoying latency issues head-on. This totally changes how people think about ordering. For sure, take a look at the alpha-stage config and see how it fits with what you're doing in the DeFi space. (docs.arbitrum.io).
• I gotta say, OP Stack Flashblocks is really something! They manage to deliver preconfirmations in less than a second! Just a quick heads up, though--definitely take a look at the audit for those equivocation protections. It's also a good idea to familiarize yourself with the user experience details, especially since those preconfirmations can be reversed. Better safe than sorry, right? (specs.optimism.io).

If you're looking into shared and decentralized sequencers, Espresso is definitely a strong choice. It provides BFT confirmations and helps prevent any issues with sequencer equivocation. It's great to get a glimpse of their current trust model, especially since they’re using permissioned validators in Mainnet 0. You’re working with data that's current up until October 2023, and you’re looking into how PoS is shaping up, especially when it comes to its idea of “finality” compared to Layer 1 solutions. (espressosys.com).

2.7 Restaking and shared‑security dependencies

Hey there! Just a quick heads up--if you’re working with EigenDA or any restaked AVSs, double-check that slashing is all set and good to go. By the way, EigenLayer started slashing on April 17, 2025, so make sure you’re aware of that! It’s super important to consider the ripple effects--like what could go down if a glitch in an AVS causes a lot of operators to start slashing. You never know how interconnected things can be! Hey, just a quick reminder to make sure you’re incorporating indemnities or some sort of buffers in your risk management plan. It’s super important to cover your bases! For more info, you can dive into the details here.

---

3) Practical examples with fresh details

Example A: Upgrading an OP Stack chain to Stage‑1 guarantees

Checklist We Run:

• Just double-check that all your documents are current.
• Let’s make sure we’ve got the meeting times and who’s coming sorted out.
• Make sure everything's good to go with the tech setup for the presentations.
• Take a look at our agenda and the main points we want to cover.
• Grab all the materials or resources you might need.
• Make sure to check your internet connection and all your equipment.
• Let's check in on the action items we talked about in our last meetings.
• Make sure that everyone can get to the files they need.
• Let’s gather some thoughts on how the last meeting went.
• Don’t forget to set some reminders for those deadlines you’ve got coming up!

Don't hesitate to throw in anything else you think might be helpful!

• Fault-proofing in production: Great news! We’ve got governance-approved fault proofs that don’t require permissions, and they’re officially live on OP Mainnet! Just a quick reminder to double-check that your fork is all set and to tidy up any leftover allowlists. And hey, make sure to jot down your process for those Base-style 7-day withdrawals in your own docs too! It's super important to keep track of everything. If you want to dive into the details, just click here. You’ll find everything you need!
• Challenge period: So, here's the deal: L2BEAT has set a minimum challenge period of 7 days for Optimistic rollups if they want to be recognized as Stage 1. Hey, just a quick reminder to double-check your timers! Don’t forget to include any “air gaps” or grace delays to make sure everything lines up with the requirement. It’s always good to be thorough! If you’re looking for more details, you can check it out here.
• Prover diversity: Let's get Kona (Rust) fired up and running alongside Cannon (Go). It’s about time! Just a heads up--make sure your MAX_GAS_LIMIT aligns with fault-provability. This way, you can avoid running into any of those tricky “unprovable” blocks. Make sure to note this in your change log and ops runbook! If you're looking for the proposal, just click here to check it out!
• Forced inclusion drills: Consider running a drill where you mimic a 12-hour downtime for the sequencer. Go ahead and process your deposits with OptimismPortal, and don’t forget to check that everything’s included as it should be. Plus, make sure to verify the whole withdrawal process from start to finish! If you’re looking for some help, take a look at the info here. It’s got all the details you need!
• Security Council policy: Remember to monitor that ≥75% threshold, keep an eye on the two-week waiting period for any upgrades, and don’t forget about the veto process. Don't forget to share user-facing promises that really match up with the Stage-1 L2BEAT principle.
  If you’re looking for more details, just click here.

The outcome is a transparent and straightforward Stage-1 rollup stance that outside reviewers can easily examine and verify.

Example B: Hardening an Arbitrum Orbit L3 with BoLD and fast exits

Hey there! Just wanted to give you a quick heads-up about the 24-hour force-inclusion settings. They’re already set up by default, but if you're thinking about adjusting them for a smoother user experience, just keep in mind that there are some trade-offs when it comes to censorship resistance. It’s always a balancing act! Hey, don’t forget to wire in those “forceInclude” paths for InboxTools in the SDK into the runbooks. Also, make sure to add in the gas estimates and custody info for those L1 fees. It's super important! If you're looking for more info, you can check it out here.

• BoLD Delay Buffer: This feature lets you set up certain thresholds that will kick in and automatically reduce inclusion times whenever it detects any censorship or outages happening. This way, validators can keep those dispute games going strong! And hey, make sure to put together some incident playbooks that lay out the whole process. It's super important! Check it out here.
• Quick Withdrawals: When it comes to fast exits, make sure to stick with committee-based options on AnyTrust-style chains that hit the minimum validator or DAC requirements. It’ll keep things running smoothly! Just remember to always keep those canonical challenge-secured withdrawal paths in place. They’re really important! If you're looking for more details, just click here. There’s a lot of great info waiting for you!
• MEV Policy: So, if you’re thinking about using Timeboost, make sure you put together a clear policy about where your order flows are coming from and any associated fees. It's super important! It’s super important to check for any conflicts between builders and sequencers. If you're curious to dive deeper, you can check it out here. It's definitely worth a look!

Example C: zk Rollup on alt‑DA (Celestia/EigenDA/Avail)

• DA guarantees:
• Celestia: Check out how DAS light clients ensure availability. It’s pretty interesting! Oh, and just a quick reminder to bring up that 30-day sampling and pruning window! Also, it’s super important to note that archival providers need to be on top of managing historical proofs and making sure they meet those retrieval SLAs. Take a look at this: docs.celestia.org. It's pretty informative!
• EigenDA: Don't forget to keep track of the quorums, the coding rate (γ), and the stake thresholds. It's important stuff! It's really crucial to test retrieval with different groups of operators and make sure to verify the KZG proofs from beginning to end. More info here: (docs.eigencloud.xyz).
• Avail: You gotta demonstrate that your client can grab those per-appID slices. Plus, make sure your relayer is checking the DAS confidence for every block to keep things legit. For all the info you need, check this out: (docs.availproject.org). It’s got everything laid out for you!
• Prover stalls and emergency modes: It's super important to sort out what happens when the prover comes to a stop. You could think of it like the emergency mode for Polygon's zkEVM. It’s important to keep emergency discretion to a minimum and ensure that we have public post-mortems in place. If you want to dive deeper into this topic, check out this link: docs.polygon.technology. It’s got all the details you need!

---

4) Incident‑driven audit tasks you should not skip

• OP Stack Stalls: In 2024, we experienced a few instances of "unsafe head stalls" on the OP Mainnet. These were mostly caused by some instability with the L1 nodes and problems related to blob data availability. It’s definitely smart to set up design probes that can catch when there’s a gap between the unsafe and safe heads. This way, you can jumpstart those forced transaction workflows to keep everything in check. Check it out here.
• Base outages: If you want to stay updated on any missed blocks or transaction delays, just head over to Base's status page. It's the best way to keep tabs on everything! Just a quick reminder to make sure your service level objectives (SLOs) and autoscaling strategies are ready to tackle any similar incidents that might pop up. It's always good to be prepared! Feel free to check it out here!
• Polygon zkEVM Emergency: So, on March 24, 2024, they had to activate an emergency state to recover from a sudden outage. It was a bit of a scramble to get things back on track! As you're going through your audit, just remember to check in on a few key things. First off, figure out who actually has the power to kick off those emergency procedures. Then, take a look at what gets put on hold during those situations. Lastly, don’t forget to see how the controls for restarting things work and how the timelocks are set up. It'll make a big difference! If you're looking for more info, just click here. You'll find all the details you need!
• zkSync news: So, on Christmas Day 2023, zkSync ran into a bit of trouble when a safety feature kicked in, causing a 5-hour outage. It wasn’t the best holiday surprise! Oh, and don’t forget about that airdrop distribution exploit back in 2025. It was all about recovering funds from that situation. These events are perfect for checking out your admin key and how you handle distribution processes that don't really connect to the protocol. It’s a great chance to see how everything’s working on your end! Take a look at the details here. It’s an interesting read!

---

5) Emerging best practices we now recommend by default

• Show off diversity and redundancy:
• OP Stack: We're working on creating several independent, super reliable setups (think Cannon and Kona). Plus, we’ll keep an eye on gas usage to make sure that every block can be easily verified. Check it out here.
• ZK stacks: Think about setting up a backup proving path, or maybe even a marketplace where third-party provers can pitch in. Don't forget to lay out those service level agreements (SLAs) to keep everything on track. And when you're at it, make sure to jot down the specifics of your GPU and CPU setup based on the transactions per second (TPS) you're aiming for. If you're looking for more details, you can check it out here.
• DA Risk Hedging After 4844: Make sure to stay updated on blob data gas prices by setting up some alerts. It’s a good idea to put automatic throttles in place, too. Don’t forget to have a backup plan for your calldata in case you find yourself in a bind with critical batch needs. And hey, it’s always smart to have some budget buffers ready just in case prices shoot up tenfold! If you want to dive deeper into this topic, check out the discussion here. It’s got some great insights!
• Strong forced-inclusion UX: Hey there! So, I put together this guide called “Users Can Exit Without Us.” It's all about how to make sure our users feel empowered to leave if they want to. It's a pretty important topic, and I think it’ll really help us understand their perspective. Let me know what you think! Alright, let’s break this down! When it comes to OP Stack, it's all about showing users how deposit-based forced transactions work. It's a neat way for them to understand the ins and outs of making these transactions.

Now, if we switch gears to Arbitrum, we need to dive into the whole delayed inbox and forceInclude process. This one's a bit more complex, but once we get into it, it’ll make sense. So, let’s get ready to share some knowledge! Hey, just a quick reminder to add those wallet snippets and RPC endpoints! If you need a bit more help, check out this link for some extra guidance: here. It's super useful!

• Ordering policy disclosure: Hey there! Just a quick heads-up: if you're planning to dive into Timeboost on Arbitrum or Flashblocks with Optimistic Protocol, it's super important to be open about a few things. Make sure you're clear about the risks that come with preconfirmation revocation, the policies builders have, and how those fee splits are gonna shake out. Being upfront about these details can really help everyone involved! If you're looking for more info, make sure to take a look at the details here. You won’t want to miss this!
• Shared/decentralized sequencing pilots: Espresso confirmations are a great way to reduce the chances of misunderstandings and really boost the experience for users across different rollups. We really need to nail down the details of our BFT trust model right now, especially since we're planning to use a permissioned validator set and are working on the Proof of Stake setup. This way, we can make sure users don’t confuse it with L1 finality. Dive deeper here.
• Restaking discipline: Hey, just a heads up! If you’re using EigenLayer or EigenDA, keep in mind that slashing is now in effect. Don’t forget to lay out your cascading-risk limits in a clear way! You know, things like how much you’re willing to risk on each position, having some emergency funds ready, and those governance “kill-switches” just in case. It’s super important to keep everything transparent! Get more insights here.
• Stage alignment: Hey there! Just a quick reminder to align your work with L2BEAT’s 2025 Stages. You know, like hitting those ≥7-day challenges for ORUs and making sure you keep that smart contract compromise below the ≥75% threshold. Also, don’t forget to share your compliance status for each environment--mainnet and canary. Thanks! More details available here.

---

6) Sidechains: what’s different and how to audit them

Sidechains Overview

So, sidechains like Polygon PoS do their own thing when it comes to security. They don’t rely on Ethereum for that. Instead, they’ve got their own consensus mechanisms and a unique set of validators that keep everything running smoothly. Alright, so if you're about to jump into an audit, here are a few things you should definitely keep in mind:

Your Audit Must:

• Check Out the Consensus Mechanism: Take some time to get a feel for how the sidechain’s consensus operates. It’s super important to make sure it’s strong and dependable.
• Check Out the Validator Set: Take some time to find out who the validators are, how they get picked, and if they’re someone you can actually trust.
• Look into Security Features: It’s super important to check that the sidechain has all the right security measures to keep it safe from attacks or any weaknesses. You definitely don’t want to take any chances here!
• Check Out the Smart Contracts: Take some time to look over all the smart contracts that have been deployed on the sidechain. This will help us spot any potential problems or weaknesses that might be lurking around.
• Look into Transaction Finality: Make sure the way we confirm transactions is straightforward, and keep an eye out for any potential delays or forks in the chain.
• Think About Interoperability: Take a moment to look into how the sidechain connects with Ethereum and other blockchains. Don’t forget to check out any bridges or cross-chain features that might be in play!
• Check Out the Tokenomics: Dive into the economic perks of the sidechain. You’ll want to see how the tokens are handed out and keep an eye out for any inflation issues that might pop up.

If you keep these things in mind, you’ll be well-equipped to dive into your audit of sidechains like Polygon PoS.

Check out the size of the validator set, how the stakes are distributed, the slashing rules in place, and who’s got the authority to make changes. It’s important to get a good grasp of all these details! Make sure you keep an eye on who's in charge of the important upgrade multisigs, and don't forget to check the thresholds and timelocks they’ve set up. So, just to give you an example, Polygon is moving to a 13-member Protocol Council. To make any changes to the standard, they’ll need a majority vote--specifically, 7 out of the 13 members have to agree. (forum.polygon.technology).

• Make sure to jot down any updates from the consensus client and keep track of any ongoing issues. So, just to give you an example, there’s been a security patch for Heimdall/Tendermint that addresses the issue of spreading invalid block parts. This was actually reported on March 27, 2025. (forum.polygon.technology). Bridges are a key piece of the puzzle; they’re not just some extra feature hanging around. When it comes to sidechain bridges, they actually carry the most risk. We really need to make sure we've got a strong canonical escrow set up, along with detailed audits, transparent incident reports, and some live monitoring for state synchronization and those exit queues. It’s all about keeping everything running smoothly! (docs.polygon.technology).

---

7) Concrete deliverables you should require from any security partner

• Threat Model and "Chain of Trust" Diagram: This section dives into everything from how settlements and proofs work to data availability (DA), bridges, sequencers, and councils. It's all about understanding the connections and potential risks involved.
• Privilege map and timelock proofs: In this section, we’ll explore who gets to call the shots on upgrades and how fast those changes can roll out. Hey, just a quick reminder to make sure you cover any emergency powers and the restrictions that come with them. It's really important to keep that in mind!
• Forced-inclusion drills with artifacts: We’re diving into transaction hashes, inclusion timestamps, and RPC traces to ensure everything’s running as it should. It’s all about keeping things on track and making sure we don’t miss a beat!
• DA resilience report: This report covers stress tests on blob prices, tests for retrieving alt-DAs, and a well-thought-out archival node plan for Celestia, all focusing on 30-day periods.
• Prover continuity plan: So, we've set up some solid metrics for tracking how quickly we can spot issues (that's our Mean Time To Detection, or MTTD) and how fast we can bounce back from them (which we call Mean Time To Recovery, or MTTR). Plus, we've got some handy fallback runbooks and budgets in place to make sure we stay on top of everything.
• MEV/Ordering Policy: Basically, this is about keeping track of how we set up Timeboost and Flashblocks. We need to tackle any preconfirmation issues that might pop up and make sure we're on good terms with our builders.
• Stage Compliance Appendix: This is a really useful guide that outlines the L2BEAT Stage-1/2 criteria and provides links to the supporting evidence. Hey, you should definitely give it a look at l2beat.com. It’s worth your time!

---

8) Brief “in‑depth details” on a high‑leverage test: Forced‑inclusion end‑to‑end

Run this before mainnet:

Just follow these steps to get everything set up right!

1. Install Dependencies
   To kick things off, go ahead and gather up all the essential dependencies you’ll need for your setup. You can easily do this by just running:

   npm install

2. Configure the Environment
   First, you'll want to get your environment variables all set up. Hey there! Just wanted to share a quick guide on what you might need:

   export NODE_ENV=production
   export API_KEY=your_api_key_here

3. Run Tests
   Before you jump into the mainnet, it’s really crucial to test everything out first. To run your tests, just go ahead and execute this command:

   npm test

4. Deploy to Staging
   After you've had a smooth run with testing, go ahead and deploy it to your staging environment to check out how it's working. Use this command:.

   npm run deploy:staging

5. Monitor for Issues
   Make sure to regularly check out your performance metrics and logs. It’s a good way to spot any potential problems before they turn into bigger issues. Feel free to set up alerts, or you can just pop into the logs from time to time to keep an eye on things.
6. Launch on Mainnet
   Alright, if everything checks out, you’re all set to launch! Just make sure you follow any specific guidelines for your mainnet deployment. But generally, it’ll go something like this:

   npm run deploy:mainnet

Hey, remember the thrill of going live? It's such an awesome feeling! So let’s take a moment to celebrate your successful launch! 🎉

• OP Stack: Alright, the first thing we need to do is pause the sequencer in the canary environment.
  Alright, time to make a deposit using the OptimismPortal. Go ahead and get that sorted! Hey, just a quick reminder to double-check that you’ve got everything covered according to the 12-hour sequencing window rules. It's easy to overlook, so take a moment to verify! Next, go ahead and use the withdrawal path to show that everything is working smoothly when it comes to exits--no need for the team's help here! Make sure to save those logs for L1 and L2 heights, along with the timestamps and portal events. You don’t want to miss out on that important info! If you’re looking for more details, you can check it out here.
• Arbitrum: First, go ahead and submit to the delayed inbox. After that, just kick back and relax for about 24 hours.
  Next, go ahead and call forceInclude with the InboxTools from the SDK. This will give you a better look at the side effects on the L2 side. Once the challenge period is over, go ahead and wrap up your withdrawal. It’s definitely worth keeping track of how adjusting delayBlocks and delaySeconds impacts things. Noting those changes can really help you understand their effects better. If you want to dive deeper into the details, you can find everything you need here.

Why does it matter? Well, these are the only things users can really count on if there's a hiccup with the sequencer or if they face any censorship issues. When you share the runbook and hashes, you’re really showing your institutional partners that they can trust you. It's one of the best ways to build that confidence! (scalability.guide).

---

9) What 7Block Labs does differently

We link protocol audits to actual incidents you might encounter, like unsafe head stalls, prover halts, and DA congestion. This way, you can see exactly how your forced-inclusion and exit invariants stand up when these real-world problems arise. We make sure to test ourselves against Stage-1 expectations by using some outside benchmarks, like L2BEAT 2025. It's not just about sticking to our own checklists! Take a look at this: l2beat.com. You might find it interesting! When it comes to alt-DA, we really take a closer look at the specific light-client and quorum assumptions you're working with. This includes things like Celestia DAS windows, EigenDA coding rates and quorums, plus that Avail app-ID filtering. We’ll demonstrate that your retrieval process is solid, even when you're dealing with only a part of the operator sets. For more info, check out the details here: docs.celestia.org.

• We break down the upgrade powers, diving into all the details like signer thresholds and timelocks. This includes info on the Optimism and Arbitrum Security Councils, as well as the Polygon Protocol Council. Plus, we’ve got some emergency procedures that users should definitely be aware of before they start depositing any funds. Check it out here: gov.optimism.io. You won't want to miss this!

---

Key references (selected)

Hey, if you're curious about EIP-4844 and what's next for the economics after it, definitely take a look at the newest updates from the Ethereum Foundation. You can find some interesting insights over at ethresear.ch too! Check out these resources--they're great for helping you figure out costs and get ready for those unexpected price jumps. (Read more here).

• Stage framework for rollups (2025): L2BEAT has really nailed it with their latest explainer! They've also shared some updates from the forum, diving into the challenges we face with ≥7-day ORUs and why a ≥75% smart contract compromise matters when we're talking about L2 to L1 block forging. It's definitely worth checking out if you're into this stuff! (Check it out).

Hey everyone! Just wanted to give you a heads-up about some exciting news from OP Labs that you definitely don’t want to overlook. They’ve got some updates on OP Stack fault proofs and prover diversity, and trust me, you’ll want to pay attention to this. Also, don't forget to check out the scoop on Upgrade 16--it's all about Kona and Cannon! (Get the scoop here).

• Check out the Arbitrum Stage-1 page and the BoLD docs: You've got to see the Timeboost preview! (Dive into Arbitrum).
• Forced-inclusion docs for OP and Arbitrum: Check out this handy guide on Base finality and other important stuff! (Learn all about it).
• Alt-DA Official Docs: Check out the scoop on Celestia, which combines DAS and pruning, EigenDA that mixes erasure coding with KZG and quorums, and Avail that features KZG and DAS along with app IDs. Dive in! (Read the docs).
• Shared sequencers: Don't forget to peek at the FAQ from Espresso for all the juicy details on Nitro integration notes! (Learn more).
• Incident Reports/Status Pages: Keep an eye on what's happening with Optimism's status issues and check in on how Base is doing right now. (View the status).
• Polygon governance/emergency updates: They've put together a proposal for the Protocol Council, rolled out an emergency mode for zkEVM, and sorted out some issues with Heimdall. (Find out more).

---

Bottom line

If you’re looking to get a solid audit for rollups or sidechains nowadays, it’s crucial that it actually demonstrates--rather than just claims--that users can do a few key things. First off, they should be able to exit without depending on your team. Second, they need to be able to manage sequencer downtime or censorship on their own. Third, it's important that they can avoid those sneaky “silent” upgrades that might endanger their funds. And finally, they should be able to deal with any data availability or prover hiccups while still meeting those all-important service level objectives (SLOs). If you're searching for a comprehensive audit that really gets into the nitty-gritty of your protocols, governance, and operations--plus some hands-on drills and outside benchmarks--then 7Block Labs is definitely the way to go. They’ve got you covered!