Blockchain Protocol Security Audit: What’s in Scope and What Isn’t

Decision-Makers Guide to Drawing the Line (Precisely) for Meaningful Audits

When you're diving into audits, it's crucial to focus on the real risks instead of getting caught up in all the distractions. Alright, let’s chat about how you can really nail down that line you want to draw.

Understanding the Difference Between Noise and Real Risk

Alright, let’s get straight to the point. You need to understand what you're up against. So, when we talk about noise, we're really just referring to all that background chatter--the irrelevant info that can pull your focus away from what truly matters. On the flip side, real risk is the stuff that deserves your attention; it's the important information that you really need to keep an eye on.

Common Types of Noise:

• Minor discrepancies
• Outdated information
• These incidents don’t happen often, but they’re not a big deal.

Key Indicators of Real Risk:

• Common problems that keep popping up.
• Signs that hint at a bigger issue.
• Places where rules or compliance could be questionable.

How to Draw the Line

1. Define Your Risk Criteria

Take some time to figure out which risks are the biggest deal for your organization. It's important to know what really matters to you and your team! This might involve chatting with your team to ensure everyone is on the same wavelength.

2. Use Data Analysis Tools

Use data analytics tools to sort through all the information. These tools are great for helping you catch trends and spot any outliers without getting too caught up in all the nitty-gritty details.

3. Prioritize Your Findings

After you’ve gathered your data, take some time to sort through what you’ve found and rank everything by importance. What do we need to tackle right away? And what stuff can chill for a little while?

4. Collaborate with Stakeholders

Don’t tackle this solo! It’s a great idea to loop in other departments or stakeholders to hear what they think. Their insights can really help shape your approach! This will make sure you don’t miss out on anything important.

5. Regularly Review and Adjust

Things are always changing, and it’s a good idea to update your audit criteria to keep up with the times. Try to get into the routine of regularly checking your risk parameters and tweaking them when necessary. It's a good way to stay on top of things!

Conclusion

To make your audits really effective, it helps to get a grip on what separates noise from actual risk. Start by setting some clear criteria for what you’re looking at. Make good use of data tools--they can really streamline the process! Prioritize what you find so you can focus on the big stuff first. Don't forget to collaborate with others; two (or more) heads are usually better than one. And lastly, make it a habit to review things on a regular basis to keep everything sharp.
This way, you’ll be ready to face real challenges head-on and dodge any distractions that come your way.

If you're curious about risk management and want to dive deeper, definitely take a look at this resource. It has some great insights!

---

Why scoping matters now

Since the Dencun upgrade for Ethereum dropped on March 13, 2024, rollups have started posting their data as “blobs,” thanks to EIP-4844. It's pretty cool to see how these updates are shaking things up! So, this update is great for slashing Layer 2 data costs, which is a win! However, it does come with some fresh risks tied to blob gas markets, data availability (DA), and proof systems. Just something to keep in mind as we navigate these changes! Make sure your audit scope considers these new factors--it’s time to ditch those outdated assumptions from 2021! Trust me, staying current is key! (blog.ethereum.org).

In the 2024-2025 timeframe, a bunch of important L2 solutions launched or revamped their fault and fraud proofs. So, just to give you an example, OP Mainnet made the switch to permissionless fault proofs back in June 2024. Then, on February 12, 2025, Arbitrum rolled out its BoLD dispute protocol for both One and Nova. Exciting stuff happening in the space! If you’re diving into a project in the L2 space, be sure to thoroughly check out the specific proof and withdrawal paths your users depend on. Seriously, no skimping on this! It’s super important to get it right. If you're curious to dive deeper into this, you can check it out here. Happy reading!

You know, real-life situations keep reminding us that some of the biggest losses don’t really come from “math bugs.” "Instead, they're usually linked to access control problems and the way different systems interact with each other." Let’s talk about that incident from May 2024. There was a pretty wild situation where a compromised minter role ended up minting a staggering 5 billion GALA tokens. Can you believe it? That's a massive amount! It wasn't exactly a breach of the contract. It was more like a hiccup in the admin process. When you’re looking at risks, it’s super important to pay attention to the threats posed by admin keys and operational controls, rather than just zeroing in on how good the code is. (news.gala.com).

---

Scope, by layer (and what to exclude)

Think in layers. Security risks pop up when we start making assumptions that go too far or cross certain lines.

1) Base protocol and network assumptions

If you're running your own L1 or L2, or if you're making some changes to the core components, be sure to include this!

Alright, so when we talk about consensus and networking surfaces, there are a few key things you’ll want to keep in mind. First up, think about peer selection--it’s all about picking the right folks to communicate with. Then there’s gossip validation, which basically ensures that the info being shared is legit. You can’t forget about the fork-choice too, since choosing which chain to follow is super crucial. And of course, you need to think about DoS tolerance to make sure your system can handle any potential attacks.
Let’s take a moment to consider how the timing of blocks and attestations after EIP-4844, as well as the rate at which forks happen, come into play here. It's really fascinating to see how these elements interact and influence each other! If you want to dive deeper into the details, just click here. You’ll find all the info you need!

• Key Execution-Layer EIP Changes to Keep an Eye On:
• EIP-1153 (Transient Storage): This one brings in some fresh state lifecycles, so it’s a good idea to keep an eye out for things like “wipe-after-use” problems and any possible reentrancy issues. Just make sure to audit carefully!
• EIP-5656 (MCOPY): So, we're diving into the nitty-gritty of bounds and copy logic, along with some memory aliasing stuff too.
• EIP-6780 (SELFDESTRUCT Constrained): Hey, just a heads-up! If you've been counting on selfdestruct for your upgrade and proxy setups, you might want to take a moment to rethink that strategy. Things have gotten a little trickier, and those assumptions are not as solid as they used to be.
• EIP-4788 (Beacon Root in the EVM): Just a quick reminder to make sure you double-check how it's being used, and don’t skip those important replay and consistency checks! If you want to dive deeper into the topic, check out this blog post. It's packed with great information!
• Data Availability: If you're considering alternative data availability options like Celestia or EigenDA, it's really crucial to take a close look at the data availability guarantees you’re actually getting. Check out stuff like sampling, proof-of-custody, and your rate limits and tiers. Don’t forget to take a look at your Level 1 verification path too! If you're curious to dive deeper into this, check out the Celestia docs. They have a lot of great info!

Leave out:

• Let’s talk about what we can expect in terms of network performance and transaction fees. Take a broader perspective on "ecosystem health" when it comes to the variety of public clients, unless your product is specifically designed for a certain client version.

Deliverables:

• We've got a threat model that lays out the safety and liveness invariants in a way that’s easy to understand.
• We’re running some simulations to highlight possible abuse scenarios that might come up due to blob scarcity--think pricing spikes--and how it impacts data connectivity and availability.

2) Rollup/stack specifics (OP Stack, Arbitrum, ZK stacks)

Looks like your message didn't quite make it through! Sure thing! Just send over the text or details you want me to work on, and I’ll be happy to help.

• Current state of the proof system:
• Optimistic: We've got some really exciting things going on! Think about challenge game contracts, reliable virtual machines, and the choice between allowlists for proposers and validators versus totally open systems. Plus, there's the upgrade guardians and that awesome withdrawal flow after proofs. It’s kind of like OP Superchain fault proofs, not to mention Arbitrum BoLD dates and parameters. There’s a lot to look forward to! Take a look at this over on the Oplabs Blog! It’s definitely worth your time!
• ZK: So, this section covers things like contracts for verifying validity proofs, circuit constraints, how recursion is set up, and different data availability modes. You’ve probably heard of them--like rollup, validium, and “prividium.” Hey there! If you’re exploring the ZK Stack or Validium, make sure you check out the L1 DA validators (that's the L2DAValidator and L1DAValidator) and take a peek at how the inclusion-proof wiring comes into play. It's definitely worth your time! If you're looking for more info, definitely check out the ZK Sync Docs. They’ve got all the details you need!
• Exit guarantees: So, here's a big one--can users really exit on their own without having to coordinate with the operators? What’s a reasonable time frame for that exit, according to your governance? Just make sure it lines up with the L2BEAT “Stages” requirements you say you’re meeting (whether that’s Stage 0, 1, or 2). If you're curious about the details, you can check it out right here.
• Sequencer fallback: This is all about having some backup options when things get tricky. It includes things like forced inclusion or exit strategies, making sure we can resist censorship, and dealing with timelocks.

Exclude:

• So, there’s some buzz going around about “Stage 2” dropping soon. "Just pay attention to what's available on the mainnet right now."

Deliverables:

Here’s a step-by-step guide on how to carry out a forced exit when you're up against some really tough operators. I’ll lay out everything with clear timelines and specific signer sets so you know exactly what to do. Let's dive in!

• So, let’s talk about attack trees that show how denial-of-service attacks and griefing can happen. Basically, these trees can map out how some interactive games can get reset repeatedly, causing a lot of frustration for players. It's a real bummer when that happens!

3) Bridges and cross‑chain messaging

Oh, it looks like your message got cut off! Can you share a bit more? Sure! Please share the text you'd like me to rewrite, and I'll be happy to help!

• Bridge Trust Model: This is really just about finding the safest way to link everything up. We're diving into the comparison between light clients and using an external relayer or oracle. We should definitely keep in mind the size of the validator set and how frequently it changes, not to mention the kinds of proofs we’re using. It's all pretty important to consider! Hey, just a quick reminder: don't overlook who has the power to hit pause or make those upgrades!
• Key Ceremonies: Okay, so these are really crucial! We're going to take a closer look at how we set up Multi-Party Computation (MPC) and Hardware Security Module (HSM) solutions for our guardians and relayers.
• Replay Protection: We’re all about keeping our messages safe and unique. It's really important to keep things separate in their own domains and to pay attention to the order of messages. That way, everything stays organized and flows nicely.

Why It Matters:

When we talk about bridge losses, the big issue still seems to be private-key compromises, or when you have a bunch of signers all in one place. That’s definitely the main culprit. Let’s talk about the Orbit Bridge exploit that happened on December 31, 2023. This incident really shook things up, with losses hitting around $81-82 million. Turns out, it was all tied to some compromised signers. Pretty wild, right? Jump ahead to mid-2024, and that attacker resurfaced, moving around $48 million through Tornado after keeping a pretty low profile for a bit. This is really just a straightforward case of key or operations risk--it's not some complicated math problem at all.

When you’re going through your audit, don’t forget to take a look at the signer processes and check on those rotation tests too! It’s super important to cover all your bases.

For more info, take a look at this article from Cointelegraph. It dives deeper into the whole situation!

If you’re diving into generalized messaging like LayerZero, don’t forget to get your oracle and relayer settings sorted out. It’s a pretty crucial step! Hey, just a quick reminder to make sure you're using nonblocking flows. Also, don’t overlook the importance of keeping your endpoints and libraries upgradable! It’ll save you a ton of headaches down the line. It's super important to really test out blocked message queues and replay handling thoroughly. You want to make sure everything works smoothly! For more info, swing by the LayerZero documentation. You'll find all the details you need there!

Exclude:

• We're putting together "interoperability roadmaps" for chains that you won’t be connecting with right at launch.

Deliverables:

Hey there! So, we need to put together a cross-chain sequence diagram that highlights potential failure modes. Don't forget to include runbooks, especially focusing on what to do if there’s a signer compromise. That’ll really help us navigate any bumps along the way!

4) Onchain application code (Solidity/Vyper/Huff/Rust)

Looks like there's been a little misunderstanding here! I didn’t receive any specific text or details to work on. Sure thing! Just let me know what you need help with, and I'll do my best to assist you!

We're going to explore standards conformance and those tricky edge cases. You know, like ERC-20, 4626, 721, and 1155. This covers everything from permit variants and fee rounding to token hooks, and we can’t overlook rebasing!

• And then we’ve got upgradeability to think about, along with those tricky proxy invariants--like initializers and the UUPS/transparent proxy controls that we all need to stay on top of. We're diving deep into the analysis, running a thorough static dive and checking out differential fuzzing against invariants. We're using a mix of tools like Foundry invariants and Slither detectors, along with some property-based tests, to make sure we're covering all our bases. Check it out here!. Hey, let’s not forget to chat about EIP-1153 and its transient storage usage patterns. We've got to consider those MCOPY limits too, along with the SELFDESTRUCT assumptions that popped up after 6780.
• So, we're diving into gas-sensitive implementations like Huff and Yul. We’ll make sure to cover the formal preconditions and postconditions, and also check that our test harnesses are all lined up properly. If you want to dive deeper, check out more info here! It’s all laid out in a way that’s easy to understand.

Tools that Should Be Baseline in 2025

• Slither is your go-to tool for running static checks. It helps you spot issues like unprotected upgrades, misuse of ecrecover, and those tricky abi.encodePacked collisions, among other things. Take a look at this: (github.com). You might really find it interesting!
• Foundry is great for fuzz testing and checking invariants. Hey, you should definitely check out targetSelector and targetContract scoping along with stateful sequences. They can really help out when it comes to managing reentrancy and rescue paths. Trust me, it's worth diving into! If you’re looking for more details, just check out this link: paco0x.org. Happy exploring!

Exclude:

• We're talking about frontend websites and non-custodial browser wallets here. Just a heads up, these will have their own separate categories when it comes to web and app security.

Deliverables:

• A fixed catalog that connects to your protocol's math (you know, like “the total of all shares adds up to the total supply, give or take 1 wei”).
• Tools for reproducing any incident type from third parties that are similar to your design.

5) Zero‑knowledge circuits and proof systems (if applicable)

Hey, it looks like your request might be missing some details. Sure! Just let me know what specifics you’re looking for, and I’d be happy to help you out. What do you have in mind?

Let’s make sure we’re staying on top of under-constrained circuit detection and determinism proofs, especially for tools like Circom, Halo2, and Plonky2. It’s really important for our work! I think it would be awesome to include tools like Circomspect and Picus in our CI and audit processes. They could really help streamline things! Hey, if you want to dive deeper into this topic, be sure to check out this blog post. It’s got all the juicy details! Let's make sure we're keeping an eye on constraint counts and how they stack up against the expected limits. We should also do some sanity checks on our witnesses, check the hashing, handle any field conversions, and don't forget about padding and making sure we’re separating domains properly. Hey, just a quick reminder to check out the verifier parameters on L1 as well!

• What do you think about making sure we have multi-language circuit coverage (like R1CS, PLONK, and ACIR) in our setup? It’s especially important since we’re working with a mix of languages and backends. If you want to dive deeper into this, check out this GitHub page.

Exclude: "Focus on tuning the prover's performance, but only if it’s relevant to security. Benchmarks can be nice to have, but they aren’t absolutely necessary for security."

Deliverables:

• There’s solid proof that every public output is uniquely tied to its inputs, which means no backup witnesses are allowed.
• We've put together some comprehensive documentation on how verifier gas and limit checks work, along with our soundness assumptions. This should really help out both auditors and governance folks.

6) Oracles and external data

Hey, it looks like there might be something missing from your request. No worries, though! Just let me know what you need, and I’ll be happy to help! Sure! Please share the text you want me to rewrite, and I'll give it a more casual, natural feel.

Hey, if you're diving into Chainlink Data Feeds (OCR), don’t forget to look into the feed parameters, the minimum submissions, and how the fallback behavior works. It’s all pretty important stuff! Hey, just a quick reminder to watch out for stale reads and keep track of how versioning works with your aggregator! If you want to dive deeper into this, you can check out more info here.

• If you’re getting into Pyth’s pull-oracle model, make sure to check who’s triggering that “update price” function. It’s crucial to avoid running into stale prices or any griefing issues. Just a quick reminder: consumers really need to request those updates using the Wormhole-signed VAAs. Keep that in mind! Absolutely, don’t forget to give those “no-update” scenarios a try! You can dive into the details here. Happy exploring! Hey there! Just a quick reminder: whenever you’re working with cross-chain oracle deliveries, make sure you check those signature sets, watch out for replay protection, and keep those guardian assumptions in mind! It's super important!

Exclude:

• Alright, let’s talk about what people think about the market share of data vendors. Overall, it seems like there’s a mix of views out there. Some folks believe that certain vendors are really dominating the scene, while others think the competition is pretty fierce and that new players are stepping up. It’s definitely a topic that gets a lot of chatter in industry circles, and opinions can vary quite a bit depending on who you ask.

Deliverables:

Make sure to set some alert thresholds and circuit breakers. This way, you can quickly spot any outdated or inconsistent feeds before they cause problems. We'll also run through some scenarios to see how we’d handle situations where things freeze up or detach from their usual value.

7) Admin keys, governance, and operations

Oh no, it looks like something went wrong with your request! Sorry about that! Sure! Just send me the text you want rewritten, and I'll take care of it for you.

• Key management: When it comes to managing keys, it's really worth considering setups like threshold (t‑of‑n) arrangements and making sure you have a variety of signers involved. Hey, don’t forget to check out hard timelocks and see what roles different people can play in that setup! It’s pretty interesting stuff. Make sure you take some time to plan out your recovery or freezing procedures. It’s really important! Hey, have you thought about using MPC, like MPC-CMP, or maybe some HSM-backed controls with rotation SLAs? Just something to keep in mind! (fireblocks.com).
• Governance: It's super important to find the right balance between delaying upgrades and keeping those user exit windows in check. When we're talking about the Security Council, it's important to remember that their powers should align with the L2BEAT Stage criteria. Just take a moment to consider what sets Stage 1 apart from Stage 2. (medium.com).
• Keep an eye on things and be ready to react: It's super helpful to have some ready-made monitors and response plans handy for when incidents pop up. So, when it comes to tools like OpenZeppelin Defender, it's pretty neat! It’s designed to help developers manage their smart contracts and keep everything secure. With features that let you monitor, automate, and deploy your contracts easily, it really takes a load off your shoulders. Plus, it’s user-friendly, which is always a bonus when you're knee-deep in code. Just a great option for anyone looking to streamline their process! 0 Monitor/Actions and Forta's real-time detectors can be super helpful. (blog.openzeppelin.com).

Let’s chat about what happened with Gala in 2024, for instance. It was a pretty typical situation where the admin and minter ended up clashing. If an audit overlooks keys and runbooks, it's pretty much asking for a rerun of the same issues down the line. If you want to dive deeper into the details, feel free to check it out here. It’s worth a read!

Exclude:
So, when we talk about HR background checks, enterprise IAM, and SOC2 scope, it’s important to remember that while they’re all connected, they actually fall under different audit categories.

Deliverables:

• A RACI chart for handling emergencies.
• We’ve got automated pause and mitigation actions that are connected to our monitors.
• We're planning a tabletop exercise to tackle the issue of signer loss.

8) Account abstraction (ERC‑4337, EIP‑7702) if you support smart accounts

It seems like you forgot to share the text you'd like me to rewrite. No worries--just send it over, and I'll help you out! Sure! Just drop the content you want me to tweak right here, and I’d love to lend a hand. Let’s make it sound awesome together!

Hey there! If you're getting into the nitty-gritty of Paymaster griefing, DoS resistance, staking limits, and all that deterministic validation stuff under the ERC‑7562 rules, make sure you check out the details on bundler simulation parity. You won’t want to overlook it! Feel free to take a look at all the details here. It’s all laid out for you! If you’re diving into EIP-7702 delegation semantics and planning on using EOAs to delegate to smart-account logic, just a heads up: it’s super important to double-check your authorization lists, clearing flows, and signature paths for wallets. Better safe than sorry! Find more insights here.

Exclude: Let's chat about the bundle marketplace and what makes its economy tick.

Deliverables:

Make sure to run thorough end-to-end tests to guarantee that any shady paymaster activities get blocked without a hitch. Also, don’t forget to add some replay and packing protection features in any custom VerifyingPaymaster you create. (alchemy.com).

---

What’s explicitly out of scope (but often confused)

You know, the whole rollercoaster ride of token prices, how emissions actually function, and what a lot of people refer to as "Ponzinomics" can be pretty wild. "Security can definitely influence incentives, but it doesn’t really have the ability to predict how the market will act." When it comes to integrating with centralized exchanges, it's important to understand how custodial flows operate and the potential risks involved. Plus, the security of third-party KYC vendors can be a bit shaky at times. It's definitely something to keep in mind! Hey there! Just a quick tip: it's important to think of your marketing sites and landing pages as two separate entities. Don't forget to run a dedicated web or app security penetration test for each one. It’ll really help keep things secure! Hey, remember to keep in mind those end-user devices and wallets that your protocol doesn’t directly manage. They can be pretty important!

If any of those factors are going to affect how money flows--like when your backend is processing withdrawals--definitely make sure to include them in what you're looking at. It could be a good idea to set up some contractual guidelines and maybe even some incident runbooks to help you tackle those kinds of situations.

---

Practical scoping checklist (start here)

Time Box: Plan for about 60 to 90 minutes with your engineering lead, project manager, and operations team.

1. So, which mainnet state are we checking out? We're taking a look at the commit hashes and tags, checking out the compiler versions, deployment addresses, configuration values, and feature flags.
2. If you're rolling with a rollup or an appchain: Hey there! So, what’s the latest on the proof system that’s up and running? I'm really curious about how the withdrawal process works--how long does it usually take? And by the way, who’s in charge of hitting the pause button or making upgrades to the contracts? Don't forget to take a peek at the important dates and links to the latest docs or announcements. Thanks! If you want to dive deeper, check out this link: blog.oplabs.co. There's a lot more information waiting for you there!

3) Cross‑chain?

Alright, so let’s break it down. First, you’ll want to jot down all the message paths and the signers that are part of the deal. It’s super important to clearly identify where those replay boundaries are--basically, look for the chainId or domain separators. This helps in pinpointing where the messages can get a little mixed up, you know? Just take your time and make sure you cover everything!

4) Oracles?

• Feeds: Think of these as the data sources that give smart contracts the outside info they need.
• Update Mechanics:
• Push vs Pull: So, when it comes to oracles, there are two main ways they handle data. Some of them automatically push data to the blockchain, which is super convenient! On the flip side, there are oracles that wait for the blockchain to pull the data when it’s needed. Different strokes for different folks, I guess!
• Heartbeat/Deviation Thresholds: Oracles are always on the lookout to ensure the data they provide is up-to-date. They do this by following certain time intervals, known as heartbeats, and keeping an eye on acceptable variances, which are basically the deviation thresholds.
• Handling Stale Reads: You know how sometimes you might get an old version of something that’s not quite right anymore? Well, oracles have got that covered! They have built-in ways to keep things fresh and prevent outdated data from slipping through. This means smart contracts always get the most up-to-date info, keeping everything running smoothly.

If you want to dive deeper into the specifics, be sure to take a look at the official documentation here: Chainlink Docs. It's a solid resource!

5) Admin and Governance

So, we’ve got some important stuff to talk about - things like thresholds, timelocks, and emergency powers. And hey, we’ve got that rotation schedule to mix things up a bit! Hey, just a quick reminder about the MPC/HSM providers and our approach to recovery drills. It's super important to keep them in mind! If you're curious to learn more about this, take a look at fireblocks.com! You’ll find some really interesting info there.

1. Monitoring & Response: Hey there! So, what monitors do we have running right now? Are we using Defender, Forta, or maybe some custom setups? Also, it’d be great to know what kind of auto-actions we've got in place, like pauses, rate-limits, or circuit-breakers. You can check all the details over at this link: blog.openzeppelin.com.

7) ZK Circuits?

We're diving into some languages and backends! We're looking into determinism proofs in continuous integration using Circomspect and Picus. Hey, just a quick reminder to keep an eye on those verifier parameters and gas limits! If you want to dive deeper into this topic, I highly recommend checking out this Trail of Bits blog post. It’s got some great insights!

8) Invariants (auditor‑ready):

Sure! Here’s a rundown of 10 to 20 key invariants--think things like supply conservation, fee accounting, and various bounds--along with the tests and fuzz harnesses that go with them.

1. Supply Conservation

• Test: Make sure the total supply stays the same even after transactions go through.

1. Fee Accounting

• Test: Make sure the fees we collected match up with the transactions we processed.

1. Bounds

• Test: Make sure that the limits on transaction sizes are being followed.

1. User Balance Integrity

• Test: Make sure user balances are spot on all the time.

1. Transaction Validity

• Test: Make sure that only real transactions go through.

1. State Consistency

• Test: Make sure the current state shows all the transactions that have been finished.

1. Access Control

• Test: Check to make sure that permissions are being enforced correctly.

1. Event Emission

• Test: Make sure the events are firing off just right while the contract's running.

1. Gas Limit Compliance

• Test: Make sure that transactions stay within the gas limits.

1. Contract Upgradeability

• Test: Make sure that previous versions still work just fine after the upgrades.

1. Token Transfer Validity

• Test: Make sure that token transfers go through without a hitch.

1. Liquidity Constraints

• Test: Make sure the liquidity pools have enough reserves on hand.

1. Oracle Accuracy

• Test: Make sure that the data from oracles is still reliable.

1. Withdrawal Limits

• Test: Make sure that the withdrawal limits for users are actually being enforced.

1. Transaction Ordering

• Test: Make sure the transaction ordering rules are being followed correctly.

1. Fallback Functionality

• Test it out: Make sure the fallback functions are doing their job right.

1. Nonce Management

• Test: Make sure nonces are being used correctly to stop replay attacks in their tracks.

1. Reentrancy Protection

• Test: Look out for any reentrancy issues.

1. Ownership Transfers

• Test: Make sure we can transfer ownership safely and securely.

1. Emergency Stop Functionality

• Test: Make sure the emergency stop features work correctly and can be activated when needed.

---

Emerging best practices we recommend in 2025

• Consider DA a top-tier risk: When you’re diving into EigenDA or Celestia, don’t forget to jot down important stuff like retrieval guarantees, and limits to fend off Sybil attacks and DoS attacks (kind of like the throttles you’d see in a free tier). Also, make sure you understand how on-chain inclusion verification is set up. It’s all about keeping things secure and transparent! Make sure to set up some monitors to keep an eye out for any DA failures that might interfere with your L2's safety exit. It’s super important to catch those issues before they become a problem! If you want to dive deeper into the topic, you can find all the details right here. Give it a look!
• Get on board with permissionless proofs as soon as you can: If you’re diving into OP Stack, it’s a good idea to start mapping out how you’ll implement permissionless proofs. And if you’re using Arbitrum, make sure to take a moment to ensure that your BoLD setup aligns with your chain’s upgrade timeline. It’s all about staying ahead of the game! Oh, and don’t forget to have your runbooks all set for those permissionless challengers. If you’re looking for more details, you can check it out here.
• Keep an eye on things with automatic responses: Make sure to set up Defender Monitors to keep track of any changes in admin roles, as well as big mints or burns, and governance actions. Link your actions to those timed pauses and rate-limiters. Consider adding the Forta Attack Detector or Firewall to your setup. It’s a great way to keep an eye on potential risks before they actually hit the chain. Got any questions? Don’t worry! You can dive into the docs right here. They’ve got you covered!
• Ensure ZK Circuit Consistency: Don’t forget to include checks for under-constraints as a part of your CI workflow. This is crucial for maintaining determinism! If something doesn't work out, you'll need some counterexample artifacts before you can hit that shipping button. Find out more here.
• Make admin keys less exciting: Consider setting up a t-of-n configuration with a mix of signers, maybe from various jurisdictions or clouds. And for those crucial roles, why not use Multiparty Computation (MPC)? It'll definitely keep things secure without the drama! Keep runbooks super strict. Hey, just a quick tip: it’s smart to share your timelocks and exit windows based on the L2BEAT Stages. This way, users have a better understanding of the risks they’re facing. It helps keep everything transparent! If you want to dive deeper into this topic, check out the details here.

---

Example: drawing a tight scope for a Superchain DeFi protocol

Context

So, it looks like you're gearing up to launch on OP Mainnet, where fault proofs are already in action. That's exciting! Plus, I see you're planning to create an L3 that zeroes in on private order flow using a ZK Stack Validium. Sounds like a cool project!

What Does That Mean for You?

When you deploy on OP Mainnet, you're tapping into a really strong infrastructure and some solid safeguards that help keep everything running smoothly. This really gives you a nice layer of security when you’re making transactions. On the other hand, if you're looking to manage private order flows, setting up an L3 with a ZK Stack Validium is definitely a clever choice! It helps you stay safe and keep your stuff private, all while still getting to enjoy everything the mainnet has to offer.

Key Points to Consider

• OP Mainnet: Fault proofs are now fully up and running! This means you can have confidence that all your transactions are being validated accurately.
• L3 Setup: With a ZK Stack Validium, you're setting up private order flows--super important for keeping your operations under wraps. It really helps maintain that confidentiality you need!
• Security and Efficiency: By blending these technologies, you can boost both your privacy and the speed of your transactions. It’s a win-win!

What to Explore Next

You should definitely take some time to explore how the ZK Stack interacts with Validium, especially when you consider the setup of the OP Mainnet. It’s pretty fascinating stuff! Think about how privacy affects how people use your app and how this could set you apart from the competition. It’s a big deal these days, and if you can highlight your commitment to keeping user data safe, it might help you stand out in the market!

Resources

• OP Mainnet Documentation
• ZK Stack Overview
• Validium Explained

Final Thoughts

By launching on OP Mainnet and using an L3 for private order flow, you're really putting yourself ahead of the curve in the world of blockchain tech. It’s an exciting space to be in! Just keep your eye on privacy and security, and you’ll be heading in the right direction!

In Scope:

• OP Mainnet Withdrawal Path: Let’s take a closer look at how withdrawal paths operate, plus we’ll explore the latest interactions with the output oracle that are powered by fault-proof mechanisms. We'll also dive into the break-glass and guardian powers, plus the details on their timelocks. If you're curious and want to dive deeper, feel free to check out more details here.
• L3 Validium DA Commitments: So, this part is all about making sure everything checks out on Layer 1 (L1) with the help of ZKsync’s L2DAValidator and L1DAValidator contracts. We're diving into stage classification for L3 too. But no need to stress--this isn't just some marketing gimmick. If you're looking for more details, check this out here. It's got all the info you need!

Hey there! So, we're diving into some pretty cool stuff regarding the bridge between L3 and OP Mainnet. We're looking into a few key areas, such as how to deal with message replay domains, what happens when the sequencer has downtime, and ways to tackle operator censorship. Exciting times ahead!

• Oracles: Alright, so when it comes to Pyth, we really need to nail down who's responsible for keeping the prices up to date. Is it the bot that's doing all the heavy lifting, or is it on the taker? Also, let's chat about what we should do if some updates get overlooked and bring in those stale-read circuit breakers to keep things running smoothly. Check out this resource for some really interesting insights!
• Admin: So, let's dive into how we're going to use MPC for minting, burning, and making upgrades. Defender monitors are set to track any role changes, and we've got some handy runbooks prepared to pause just the modules that are impacted. If you want to dive deeper into the topic, check it out here. You’ll find some really interesting insights!
• ZK Circuits: We're making sure to document everything related to under-constraint checks and gas limits. We're particularly focused on how to parameterize the verifier effectively. If you want to dig deeper into this topic, you can check out more info here.

Out of Scope (for this audit):

• The marketing website and the analytics system.
• We'll dive into the SRE setup for the centralized matching engine in another appsec/infra review later on.
• When it comes to migrating to BoLD on an Arbitrum instance, we’re holding off for now. We’ll wait until everything--like dates and configurations--is all locked in before making any moves on that front. Take a look at the details right here: (docs.arbitrum.io). You'll find all the info you need!

---

How we run protocol‑grade audits at 7Block Labs

• Pre-audit hardening (1-2 weeks): To start things off, we’ll provide you with a “red list” that we’ve put together from some static analysis using Slither. We’ll also throw in some fuzzing and invariants scaffolding from Foundry. If it’s relevant to your project, we’ll set up CI gates for ZK determinism too! Getting these issues sorted out now can really help you save some time on your audit hours. Take a look at this: GitHub Link. You won’t want to miss it!
• Scope Lock (D-7): Alright, folks, it’s locking time! Let’s get those commit hashes pinned down, nail down the deployment addresses, clarify those EIP assumptions, decide on the L2 proof mode, set the DA layer settings, and sort out the admin key setup. We want everything nice and secure! We're going to whip up a RACI chart to help us handle any incidents that pop up. It'll make it easier to keep track of who’s responsible for what.
• Audit execution (2-4 weeks): In this stage, we’re going to tackle a few things at once. We’ll dive into the on-chain code, check out proofs, bridges, and oracles, and also review the operations and governance aspects. It's going to be a busy but exciting time! You can count on us to provide not only the proof of concepts (PoCs) but also any essential minimal patches--no dry list of findings here! We're all about making sure you get what you really need.
• Getting Ready: Alright, let’s go ahead and set up those Defender/Forta monitors and actions. Also, we’ll set up some tabletop drills to get ready for any hiccups we might face with bridges, oracles, or decentralized apps, especially during those times when there’s a surge in blob scarcity. It’s all about being ready for whatever comes our way! If you're looking for more info, check this out: (docs.openzeppelin.com). You'll find all the details you need right there!
• Post-audit: Once we wrap everything up, we’ll put out a friendly note that breaks down the “assumptions and limits.” This way, everyone can easily see what’s secure and what might depend on outside trust. It’s all about making sure users are in the loop!

---

Final word: write your scope like an adversary would

Having a clear scope helps to establish clear boundaries around:

• You've got the proof and DA guarantees right at your fingertips.
• The admin powers that can change the way user funds are managed in the future.
• The external data and cross-chain dependencies that your protocol just can’t outsmart on its own.

Just do that, and trust me, your audit won’t just sail through; it’ll be totally equipped to tackle any real-world challenges that pop up next!

---

References and Further Reading:

Hey everyone! Have you seen the announcement for the Ethereum Dencun mainnet? It’s set to go live on March 13, 2024! Pretty exciting stuff, right? They've got a bunch of Ethereum Improvement Proposals (EIPs) lined up, including 1153, 4788, 4844, 5656, 6780, 7044, 7045, 7514, and 7516. Make sure to check it out! (blog.ethereum.org).

Hey there! If you're interested in what happened after 4844 and want to dive into how blobs work, I found a really great resource for you. Check it out! (eip4844.com).

Hey there! If you're looking to get the scoop on OP Stack fault proofs (Stage 1) and the updates to withdrawal flows, you’re in the right place. This blog has all the details you need! (blog.oplabs.co).

Hey, mark your calendars! The Arbitrum BoLD launch is happening on February 12, 2025, and you definitely don’t want to miss it. Plus, there's going to be some cool insights on adoption that you’ll want to check out. (docs.arbitrum.io).

If you're curious about ZK Stack Validium's DA inclusion contracts and how the whole architecture works, I've got a great guide for you! (docs.zksync.io).

If you’re diving into Celestia, you’ve got to check out this essential read on its data availability (DA) sampling. It really breaks down the assumptions behind data availability in a way that’s super understandable. You won’t want to miss it! (docs.celestia.org).

• Check out the details on the EigenDA security model and the slashing notes right here! (docs.eigencloud.xyz).
• The whole Orbit Bridge exploit definitely got people talking. If you want to dive deeper into the risks that come with bridge signers and their operations, you’ll want to check this out. There's some valuable info waiting for you! (cointelegraph.com).
• Take a look at the Pyth pull-oracle model and how it handles cross-chain delivery right here. (pyth.network).
• Curious about how Chainlink Data Feeds architecture operates? Let me give you a quick rundown of the whole process! (docs.chain.link).
• Just a heads-up to keep an eye on Defender 2! You'll get 0 for monitoring and response, along with the Forta Attack Detector/Firewall. This combo really helps with real-time detection and prevention strategies to keep everything secure. (blog.openzeppelin.com).

Slither and Foundry are pretty fantastic tools when it comes to setting up audit baselines using their invariants. They really help make the process smoother! Check them out! (github.com).

• Finally, don’t forget to check out Circomspect and Picus for some cool insights on under-constraint ZK checks in this really informative blog! (blog.trailofbits.com).

Oh, and make sure you keep in mind the ERC-4337 security stuff! It includes things like paymasters, ERC-7562, and it’s all about staying in line with EIP-7702. This is an awesome resource for really getting a handle on these ideas! (docs.erc4337.io).

Hey there! At 7Block Labs, we're here to support you. If you're looking for our one-page scope template--complete with an invariant catalog starter--just give us a shout. We’d love to share it with you!