Blockchain Security Audit Checklist for Engineering Leaders

The Ultimate Audit Checklist for Onchain Systems in 2025

Hey there, if you’re a decision-maker gearing up to roll out onchain systems in 2025, you really need to get your ducks in a row! I’ve put together a handy audit checklist that’s been tried and true in real-world situations.
It's got you covered on all fronts, tackling everything from pre-audit planning to handling incidents. Let’s dive in!.

Pre-Audit Scoping

Before you jump into the audit, it’s super important to clearly define your scope. Here are a few things to think about:

So, what are the main goals of the audit?

So, what parts of the system are we going to include? So, when can we expect the audit process to wrap up? What's the timeline looking like?

L2/Bridge Assumptions

When you're diving into Layer 2 solutions and bridges, there are a few key things to keep in your back pocket:

Get a grasp on how the technical architecture of the L2 solution works.
Take a look at your trust model: Are you counting on a central authority, or are you going with a more decentralized approach?
Look for any potential problem areas and spots where too much trust is placed in just one thing.

Contract Pitfalls

Smart contracts can be a bit of a challenge, you know? Keep an eye out for these common traps:

Reentrancy: It’s super important to keep your contract safe from this kind of attack. You definitely don’t want to overlook this!
Integer Overflow/Underflow: To avoid running into trouble with these pesky issues, make sure you’re using safe math libraries. Trust me, it’s worth it!
Access Control: Just make sure that only the folks who are supposed to be doing certain important things have access. It's all about keeping it secure!

Test/Formal Methods

Testing is key. Consider these methods:.

Unit Testing: This is all about checking out those individual functions to catch any bugs before they become a bigger deal. It’s a great way to nip problems in the bud!
Integration Testing: This is all about making sure that different parts of the system play nicely with each other.
Formal Verification: This is all about using mathematical proofs to make sure your contracts are doing what they’re supposed to. It’s like double-checking your work to ensure everything runs smoothly!

Operational Controls

Operational controls play a crucial role in keeping the system running smoothly and securely. Make sure to:.

It’s really important to define what everyone’s role is on the team. Make sure each person knows their responsibilities!
Make sure you use access controls to limit what people can do.
Make sure to hold regular training sessions for the team on security practices.

Runtime Monitoring

Keeping an eye on your system while it’s running is super important. Here are some helpful tips for you!

Use logging to monitor transactions and any changes in state. It’s a great way to stay on top of everything happening! Make sure to set up alerts for any weird activity or anything that seems off. Make it a habit to check your logs and reports regularly so you can spot any problems before they get out of hand.

Incident Response

And hey, don’t forget the importance of having an incident response plan ready to roll. It's super crucial! Just a quick reminder to remember these steps:

Preparation: Make sure you have a well-prepped team that's ready to jump into action when incidents pop up.
Detection: Grab some automated tools to help you spot any potential incidents in no time.
Recovery: Come up with plans to get systems and data back on track after something goes wrong.

Examples and Latest Standards

Make sure to keep yourself in the loop with the latest standards, and don’t forget to check out six handy examples that really match up with these practices! Knowledge is definitely power! It’s going to be your best friend as you tackle the constantly shifting world of onchain systems.

By using this checklist, you're really gearing yourself up for success in the ever-changing world of on-chain technology. Good luck out there!.

Engineering leaders, whether they're at a startup or a big company, can totally use this to shift their mindset from “we think it’s secure” to “we can actually prove it, measure it, and respond in just minutes.” It’s a game changer! ”.

Why this checklist now

As we look ahead to 2024-2025, it's pretty clear that we're noticing some noteworthy changes in how risks are playing out. There are definitely more incidents occurring, but the good news is that the median loss seems to be lower than what we saw back in 2021-2022.
That being said, we're still dealing with some pretty significant single points of failure. I mean, things like admin keys, upgradeable proxies, oracle designs, and cross-chain bridges are still causing us some big headaches and can lead to major risks down the line. (halborn.com).

I’ve got a couple of solid examples you might want to keep in mind for your playbooks.
Munchables (Blast, Mar 26, 2024): So, here's the scoop--some rogue developer really went off the rails by exploiting an upgradeable proxy. They decided to give themselves a crazy balance of 1 million! In the end, they managed to drain a whopping 17,411 ETH, which is roughly around $62,000. Wild, right? 5M). Luckily, they ended up giving the money back after everything was said and done. So, the main problems we ran into were insider risk, a pretty lax approach to upgradeability, and missing invariant tests. (theblock.co).
Gala Games (May 20, 2024): So, here’s a wild one - a staggering 5 billion GALA tokens got minted after someone managed to mess with the minter role. Quite the headache for them! The team really stepped up and got the situation under control in about 45 minutes, which was amazing! But in the end, it turned out to be more of an access control problem than a flaw in the contract logic itself. (news.gala.com).

At 7Block Labs, we’ve got this super handy checklist that we always turn to for audits, threat modeling, and incident exercises. It really helps keep everything organized!

0) Pre‑audit prep (what leaders must freeze, list, and decide)

Before You Dive into Code:

Lock in the commit and the dependencies. Make sure to tag and hash those specific commits so we can do a detailed review later on. Make sure you set up a consistent build by pinning your solc version with tools like Foundry or Hardhat. Don’t forget to use lockfiles for your JavaScript tools, too!
Could you jot down a list of all the third-party code you’re using? This includes any libraries, wallets or connectors, SDKs, and don’t forget to include their versions and addresses too! Hey, do you recall the whole Ledger Connect Kit situation? It turned out to be a problem with their supply chain. Most of the teams were covered at the contract level, but they still ended up getting caught up in a compromised NPM package. Crazy, right? Think of the frontend and connectors as part of your trust boundary. (ledger.com).
Let's take a look at what we're dealing with here: the scope and the threat model. So, go ahead and make a note of your trust claims and those you’re a little skeptical about. Think along the lines of “permissionless withdrawals on L2” or “no single person can just take off with the treasury,” and don’t forget about “the oracle is resistant to flash loans beyond X% in Y blocks.” Just jot down what feels right and what raises an eyebrow for you! These will act as guidelines and constants that we'll refer back to when we do our verification later on.
Auditor's checklist for artifacts. Here's a system diagram that outlines the roles, admin pathways, and emergency procedures. It's a handy visual that helps to clarify how everything ties together! Here’s a quick rundown of the deployment plan. It covers the proxy pattern, the timelock setup, and the multiparty signature (multisig) parameters. Here's a parameter sheet that lays out all the details about caps, fees, and how pauser behaviors work. Hey, don’t forget to check out Section 1 for the L2/bridge assumptions!
Check out the monitoring and alerting runbook in Section 4!

1) Architecture & chain assumptions (L1, L2, and cross‑chain)

Rollup security posture
So, on June 10, 2024, Optimism/OP Stack launched these governance-approved, permissionless fault proofs on OP Mainnet. This is what L2BEAT refers to as Stage 1. Exciting times ahead! This is a pretty significant move! It means you won't have to depend on third parties for your withdrawals anymore, which is great. Of course, there's still a Security Council that can jump in to help out if anything goes awry. So, if you’re thinking about diving into OP chains like OP Mainnet or Base, make sure you’re cool with the trust model that comes with it. It's an important aspect to consider before you get started! (docs.optimism.io). So, back in February 2025, Arbitrum BoLD introduced permissionless validation for both Arbitrum One and Nova. This big move really helps speed things up by reducing the time for disputes, but it also opens the door for some economically viable delay-attacks. Pretty interesting stuff, right? This is super important for both withdrawal and governance strategies. (theblock.co). Hey there! When you're looking at your L2 options, check out the L2BEAT Stages framework. It'll help you figure out if you're at Stage 0, 1, or 2. Don’t forget to point out any “training wheels” you’ve got in place, like those challenge periods, councils, and escape hatches. It’s super helpful to see where you stand! Make sure to add this info to your audit report! (medium.com).
Designing Bridges and Their Limitations. Hey, just a quick tip when you're working with Chainlink CCIP: don’t forget to set up those token-bucket rate limiters for your token pools and also for the aggregate lanes. It’ll really help keep everything running smoothly! You might want to consider keeping your inbound limits around 5-10% higher than your outbound limits. It can really help things run smoother! This really helps to take care of any batching issues or finality hiccups you might encounter. Oh, and make sure to hand off those rate-limit admin duties to another role! It's definitely a good idea to add these to your incident response plans. (docs.chain.link).
Oracle assumptions Hey there! When you're diving into Uniswap v3 TWAPs, don't forget to take note of a few key things. First off, keep track of the document window length you’re working with. It’s also super important to think about how you’re modeling manipulation costs. Plus, be sure to consider any strategies you might want to use to tackle those costs, like implementing wide-range liquidity or using median/winsorized methods within the PoS landscape. It'll help you stay on top of your game! Just a heads up: two-block attacks can be pretty pricey on those top pairs. But if you're working with some big-time validators, you might find that multi-block attacks are actually within reach. (blog.uniswap.org).

2) Contract checklist (what to prove in code)

Upgradability (UUPS/Transparent) Hey there! So, what you want to do is replace your constructors with initialize() methods. And don’t forget to throw in _disableInitializers() to really keep things secure. That’ll help lock everything down nicely! Just a little reminder to keep those storage gaps in mind. You might want to think about using ERC‑7201 namespaced storage--it could really help out! And hey, make sure you check your storage layout diffs whenever you do an upgrade! It's an important step you won't want to skip. Many of the problems we encounter stem from people misusing proxies or running into storage conflicts. Check out more here.
Access Control Consider using role-based Access Control and create some straightforward roles that stick to the principle of least privilege. Think roles like UPGRADER, PAUSER, RATE_LIMIT_ADMIN, and GUARDIAN. Keeping it simple helps everyone understand who can do what! When it comes to transferring ownership, you’ll want to follow a simple two-step process for your externally owned accounts (EOAs). First, you’ll put the transfer in a “pending” state, and then once everything checks out, you’ll move it to “accept.” This way, it keeps things smooth and secure! Also, don’t forget to set a timelock on admin actions within the production governance paths. If you want more details on this, just check out the Governance section! If you’re looking for more info, you can check it out here.
Allowances and Token Transfers.

When it comes to managing your tokens, allowances are super helpful! They let you decide how much of your tokens you want to allow someone else to spend or transfer on your behalf. It’s like giving a friend permission to borrow your stuff, but in the digital world.

Plus, when you’re ready to send tokens to someone else, the transfer process is pretty straightforward. Just specify the amount and the recipient, and you're good to go! It’s a neat way to share or trade tokens securely without any hassle. To keep things safe, try to minimize your attack surface by using Permit2. It’s great for setting up time-limited approvals and handling signature-based transfers. A little extra security goes a long way! This will help you avoid getting stuck in those annoying “infinite approve” situations, and it makes revoking permissions super easy! Hey, don't forget to get your frontend team up to speed on batch revocation and expirations too! It's super important for them to be in the loop on this stuff. If you're looking for more info, check out this link. You'll find some great insights there!

Reentrancy and Settlement Alright, so here’s the deal: when you're coding, make sure you follow the checks-effects-interactions pattern. It’s super important. Also, don’t forget to implement the ReentrancyGuard--that one’s a lifesaver! And definitely opt for pull payments; they’re usually a safer bet. Lastly, take the time to write thorough tests that cover any external callbacks. Covering your bases is key!
Economic Safety Rails Let's go ahead and set up some TVL-aware caps and rate-limiters for minting, burning, and withdrawal processes. Plus, we should throw in some throttles for outflows on a per-block and per-epoch basis. Hey there! If you're considering using the ERC‑7265 circuit breaker pattern, don’t forget to clearly define your thresholds and cooldown behaviors--like whether you want to implement a delay or go for a revert option. Also, it's super important to decide who has the authority to arm or disarm the system. It really helps to nail these details down from the start! Think of this more like a backup plan than your main strategy, since it’s still just an idea for now. If you're looking for more details, you can check it out here. It's a great resource!
Oracle Integration Try combining TWAP with some extra checks, like using a median or percent-band, and set a rule like “no more than X% difference over N blocks.” This way, you’re adding a layer of safety to your strategy! “Don’t forget to check out those edge cases, like halted pools and liquidity cliffs. It’s super important to cover all your bases!”

3) Verification stack (tests, fuzz, invariants, proofs)

Unit + integration Make sure to use Foundry or Hardhat to really nail down solid branch and statement coverage for those important modules. Just a quick reminder--make sure to run those differential tests against the reference models or the earlier versions! It's super important!
Fuzz and invariants
Put into action the Foundry principles like “supply conservation,” which basically means keeping track of resources, “no loss from honest actions,” so you won’t lose anything if you’re playing fair, and “you can’t drain without first decreasing your balance,” among a few others. Take a look at Echidna if you’re interested in property-based fuzzing that’s tailored to your specific invariants. It could be just what you need! (github.com). Hey there! If you're diving into fuzzing or simulation, definitely give Scribble a try. It’s a handy tool that lets you throw in some runtime checks to keep your specs in line. Happy coding! If you're looking for more details, check this out: docs.scribble.codes. It's got a ton of useful info! Halmos is awesome for doing symbolic testing, especially since it leverages the tests you’ve already created in Foundry. It's super useful for keeping stateful invariants in those more complex protocols. (github.com).
Static analysis Hey there! Just a quick reminder to add Slither baselines into your CI setup. It's super important for checking things like ERC compliance, upgradeability, reentrancy, and uninitialized storage. Trust me, you won't want to skip this step! You can check it out right here: github.com.

Deliverables You Can Expect from Your Security Partner

When you're teaming up with your security partner, here are a few things to keep an eye on:

Explicit Property List: This is basically a comprehensive list of all the properties your system should meet. Think of it as your go-to guide for what to expect!
Failing Counter-Examples (if any): If things don’t go as planned, you'll receive straightforward examples that highlight where things went wrong.
Proof Artifacts or Test Seeds: These are great tools for helping you replicate the results and make sure everything adds up.

Getting these deliverables in place is really going to help you keep a strong security game!

4) Operational security (keys, governance, CI/CD)

Keys and multisigs Make sure you always go for a Safe multisig when it comes to key roles. For small teams, a good rule of thumb is to aim for a 2-of-3 threshold. If you're dealing with a bigger organization, bump it up to 3-of-5 or even 4-of-7. It’s all about keeping things secure while still being functional! Just a heads up: it's really important to keep custody separate. You don’t want to have two keys with the same person--it’s better to distribute them.
Just a quick reminder: Modules and Guards are really powerful tools, so treat them like your code’s best friends that definitely deserve a careful check-up. If your Guard isn’t set up just right, it might end up locking you out of your Safe! If you want to learn more about it, check out this link: help.safe.global. It’s definitely worth a look! Hey, you know what? It could be a good idea to throw in a Delay module for your spending rules. Just a little something to help with managing things better! For example, if there's a 3-minute delay, it can serve as a little pause button for any transactions that seem a bit off. Also, having dedicated Safes for different purposes--like one for treasury stuff and another for operations--can really help minimize any potential risks. It's a smart way to keep everything organized and secure! (help.gnosispay.com).
Governance and timelocks Hey there! If you're diving into OpenZeppelin Governor, just a quick reminder to nail down those voting delays, periods, and quorum requirements. It’ll really help keep things running smoothly! Hey, just a heads up--when you’re setting things up, make sure to run your executions through a TimelockController. It’s best to aim for a timeline between 48 and 168 hours. This way, you’ll have a little buffer to catch any issues that might pop up! Make sure to keep your emergency guardians on a separate, clear path and outline their roles in detail. (docs.openzeppelin.com).
CI/CD and Supply Chain: So, let's talk about CI/CD and how it fits into the supply chain. It's basically all about making sure that software development and delivery processes are smooth and efficient. This helps teams get their code into production faster while keeping everything organized and secure. It's like having a well-oiled machine that not only builds software but also ensures everything runs smoothly from start to finish. Pretty cool, right? Try to get into the routine of pinning your dependencies and make sure to include a CODEOWNERS file. Plus, it’s a good idea to set up protected branches for your contract folders. It'll really help keep everything organized and secure! Make sure to double-check your NPM packages and set up some integrity checks. It's a good habit to get into! Hey, remember that Ledger Connect Kit situation from 2023? Yeah, that was a serious supply-chain issue. So, just a heads-up: don't take it for granted that hardware wallet companies always provide safe front-end packages. When it comes to important JavaScript projects, it's super important to run a dependency review and check for those SLSA-style provenance details. Trust me, you really don’t want to skip this step! (ledger.com).

5) Runtime monitoring, MEV‑safe ops, and incident response

Keeping an Eye on Things and Spotting Oddities. Hey there! Check out Forta’s Threat Detection Kits for all things DeFi, bridges, governance, and stablecoins. It's a great ride, and you'll be glad you hopped on! Creating playbooks that tie different alert types to quick actions is super helpful. Think about things like pausing modules, tightening up those rate limits, getting in touch with the sequencer, or even flipping that front-end kill switch. It just makes everything run smoother! If you want to dive deeper, just click here for more info! If you’re looking for some really great continuous monitoring options, you might want to check out Hexagate. They were acquired by Chainalysis back in December 2024, and they're definitely worth considering along with a few other similar services. They offer real-time threat detection, which some major protocols and exchanges are already taking advantage of. If you want to dive deeper into this, you can check it out here. Happy reading!
Coordinating emergencies and offering bounties. Don’t forget to include SEAL 911 in your emergency runbook! It's super important. This is a reliable volunteer hotline that’s been thoroughly checked out. It can quickly assess on-chain incidents and connect the right responders to tackle the issue. If you're looking for more details, you can check it out here. There's a ton of useful info waiting for you! Hey, just a quick reminder to set up a bug bounty program! Seriously, take a look at Immunefi. They've already dished out more than $100 million to ethical hackers. Pretty impressive, right? On top of that, some major players like Uniswap v4 are even throwing in a cool $15! 5 million bounty. Just a heads-up: while bounties are pretty cool, they shouldn't replace audits. Think of them as a way to lower risk a bit between releases, but they’re not a complete solution. Check the numbers here.
MEV and Admin Ops. When you're dealing with sensitive admin tasks--like setting caps, changing oracles, or enabling assets--it’s a good idea to use private order flow via Flashbots Protect RPC. Just make sure you're using the “max privacy” settings or fine-tuning your hints to keep things secure and under wraps. This can really help you avoid those pesky frontrun problems and even grab some MEV refunds! Hey, just a quick reminder--make sure to note the default privacy settings in your runbooks. It’s super important! If you want to dive deeper into the details, you can check it out here.

6) Two practical examples you can lift today

Circuit breaker thresholds (like the ERC‑7265 style).
Stablecoin pool outflows: These start happening as soon as we hit zero. In just five minutes, we saw a whopping 75% of the Total Value Locked (TVL) change hands. Crazy, right? Once it’s activated, you'll need to wait 30 minutes before you can use it again. Also, there's this handy “delay settlement” feature that allows outflows to stack up so we can take a closer look at them, and if necessary, even reverse them.
Volatile asset pool: This one kicks in at 1. Just a heads up, we're looking at a 5% total value locked (TVL) over a span of 10 minutes. The cooldown period is pretty quick--only 10 minutes! We've got this "revert on outflow" mode in place to help keep things stable while we dig into the details. This way, we can avoid any weird state drift.
Governance: So, here’s the deal with the Pauser role: they can only hit the unpause button after getting the green light from a 2-of-3 multisig. And don’t forget, they also need to throw in a link to a post-mortem in the proposal metadata. This method lets us hit the brakes when we need to, but it also means that admins can't just take over whenever they want. (ethereum-magicians.org).
CCIP Rate-Limit Setup Alright, so here's the scoop on the TokenPool: we can send out a maximum of $2 million every hour, and it gets a nice little refresh around 5:55. 55… dollars a second. The cap for incoming transactions is set at $2. 1M per hour. So, when you check out the lane aggregate, we’ve got a cap set at $5 million per hour in USD. This little buffer we’ve got between incoming and outgoing really helps with batching and getting things finalized, just like the documentation mentions. Just a quick reminder--make sure to assign RATE_LIMIT_ADMIN to a separate multisig for extra security! It’s an important step to keep things safe. Just a quick reminder: if something happens, one of your first steps should be to tighten it to 20% of normal. It's a simple move, but super important! Feel free to dive into the details in the documentation whenever you're ready!

7) Example 14‑day audit & hardening sprint (what to expect)

Days 1-2: We’re going to start things off by locking in our scope. After that, we’ll dive into a workshop for threat modeling. To cap it all off, we’ll finalize and sign off on the property list.

Days 3-5: Let’s dive into setting up our static analysis baseline using Slither! We’ll also work on improving our unit and fuzz test harnesses, and take a peek at some of the initial results we uncover. It’s all about laying a solid foundation and figuring out what we’re dealing with! (github.com). Alright, so here’s the plan for Days 6-8: we’re going to jump into invariant design, and I think you’ll really enjoy using Scribble for some interesting instrumentation. Plus, we'll do some Halmos symbolic checks on the important modules. It should be pretty engaging! (docs.scribble.codes).
Days 9-10: Alright, moving on, we're going to take some time to check our assumptions around L2 and bridges. We’ll also dive into the costs associated with oracle manipulation and explore what we can do to make our ops safe from MEV. (docs.optimism.io). Days 11-12: We’ll be diving into some tests on governance and timelock wiring using a fork. It’ll be a good chance to practice Safe roles and thresholds too. Plus, we’ll go over the Delay/Guard setups, making sure everything is lined up. (docs.openzeppelin.com).
Days 13-14: Alright, this is the exciting part! We’re going to wrap everything up with a report. We'll double-check all the fixes we’ve made and run through an incident tabletop. It’s kind of like putting together a simulation that mimics GALA or Munchables situations, but tailored specifically to your controls. (cryptoslate.com).

8) Emerging practices to adopt in 2025

L2 Fault-Proof Maturity Hey there! Just a quick reminder for all you folks working on OP Stack or Arbitrum--make sure to update your “trust/minimized-trust” claims. And while you’re at it, it’s a good idea to give your bridge UX copy a little tweak. Happy coding! We really need to shine a light on permissionless fault proofs and BoLD activation. People are genuinely concerned about being able to exit safely, and that’s something we can’t overlook. If you're curious and want to dive deeper, you can find all the details right over here. Enjoy exploring!
Using Permit2 for Allowances by Default. How about we make expiring approvals and signature-based transfers our go-to method? It just makes sense! This is going to help you finally say goodbye to that never-ending allowance debt! Hey, just a heads up--make sure your support team is all set to help out users with batch-revoking if any issues arise. It’s always good to have them on standby during those moments! If you want to explore this further, just click here.
Threat Modeling for Uniswap v4 Hooks. Hey there! If you’re diving into integrating or writing hooks, just a quick reminder to pay close attention to the v4 security guidance. It's really important! Make sure to really dive into testing those “flash accounting” settlements. It’s super important! And hey, don’t forget to allocate a bit of your budget for bounty surfaces, especially if your hooks are managing pooled value. It’ll save you some headaches down the road. If you're looking for more details, you can check it out here. It’s worth a look!
Proactive Supply-Chain Hygiene Get into the habit of locking down your frontend packages and double-checking them. It’s a smart move to add provenance and use signed releases. Trust me, it pays off! Just take a look at what happened with Ledger's 2023 Connect Kit--it was crazy how in just two hours, so many users got hit hard! Seriously, we need to think of those UI code channels as super important. No exceptions! If you want to dive deeper into that incident, just click on this link here. It’ll give you all the details you need!

Final cut‑down checklist (print this)

Architecture
We’ve got the L2 stage and exit trust all sorted out, and the bridge limits alongside the runbooks are all set and good to go! (medium.com).
We've got our Oracle windows, bounds, and fallbacks all set up, and we've even taken a look at the costs involved in manipulation. (blog.uniswap.org).
Contracts
So, for the proxies, we’ve got the initializers locked down, we’ve double-checked the storage gaps, and we’ve made sure that upgrade authorization is all set to go. (docs.openzeppelin.com). We're really into the whole least privilege thing when it comes to roles. On top of that, we've got this cool two-step ownership setup and a time lock for production paths. It just keeps everything secure and organized! (docs.openzeppelin.com).
Allowances: We’ve added Permit2 and introduced a new user-friendly interface for batch revoking. (docs.uniswap.org).
We've got the circuit breaker and outflow caps all set up and thoroughly tested. (ethereum-magicians.org).
Verification Hey! Just wanted to share that we’ve got our unit tests and invariant tests all wrapped up. Plus, we’re throwing in some Echidna fuzz testing too. On top of that, we’re using Halmos for symbolic tests and keeping things in check with Slither CI. Everything’s pretty much in place! (github.com).
Ops & governance So, we've set some safe limits in place. We've gone through the modules and guards to make sure everything checks out, and we’ve also added a delay for those larger outflows. (help.safe.global).
We’ve got all the governor parameters set up and tested, including delay, period, and quorum. Everything's good to go! (docs.openzeppelin.com). We're making sure to pin down our dependencies and check where everything comes from. Plus, we took a good look at the supply chain for wallets and connectors too. (ledger.com).
Monitoring & IR Hey everyone! Just wanted to share that our Forta subscriptions are officially up and running. Plus, we've got everything in place for Hexagate and enterprise monitoring whenever we need it. Exciting times ahead! (docs.forta.network).
Just a heads up, SEAL 911 is included in our runbook, and we've got a solid bug bounty program set up with Immunefi and Cantina. (docs.uniswap.org).
The Flashbots Protect RPC is all set for admin tasks, and we’ve put together some helpful privacy tips to guide you. (docs.flashbots.net).

Closing

Security isn't a one-and-done deal; it’s something you need to keep working on all the time. It's all about gathering evidence, planning ahead, keeping tabs on what you've done, and making improvements along the way. Take a look at this handy checklist to help you get everything in order for your next release! Don’t forget to back up your points with some solid proof--things like tests, invariants, and limits really help! Plus, it’s a good idea to sharpen those incident response skills of yours.

If you're on the hunt for a partner who truly knows their way around code and can back it up with some solid proof, 7Block Labs is definitely the team you want in your corner. They’ve got you covered for the entire sprint! Whether it’s threat modeling, setting up verification harnesses, or even tackling governance wiring and monitoring, they can take care of all of it. Oh, and don’t forget the incident tabletop exercises--they handle those too! And the coolest thing? It’s totally tailored to suit your setup and schedule!