blockchain software development outsourcing: Managing Quality, Security, and IP

These days, outsourcing blockchain software is quite the trend! Things are shifting a lot lately! With all the recent protocol upgrades, new EU regulations like MiCA coming into play, changes in the vendor landscape, and a rise in attacks, we’re definitely seeing a different risk environment out there. Hey there! This guide is designed to give decision-makers a handy playbook for tackling quality, security, and intellectual property as you dive into Web3 engineering in 2025.

1) Why your outsourcing playbook must change in 2025

So, Ethereum rolled out its Dencun upgrade (that’s EIP-4844 for those in the know) on March 13, 2024. Exciting times! With this upgrade, we've got something called "blob" space now. It's pretty cool because it makes posting data for Layer 2 a lot cheaper. Plus, it really changes the game for how rollups handle batching and storing data. Hey vendors! It’s time to shift your focus to blob economics and think about your data availability options. Let's leave that old calldata mindset behind and embrace something new! (ethereum.org).

In Europe, they're gradually rolling out the MiCA regulations bit by bit. So, just a heads up: the rules for stablecoins officially took effect on June 30, 2024. Then, starting on December 30, 2024, the main parts of the CASP regulations will roll out. And it looks like ESMA is getting ready to jump into action with some coordinated enforcement in the first quarter of 2025. It’s all happening pretty soon! On top of that, there are some national “transitional” windows that are set to stick around until July 1, 2026. For example, Spain has decided to push its deadline all the way to July 2026. If you’re working on a project for users in the EU, it’s super important to have a solid plan for MiCA compliance. Don't overlook it! (ethereum.org).

Hey, just a heads up! OpenZeppelin is planning to wrap up its Defender SaaS on July 1, 2026. On the bright side, they’re going to make the Relayer and Monitor open-source, which is pretty cool! If your vendor is using Defender for operations or monitoring, it’s super important to encourage them to whip up a migration plan as soon as possible. Whether they decide to self-host or look for another solution, getting on this quickly is key! (blog.openzeppelin.com).

Account Abstraction (ERC-4337) has been really popular lately! A bunch of projects are jumping on board, using bundlers and Paymasters to make those gasless experiences happen. It's exciting to see how this is shaping the way we interact with crypto! Don't forget to check in with your vendors about their experience with ERC-4337. Also, it’s a good idea to ask if they have any production runbooks prepared. It’ll save a lot of headaches down the line! (docs.erc4337.io).

Hey, don’t forget about the operational risks that come with L2s! A good example is what happened with Coinbase’s Base L2. Back in August 2025, they hit a snag and had a serious hiccup--a 29 to 33-minute halt because of some sequencer failover problems. Just goes to show that even the big players can run into trouble! This really shows how important it is to have solid reliability engineering for L2/SaaS. Relying just on contract audits isn't going to do the trick. (coindesk.com).

2) A procurement blueprint: evaluate vendors against objective, testable criteria

Let’s make sure we have a solid “definition of done” that really lines up with our current attack surface and keeps us in check with the regulatory scene. It’s important to have clarity here! Make sure to include these points in your RFP and SOW.

2.1 Architecture and chain/DA choices (prove, don’t pitch)

So, when we're talking about Ethereum L2 and blob data, it’s really crucial to keep an eye out for some clear proof that the team is managing pricing, posting, and monitoring blob usage effectively after the Dencun upgrade. This might involve setting aside some cash for blob gas, keeping an eye on any spikes in blob fees, and really getting to grips with the pros and cons of various DA backends--like comparing Ethereum blobspace to Celestia, Avail, or EigenDA. It’s all about finding what works best for you! Feel free to take a look at it over on ethereum.org. You might find some interesting stuff there!

Hey, if you’re thinking about going for a modular DA, don’t forget to ask about the specific DA stack and the governance details. It’s super important to get those specifics! For instance, you might be curious whether they're working with Polygon CDK Validium, and if they’ve got a designated Data Availability Committee on board, plus a quorum policy in play. It’s really helpful to know how they gather signatures and how clients are able to get their data back when there's a DAC churn. If you're looking for more details, check out the Polygon documentation. It's got everything you need!

If you’re working with OP Stack, Arbitrum Orbit, or zk stacks, it’s really important to grab those environment-specific SRE runbooks. They’ll make your life a lot easier! You might want to check out some guidelines on sequencer failover drills and standby provisioning. Also, don’t forget to look into their RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets when the system's under load. It'll definitely help you get a better understanding of their processes! It’s a good idea to look back at how similar situations were tackled in the past, like the Base sequencer handoff incident. If you're curious, you can check it out over on Coindesk for more details!

2.2 Secure SDLC for smart contracts (EVM or zk)

Mandate a Pipeline to Catch Bugs Before Mainnet Launch

We really need to establish a strong pipeline that lets us catch those annoying design, coding, and integration bugs before we launch on the mainnet. It’ll save us a ton of headaches later on! Alright, let’s break this down and see how we can handle it:

Steps to Implement the Pipeline

Design Review
Before we jump into coding, let’s ensure our design is in great shape! Getting together for a group review is a great way to spot any potential problems before they escalate. It’s like having a safety net that gives everyone a chance to weigh in and make sure everything's on track.
Automated Testing
Let’s start incorporating automated testing into our workflow. This might involve running some unit tests, integration tests, and end-to-end tests to make sure everything’s running smoothly like it should.
Continuous Integration (CI)
Let’s set up a CI system that kicks off our tests automatically whenever new code is pushed. It’ll help us catch any issues early and keep everything running smoothly! By doing it this way, we can spot bugs as soon as they pop up instead of letting them linger until later on.
Code Review
Make sure to set up a detailed code review process. Sometimes, having another set of eyes on your work can really help catch issues that the original developer might overlook.
Staging Environment
Go ahead and create a staging environment that closely resembles the mainnet. This lets us run tests in a real-world environment without messing with the experience for our users.
Bug Bounty Program
Have you thought about starting a bug bounty program? It could be a great move! Getting outside developers involved can really encourage them to spot and report any bugs we might have missed.
User Testing
Let’s set up some user testing sessions to collect feedback and spot any usability hiccups before we launch. It’ll help us make sure everything runs smoothly!

Conclusion

Setting up this pipeline will really help us cut down on the number of bugs making it to the mainnet. Let’s team up and get this done!

Threat modeling and standards

Alright, let’s get started with the OWASP SCSVS v0! 0. We're using 1 and EEA EthTrust v2 to sharpen up our control objectives and establish some straightforward pass/fail criteria. Check it out here.

Static, dynamic, and property checks

When it comes to static analysis, we’re using Slither as a key player in our CI workflow. Hey, just a quick reminder to pass along the detector set and those zero-tolerance rules. You know the ones--like staying clear of tx-origin use and making sure we don't have any unbounded loops. It’s super important! Oh, and don’t forget to pin the Slither version! More info here.

When we dive into fuzzing and testing for invariants or properties--like with tools such as Foundry or Echidna--we should definitely establish some baseline campaign durations, seeds, and coverage goals. It'll help us stay organized and make the most out of our testing efforts! Also, don’t forget to add properties that check for ERC or standard compliance! If you want to dive deeper into the details, just check it out here.

When it comes to the key components--like vaults, bridges, and the math behind AMMs--we're really going the extra mile by using Certora Prover for formal verification. It’s all about making sure everything is rock solid! We've got to make sure we send those machine-readable rules (CVL) along with the final reports. If you want to get into the nitty-gritty details, check it out here.

Verification and provenance

We really need to make sure we ask for “exact match” verification on Sourcify along with a metadata hash (auxdata). This way, we can show that the bytecode and the compile settings are exactly the same. When it comes to those important contracts, just getting partial matches isn’t going to do the trick. If you want to dive into the details, you can find everything you need right here. Take a look!

Hey, just a quick reminder to make sure we publish the source and metadata to IPFS. Don’t forget to verify it using the Sourcify API v2, alright? Thanks! Let’s make sure to toss in a bytecode-diff artifact with our delivery too. It’ll be super helpful! If you want to dive deeper into this topic, you can check out more details here. Happy exploring!

Supply-chain integrity for artifacts

And finally, let’s not forget to sign our build artifacts and deployment manifests with Sigstore cosign. You can go for keyless signing or use KMS if that’s your jam. Just make sure we attach those attestations too! Hey, just a quick reminder to share the policy and the verification commands, okay? Thanks! If you want to dive deeper, just take a look at this link. It’s got all the info you need!

Example acceptance gate (include in SOW):

There aren't any serious gaps in the SCSVS, so we need EthTrust v2 to clear for the contract set. (owasp.org). Alright, so here’s the deal: Slither needs to be all tidy with the detectors we talked about. We’re aiming for at least 95% coverage on both lines and branches for the core libraries. Plus, we should run at least 100 different invariants through a minimum of 100,000 iterations each. Let's make sure everything's in top shape! (github.com).
We also have to demonstrate at least N key properties in Certora. This includes things like making sure the vault is safe from reentrancy issues, keeping track of the fee accounting correctly, and ensuring that no one can mint or burn tokens without permission. (docs.certora.com). Alright, so here’s the deal: just double-check that everything is an “exact match” in Sourcify for all your deployments. Also, don’t forget to get that signed release bundle with cosign. It’s super important! (docs.sourcify.dev).

2.3 Upgrades, governance, and kill‑switches

Alright, so here’s the deal: you should definitely use the ERC‑1967 storage layout. It’s solid! Also, stick with reliable proxy patterns--UUPS or Transparent are great options. Just make sure to manage everything through a timelocked multisig for that extra layer of security. You'll be in good shape! Hey, just a quick reminder to whip up those upgrade runbooks and role maps when you get a chance. Thanks! (eips.ethereum.org).

Hey, just a quick tip: it's really important to set up an emergency pause or circuit-breaker that you can tweak whenever necessary. Also, don’t forget about those on-chain timelocks! They’re super handy. It's really crucial to figure out who has the power to hit the pause button and how the team will keep each other in the loop about any issues that come up.

So, if you're considering making the leap from Transparent to UUPS, or even swapping between different proxy families, it's really important to take your time and plan it out.
Getting through this isn’t exactly a walk in the park, and there’s a pretty decent chance that some of your tools might run into issues as you go along. (forum.openzeppelin.com).

3) Key management and infrastructure you can audit

Alright, here’s the scoop: make sure to stash your keys in HSM/KMS instead of leaving them hanging out on your laptops. Cloud KMS is now supporting secp256k1 (the one used in Ethereum) and Ed25519! Plus, they've got FIPS-validated modules, which is pretty cool. Hey, just a quick reminder! You'll need to include KMS URIs in your code, along with the necessary policies attached to them. Check it out here.

Alright, let’s dive into the essentials you really need:. When you're setting up AWS KMS keys, make sure to go for either the ECC_SECG_P256K1 or Ed25519 type. It’s a good idea to have automatic rotation enabled and to keep a solid audit trail as well. More details here. If you're using Azure, definitely check out Azure Key Vault (Managed HSM) or go for Vault-backed keys. Just make sure that ES256K is supported and verify the FIPS level while you're at it! If you want to dive deeper into this topic, check it out here. When using Google Cloud KMS, definitely opt for EC_SIGN_SECP256K1_SHA256 for your signing process, and don’t forget to enable that HSM protection. It's really important! If you want to dive deeper into this topic, you can check out more details here. It’s got a lot of great info!

If you’re diving into node operations, it’s super important to have great SRE-grade observability for Geth, Nethermind, and Erigon. Trust me, you want to keep a close eye on things! Basically, you'll want to get your Prometheus and Grafana dashboards up and running, plus set up alerts for things like peer counts, sync lags, and RPC latency. It’s all about keeping an eye on those metrics! It's super important to set up RPC multi-provider failover along with health checks and regional routing. This way, you can be sure everything’s running smoothly and you’re prepared for any hiccups that might come your way! Dive deeper here.

4) Post‑deployment monitoring and incident response (IR)

Hey there! Just a quick heads-up: Defender SaaS is winding down on July 1, 2026. So, it's a good idea to check in with your vendor and ensure they've got your back with self-hosted monitoring and relayers. You might want to look into options like OpenZeppelin Relayer/Monitor OSS or something along those lines. Better to be safe than sorry, right? Hey, just a quick reminder to make sure you've got those runbooks and alert policies organized--whether you're using Datadog or PagerDuty. Oh, and don't forget to sort out those “break-glass” procedures too. It’s important stuff! If you're curious and want to dive deeper into the details, feel free to check it out here!

Make sure to connect those alerts to specific actions. For instance, consider what might trigger any deviations in oracle data, any activities related to role upgrades, unexpected mint or burn events, or sudden spikes in approvals. It really helps to have those details mapped out! And don’t forget to link these to your circuit breakers and governance queues!

Run some chaos drills to get hands-on experience with situations like sequencer failures and RPC outages. Try to aim for a recovery time objective (RTO) of 15 minutes or less for your dapp operations. This way, if anything goes wrong, you can bounce back quickly without too much downtime. Hey, just a heads-up! The Base outage is a great example of what can really go sideways, so it’s a good idea to check it out. You can read all about it here. It’s definitely worth your time!

5) Compliance by design (MiCA, OFAC, privacy)

MiCA readiness Hey there! If you're involved in issuing ART or EMT (which is just a fancy way of saying stablecoins) or if you’re running a CASP in the EU, you definitely want to pay attention. The deadline is approaching fast! The rules are now in action, and ESMA is urging national authorities to start enforcing them as early as Q1 2025. So, make sure you’re on top of it! The timelines for transitions can really differ depending on the country, and they’re set to run all the way through July 2026. Vendors should really think about syncing up their features, such as custody, market abuse controls, and disclosures, with the different MiCA Titles and the timelines for rolling them out. It just makes sense! For more info, feel free to check this out here. It’s got some useful details!
OFAC sanctions controls Hey there! So, if you're in the U.S. right now... Hey there! Just a quick heads-up--it's super important to make sure your platform has its sanctions screening, IP geofencing, and escalation/reporting procedures all squared away. Hey, just a heads up - OFAC has some pretty straightforward rules when it comes to virtual currency, so definitely keep that in mind! It’s a good idea to check in with your vendors and ask them about their sanctions risk assessments, any test results they've got, and their training logs. It’ll help you stay on top of things! If you’re looking for more details, you can check it out here.
FATF Travel Rule If you've got a solution that includes VASPs, it's super important to ensure you're all set with the Travel Rule data-sharing processes and the necessary provider integrations. Those supervisors are really stepping up their game starting in 2025, so getting ahead of this now will save you some headaches later! If you're looking for more details, feel free to take a peek at this link: here. It's got some great insights!
GDPR and Data Protection in the Context of Blockchains (EU). So, based on the EDPB’s guidance that's rolling out in 2025, it's a good idea to avoid putting personal data on the blockchain. Instead, why not consider setting up off-chain storage using commitments or hashes? It's a pretty interesting approach! Make sure you clearly outline who’s the controller and who’s the processor before you dive in. And hey, don’t skip the DPIA - it’s super important to have that sorted before you roll anything out! Don't forget to ask your vendor for their DPIA and any notes they've got on how they handle data minimization. It's always good to have those details on hand! If you're looking for more info, you can check it out here.

6) Intellectual property: keep what you pay for

When it comes to exits or IPOs, IP issues are still the biggest headache causing delays in blockchain deals. Be sure to tackle this right from the beginning.

Task > "Work for Hire." ” In the U.S. Hey, just a heads up--“work for hire” isn’t a blanket rule for software, even though a lot of founders might think it is. When you're drafting your contractor agreement, be sure to use present-tense language like “hereby assigns” to keep things clear. Also, don’t forget to include waivers for moral rights and outline what’s expected when it comes to disclosing inventions. It's all about making sure everyone’s on the same page! Make sure to share these requirements with any subcontractors you’re working with, too! (pillsburypropel.com).
Contribution Model: CLA vs DCO.

When it comes to the contribution models, we’ve got two main players: the Contributor License Agreement (CLA) and the Developer Certificate of Origin (DCO). Each has its own vibe and purpose.

A CLA is a legal document that individuals sign to give the project maintainers the right to use their contributions. This often involves a bit of a formal process, but it helps protect both the contributors and the project in the long run.

On the flip side, the DCO is more laid-back. Contributors simply sign off on their commits, stating that they own the work and are okay with it being used in the project. It’s a quicker process, which appeals to a lot of developers looking for ease and efficiency.

In short, both models have their perks, so it really comes down to what fits best for your project’s needs and the community you're building. So, if your vendor is totally on board with letting in outside contributions, you'll want to decide what works best for you. Are you leaning towards Contributor License Agreements (CLAs) for that extra layer of IP rights and a bit more clarity? Or do you prefer the Developer Certificate of Origin (DCO), which is a bit more chill? It’s all about what fits your vibe! Just remember to weigh the pros and cons of both sides. (linux.com).

Choosing the Right License for Your Contracts and SDKs.
The Apache-2. The 0 license offers a straightforward patent grant, which makes it a safer bet for businesses than MIT or BSD licenses. This is particularly important when you consider that contributors could have patents up their sleeves. (httpd.apache.org). Hey, just a heads-up about the Business Source License (BSL/BUSL). It can actually limit how you can use the product for production or commercial purposes until a specified date. So, it's something to keep in mind! This can be a great opportunity if you’re the one giving out the license, but it can definitely be a bit risky if you're depending on it. Want a practical example? Check this out: Uniswap v3 switched from the Business Source License (BSL) to the General Public License (GPL) back in April 2023. Meanwhile, Uniswap v4 is still under the Business Source License, and it won’t be able to change that until June 15, 2027--unless the DAO steps in and decides to do something different. Your vendor should let you know about any BSL components they have, along with their “Additional Use Grants.” " (unchainedcrypto.com).
Open-source Compliance Hey, don’t forget to grab a license inventory and check the policy! Just a heads up, we can’t have copyleft in any proprietary components unless we’ve got the green light. Also, make sure they include those SPDX IDs in the headers. Thanks! Just a quick reminder: when you're handing things over, make sure you ask for that license report and any third-party notices too. You don’t want to overlook those!

7) Security posture vs. today’s attack trends

As of 2025, losses are still running pretty high, mainly due to service compromises and wallet takeovers being the heavy hitters in the game. Make sure your vendor is really upping their game and not just sticking to the basic contract stuff. Keep an eye out for things like how well the signer maintains their hygiene, whether they use phishing-resistant authentication, have any spending limits in place, and how quickly they work with analytics and tracing partners when something goes wrong. If you want to dive deeper into the details, just head over to this link: chainalysis.com. You'll find all the info you need!

Hey there! If you’re getting started with creating those 4337 smart accounts, make sure to check in on their bundler and paymaster security controls. It’s super important to have that covered! Make sure to check for alignment with ERC‑7562 standards. You’ll also want to look for safeguards against mempool DoS attacks and some throttling to prevent sponsor abuse. These aspects are really important! And don't forget to get them in on the EF's AA bug bounty scope too! If you're looking for more info, check this out: (docs.erc4337.io). It'll give you some great insights!

8) Contracting checklist: put it in the MSA/SOW

Make the Vendor’s Promises Enforceable

When you're working with vendors, it's really crucial to ensure that what they promise is something you can actually hold them to. Check out these ideas to help you out:

1. Get Everything in Writing: Make sure to ask for a written contract that lays out exactly what the vendor is promising. It's super important to have everything documented so there are no surprises later on! Doing it this way helps avoid any mix-ups down the line.

2. Define What You Need: Make sure to clearly outline what you're looking for. Rather than just tossing around the term "good quality," let’s break down what that really means for us. It’s all about being clear so we’re all on the same wavelength, right? To me, good quality means durability, reliability, and just an overall sense of satisfaction. It should feel like a solid investment rather than just another purchase. I want things that not only look great but also perform well and stand the test of time. What about you? What does "good quality" look like in your eyes?

3. Add Timelines: Don’t forget to set deadlines for when things need to be delivered!
This keeps the vendor on their toes and gives you a straightforward timeline to look back on whenever you need it.

4. Lay Out the Consequences: It’s a good idea to be upfront about what happens if the vendor doesn’t stick to their commitments. That way, everyone knows what to expect. Just be upfront about what could happen if things don’t go as planned, whether it’s a penalty fee or the chance for you to claim damages. It’s important for them to know the potential consequences of not delivering.

5. Go for Standardized Contracts: Whenever you can, stick to standardized contracts that come with terms you can actually enforce. It's a smart move! This can really help safeguard your interests and make everything run more smoothly.

6. Get Some Legal Help: If you're feeling a bit confused about the terms, it could be really helpful to chat with a legal expert. They'll be able to clear things up for you. They can really help you make sure that the contract is strong and actually enforceable.

7. Stay Professional: It's super important to keep things professional when you’re communicating. Always remember to strike that balance! This really shows that you’re serious about the agreement and that you’d like the other person to feel the same way.

If you stick to these steps, you can make sure that what the vendor says isn't just fluff, but real commitments they can actually follow through on.

Security deliverables Alright, so here’s the scoop: you’re going to need a few key things. First off, grab the SCSVS/EthTrust v2 compliance reports. You'll also want the outputs from tools like Slither, Foundry, or Prover. Don’t forget to get the “exact match” from Sourcify, as well as the Sigstore attestations. Oh, and a dependency SBOM plus a license report should be on your list too. Make sure you have all of these handy! Take a look at this: (owasp.org). It's got some really cool info!
Operations deliverables Having runbooks for key rotation, proxy upgrades, and emergency pauses is super important. You never know when you might need them, so it’s a good idea to have those details sorted out ahead of time! Hey, just a quick reminder! Make sure you include a catalog for tracking alerts, the Defender migration plan, and the setup for self-hosted monitoring. It’ll really help keep everything organized! If you want to dive deeper into this, check out the details over at blog.openzeppelin.com. There's plenty of info waiting for you there!
Compliance deliverables Hey there,

Just a quick reminder to put together a memo about how MiCA applies to us. Also, don't forget to set up a remediation backlog while you’re at it. Thanks! Don’t forget to put together a summary of your OFAC program! Make sure it includes details about how you handle screening, your geofencing strategies, and how often you test everything. It's important to cover all these bases! Finally, don’t forget to whip up a DPIA and a plan for data minimization! Learn more here: (esma.europa.eu).

IP and licensing When it comes to IP and licensing, make sure you include a current assignment, a Freedom to Operate (FTO) statement, and a licensing policy that uses Apache-2. Let's stick with 0 as our default unless we come to a different agreement! Hey, just a quick reminder to make sure you mention any BSL/BUSL dependencies you’ve got. It’s really important to include their change dates and any grants related to them. Thanks! Take a look at this link: httpd.apache.org. It’s got some great info!
Export control warranty Hey there! Just a quick reminder to have your vendor properly classify their encryption products, like those 5D002 or 5D992 mass-market items. It's super important that they stay on top of EAR reporting too. Keeping everything compliant is key! They’ll also keep you updated on any rules regarding Russia and Belarus, along with any risks that come with sanctioned parties. For more info, check out their website at bis.doc.gov. They’ve got all the details you might need!

9) Two practical examples

Example A: L2 ops hardening after the Base outage

Alright, before you kick things off, here’s a quick checklist to make sure everything runs smoothly. First up, get your sequencer failover game day ready--this is crucial! Double-check that your standby system is good to go, and ensure that the "Conductor/leader" components can swap roles without any hiccups. Don’t forget to test those deposit and withdraw queues while the system is on pause. Lastly, whip up some user communication templates so you can keep everyone in the loop. You’ve got this! (coindesk.com).

Example B: Defender sunset migration

Quarter 1: Let’s get those inventory automations rolling--think relayers, actions, and monitors. And don't forget to link them up with the OSS Relayer/Monitor! Make sure you get everything set up in your cloud! And hey, don’t forget to connect it with Slack and PagerDuty, too. You’ll want to have those integrations in place! We should definitely take another look at those upgrade proposal flows and make some tweaks.
Quarter 2: It’s time to kick off the parallel run, make the switch, and then say goodbye to the old system! Let’s remember to keep our logs and artifacts handy for audits. It's always a good idea to have everything documented! (blog.openzeppelin.com).

10) Questions to ask every blockchain outsourcing vendor this year

Take a look at a recent project where we had the chance to work with EIP-4844 blobs. We rolled out some handy alerts and smart assumptions for the blob fee budget. You can find all the info you need right here. Check it out!

So, which security standard do we actually hold a certification for? Well, we’re certified against SCSVS/EthTrust. If you’re interested, you can check out the latest pass results and any outstanding issues right over here.

Hey, just wanted to let you know that we have the Certora report ready, along with the CVL properties for an important module that we checked out. Check out these findings right here! Check it out!

Curious about how we keep our 4337 stack safe and sound? We've got you covered! We dive into our bundler policy, share how we protect against any paymaster abuse, and talk about our involvement in bug bounties. Hey, if you want to dive into the details, just click here!

Hey! We need to share the Sourcify exact-match link with you, along with the cosign verification command for our most recent deployment. If you're looking for that info, you can check it out here.

Hey team! So, what's the plan for wrapping up Defender by July 1, 2026? If you want to dive into the details of our strategy, check it out here. Let’s gear up for this transition!

Hey EU folks! We wanted to give you an update on where we stand with MiCA and GDPR compliance. We've got some practical stuff to share, like our CASP prep list and DPIA. You can check them out here. Take a look!

TL;DR buyer’s checklist

Architecture: We’ve set up a design that’s all about blobs, and we’ve also got a solid backup for our DA choice in the mix. By the way, we’ve successfully tested the L2 SRE runbooks! Check it out here.
Code Security: We're super focused on making sure everything's locked down tight. We've got SCSVS/EthTrust in our toolbox, plus we use Slither, fuzzing, and formal verification to keep things safe. On top of that, we're working with Sourcify to nail down those exact matches and make sure we have all the signed releases in place. More details here.
Ops: We’ve got our keys locked down with KMS, and we’re using secp256k1 and Ed25519 for extra security. We're putting a lot of effort into observability right now, and we've also implemented RPC failover to make sure everything runs seamlessly. Get the scoop here.
Compliance: We’ve laid out the MiCA timeline, created an OFAC program, and tackled GDPR by putting together a DPIA and figuring out off-chain storage strategies. If you're looking for more info, just check this link out here. It's got what you need!
IP: We’re sticking to a simple assignment language, and we prefer using Apache-2.

0. We're also keeping it real by letting you know about any BUSL timebombs that might pop up. Want to get into the nitty-gritty? Check it out here!

If a vendor can’t back up any of those points we talked about, it’s probably best to keep looking.

At 7Block Labs, we're all about giving startups and bigger enterprises the tools they need to kick off their blockchain systems. We make sure everything is blob-aware, audit-ready, and totally clear of any IP issues. It's all about setting you up for success! We make this happen by giving you formal proofs, exact matches from Sourcify, attestations from Sigstore, and all the important documents related to MiCA and GDPR. Plus, we've got a super useful IR runbook that you can really put to work. On top of that, we’ll transition your Defender automations over to open-source tools. We’ll also include RTO-backed playbooks to help you tackle any sequencer or RPC failures you might encounter.