At 7Block Labs, we jump on IP disputes and deployment hold-ups right from the get-go. We make sure everything is traceable at the artifact level, using tools like Solidity and ZK. This way, we keep things smooth and transparent from the very beginning! Next, they put this traceability to good use for the procurement, security, and legal teams. What’s the bottom line? You’ll end up with processes that are ready for audits and smooth handoffs that speed up approvals without compromising on quality. It’s all about keeping those technical standards high while making everything run more efficiently!

Hey there! This guide is made for Enterprise teams, whether you’re in Procurement, Legal, Security, or Engineering. If your focus is on SOC 2, SBOM/SLSA provenance, reproducible builds, and continuity planning, you’re definitely in the right place!

7Block's Approach to IP Ownership and Source Code Handoff

“Where exactly is the IP, and can we operate it without the vendor?”

Common Issues We Encounter

So, here are a few common problems that we usually get called in to tackle:

So, just a heads up: if you try to re-verify compiled bytecode on the mainnet, you might run into some trouble. That's because the specific compiler settings used weren't saved, which can throw a wrench in the works. Just something to keep in mind! This could slow down audits and listings on Level 2. To get the deployed bytes just right on Etherscan, you need to make sure that the compiler version and the optimization settings match exactly. It’s super important! If you want to dive deeper into this topic, just click here to learn more!

You know how sometimes source files don’t come with their SPDX headers? Or they end up mixing licenses that just don’t play well together? Like when you find AGPL snippets thrown into a proprietary codebase--it’s a real head-scratcher! So, when you're working with Solidity, it's important to include an SPDX identifier in every file. If you forget to add it, you'll end up with some annoying warnings, and trust me, it’ll make license scanning a real pain down the line. If you want to dive deeper, you can check out more details right here. It’s packed with helpful info!

It’s pretty common to find ZK proving keys and trusted setup artifacts just hanging out on an engineer's laptop rather than being safely tucked away in a secure escrow. It would be so much better if they had proper instructions for how to recreate everything, too! So, when it comes to Circom and Groth16 flows, they're really tied to the Powers of Tau and also need that per-circuit Phase 2. So, you’ve got your zkey and verification key materials, right? Just a heads up, it’s super important to keep those organized. Make sure each version is clearly labeled and that you can easily reproduce them whenever you need to! If you want to explore this topic further, check it out here. It'll give you some great insights!

Sometimes, procurement processes can get a bit tricky, especially when there's a missing piece in the puzzle like SOC 2-aligned evidence, SBOMs, or provenance attestations linked to releases. These days, buyers are really looking for proof of SSDF/SBOM. Just a heads-up: CycloneDX has officially become an ECMA standard, and it’s gaining a lot of traction in different industries. If you're looking for more insights, check this out here. It’s definitely worth a look!

If something goes wrong, like a vendor crashing and burning or support problems popping up, it’s not always easy to figure out a clear and straightforward way to release code that’s both legally sound and technically solid. Standard escrow “release events” usually cover things like bankruptcy, major support failures, and situations where intellectual property is transferred without proper protection. If you’re interested in this topic, take a peek at this link here. You might find it pretty insightful!

Operational and financial risk compounds quickly

We're really missing the boat on some key exchange and partner integrations here since we can't verify those contracts down to the last byte on-chain. Security teams are rejecting any deployments that can’t be verified. So, when you're working with Sourcify and Etherscan, they want those exact metadata and source hashes. But here's the thing: if you flatten your sources, it can totally throw those hashes off. If you're interested in digging deeper into that topic, you can find more information here.

We're seeing a lot of redlines in the MSA right now because some IP and licensing stuff isn’t crystal clear. Unfortunately, that's causing our product roadmaps to slide back by a quarter or even two. Nowadays, it’s really important to ensure that everything lines up with SPDX and that you're mapping to OSI-approved licenses. It’s just a smart move when you're rolling out products in the enterprise space! If you want to dive deeper into SPDX, you can check out more info here. It's a great resource!
We've got some pretty expensive rework to tackle as well. If teams don’t have deterministic builds, like specific versions of solc, EVM targets, and optimizer runs, they can’t recreate the exact same bytecode after making an upgrade. So, we’re basically stuck in a “redeploy-and-migrate” scenario now, which isn’t as easygoing as the “verify-and-operate” approach we were hoping for. Just a heads up: Solidity actually adds a metadata hash (like IPFS or Swarm) right into the bytecode. So, if you don’t make sure to save and publish that, you could end up losing track of the chain of custody. It’s super important! If you want to dive deeper into this topic, check it out here. There's some great info waiting for you!
Plus, ZK systems can end up being single points of failure. If we happen to misplace the proving keys or setup notes, we’ll need to regenerate and redeploy the circuits. Unfortunately, that could mean we’d have to deal with some governance and UI migrations, which isn’t exactly ideal. The Ethereum KZG ceremony really shines a light on how big and detailed modern MPC setups are striving to be. If you want to dive deeper into it, feel free to check it out here.
Finally, if you don’t have SOC 2-aligned controls, SBOMs, and SLSA-level provenance in place, procurement is going to hit a brick wall. This stuff is crucial for tackling third-party risk and meeting those EO 14028 requests. If you're curious to dive deeper into this, be sure to head over to NIST for all the details. They’ve got some great info waiting for you!

7Block’s “Own, Verify, Operate” handoff methodology

We design everything with “transferability under change” in mind. That means you get to own the code entirely, so you can run it however you like. And don’t worry; we’ve got all the proof you need to satisfy your auditors!

1) IP and Licensing Architecture (Week 0-2)

SPDX-First Repository Policy: Make sure every Solidity file starts with the correct SPDX identifier--whether that's MIT, Apache-2, or whatever you're working with. It’s just a good practice! It's either going to be a big fat zero or marked as UNLICENSED, all based on how you feel about licensing. Hey there! Just a heads-up: if a merge doesn't have an SPDX header, we're going to have to block it.
If you’re looking for more info, you can find all the details right here.
License Bill of Materials: We put together a handy SPDX-based inventory that shows all the third-party code we're rocking--whether it’s in Solidity, JS/TS, or Rust. We always make it a point to highlight any non-OSI or “fair-code” variants, such as BSL, so they can be looked over by our legal team. The SPDX license list is really handy! It gives you those standard short IDs and OSI markers that you might need. If you're looking for it, you can check it out here.
Keeping an Eye on Business Source License: If we come across any upstream components that are using the BSL, we'll make a note of the Change License and the Change Date. We'll also double-check any commercial licensing obligations we need to be aware of. This way, you won’t accidentally run into any surprise copyleft or usage rules. If you want to dive deeper, check out MariaDB!

2) Deterministic Solidity Builds with Byte-for-Byte Verification (Weeks 1-3)

Alright, so first things first--we gotta make sure we set the solc version, EVM target, optimizer runs, and metadata settings in our CI. It's super important to nail this down! This is what allows us to put together the Standard JSON input, the raw metadata, and the compiler artifacts that Sourcify and Etherscan rely on. Sourcify makes life easier by matching up metadata hashes and source hashes--no need to flatten anything! If you want to dive into the specifics, just head over here.

Next on our agenda is focusing on being deployable without getting locked into one specific vendor. We'll make sure to keep an eye on CREATE2 salts for those predictable addresses whenever it totally makes sense to do so. And hey, we’re going to put the specific initcode and salts directly into the deployment manifest for you. If you're curious to learn more, just check it out here!
And just to wrap things up, we’ve got some cool automatic verification jobs running with Etherscan and Sourcify for those post-deploy checks. If the on-chain bytecode doesn’t line up with what we created, the pipeline is going to get really upset and fail. If you want to dive deeper, take a look at the common verification errors here. It’s a handy resource!

3) ZK Asset Management (Circuits, Keys, Ceremonies) (Week 2-5)

Circuit Artifact Catalog: We’re in the process of putting together a cool collection of artifacts, including things like R1CS and WASM. You’ll find everything you need neatly packaged for each release: a zkey for proving, a verification key in JSON format, a Solidity verifier, and some handy witness tools. Plus, we’ve included checksums to keep everything organized and secure! We follow the standard Circom/Groth16 process, so we've got you covered from Powers of Tau all the way through the Phase 2 steps. Plus, we’ve got some handy scripts ready that will make it super easy for you to reproduce everything. Hey, if you want to dive deeper into the topic, just head over to docs.circom.io for all the info you need!
Keeping tabs on custody and provenance: We're on top of things when it comes to our proving keys and the outputs from our trusted setup. We’re making sure they’re properly versioned, checked for accuracy with checksums, and securely tucked away in escrow. On top of that, we throw in some ceremony docs and examples for reference--like Ethereum’s KZG ceremony practices--to give everyone a clearer idea of what's expected when it comes to multi-party integrity and making sure things are reproducible.
If you're looking to explore this topic further, check out blog.ethereum.org. They’ve got some great insights that you won’t want to miss!
Compatibility notes: Just a heads up, so we don’t run into any issues with mismatched proving stacks while passing things around, we're keeping a record of the curve/backend assumptions we’re working with (think BN254/BLS12‑381 and the differences between Circom and Arkworks reductions). If you want to dive deeper into this, just check out our repository at github.com. It's all there waiting for you!

4) Supply Chain Evidence (SSDF, SBOM, SLSA) (Weeks 1-6)

SSDF Alignment: We’ll work with you to get your controls in sync with the NIST SSDF 1. 1 practices. This covers stuff like purchase orders and more. Here are five tips to keep your build environments and post-scripting secure:

3. 2 for software provenance. On top of that, we’ll collect all the info you’ll need for those auditors and big clients. Check it out here.

SBOMs: We're really into creating CycloneDX SBOMs for all sorts of components, whether they're on-chain or off-chain. This includes everything from contract packages to SDKs and frontends. You'll get all the key details you need, like version info, licensing stuff, and data about its integrity. CycloneDX is officially recognized as ECMA‑424, and it does a great job of handling things like SBOM, VEX, and attestations. More info here.
Provenance and Signing: We’ve got you covered! We’ll include SLSA provenance attestations and sign your container and artifact releases with Sigstore Cosign. Whether you prefer keyless/OIDC or want to go with KMS-backed options, we can make it happen. What this really means is that you'll have a way to track build-to-binary provenance that your procurement teams are sure to love. Dive deeper here.

5) Repository Governance and Enterprise Controls (Week 0-Ongoing)

GitHub Enterprise Guardrails: Don’t forget to set up your CODEOWNERS for those essential reviews! It's also super important to put branch protection in place, along with rules like requiring signed commits, maintaining a clean linear history, and making sure you have those necessary status checks ready to go. Hey, just a quick note--make sure you’ve got 2FA and SSO set up; they're really essential! Also, you’ll be glad to know that audit logs are continuously feeding right into your SIEM, and they've got retention that far outlasts what you can see in the UI. Just thought I’d share that! If you want to dive deeper into this topic, just click here!
Secrets/Code Scanning: Be sure to really emphasize the importance of secret scanning and code scanning policies. It’s crucial to keep things secure! This way, you can keep those annoying credentials and any insecure patterns from sneaking into your repositories.
If you want to dive deeper, just check out this link: docs.github.com. It's packed with all the info you need!

6) Escrow that Actually Works in Production (Week 3-6)

What’s in Escrow: It’s way more than just throwing in some “source code.” We're looking at including a bunch of things like build scripts, toolchain pin files, deployment manifests, and environment snapshots. Oh, and we can’t forget about ZK assets, which are basically the proving/verification keys and setup transcripts. Plus, we’ll have admin scripts and runbooks in the mix too! It’s pretty much everything you need to keep everything flowing just right.
Release Events: We’ve put in place some solid legal triggers that activate when certain situations arise. This can happen if there's insolvency or bankruptcy, if there are major support issues after a grace period, or if someone goes ahead and transfers intellectual property without the right safeguards. These really fit right in with what you typically see in the industry. Also, we’ll walk you through the verification steps to make sure the escrow materials match up with the on-chain bytecode and the metadata that’s been published. Hey, if you’re looking for more info, feel free to check this out: here’s a helpful link. You’ll find some great insights!

7) Handoff and Continuity (Weeks 4-8)

“Operate Without Us” Drills: It’s a great idea to get your team rolling with some practical drills! Think along the lines of reproducible builds, contract verification, key rotations, and practicing disaster recovery. Engaging in these activities will really help everyone get the hang of things! It's all about getting your team prepped and ready to hit the ground running when the moment arrives.
Documentation Deliverables: Hey, just a quick reminder not to overlook those crucial documents! You'll definitely want to have things like architecture decision records, your SBOM along with SLSA provenance, and deployment manifests (don't forget to add in those chain IDs for EIP‑155). Also, make sure you're covering key management details and runbooks for any governance upgrades. It’s all super important! If you want to dive deeper into this, feel free to check out more info right here: eips.ethereum.org.

Solidity verification that holds strong even when upgrades roll in.

Hey, don’t forget to pin the solc 0! 8. Make sure to explicitly work on the 3x series and keep the standard JSON input in version control. Hey, just a quick reminder--when you do an upgrade, make sure to jot down a migration note and grab a new set of artifacts. It’ll save you some hassle later on! Publishing the Solidity metadata hash on IPFS and adding a link to it in your release assets is definitely a smart move! It makes it easier for everyone to access and verify your work. This makes it super easy for anyone to grab the metadata that goes along with your on-chain bytecode. (docs.soliditylang.org).

Check out OpenZeppelin Contracts and make sure to note down the version you’re using (something like version 5). 3 or 5. 4 series). Just a quick reminder: make sure to add the license and commit hash to your SBOM. This way, auditors can easily track down any CVE exposures. It's a good habit to get into! (contracts.openzeppelin.com).

ZK Proving Key Custody Approved by Auditors

If you’re diving into a Circom/Groth16 circuit, let me give you the scoop: First things first, let’s take a look at R1CS and WASM.
Go ahead and create your Powers of Tau and make your contributions for Phase 2.
After that, create your own. zkey and verification key. Hey, just a quick reminder--make sure you commit those checksums and export a Solidity verifier!
When you’re done, make sure to tuck away all the artifacts and any scripts into escrow. If you want to dive deeper, just take a look at the Circom documentation. It's got all the info you need!

Don’t forget to put together a quick "ceremony dossier." It should cover who was there, when it all happened, how you created your entropy, and some info on the environmental controls you had in place. The Ethereum KZG ceremony really showcases how important it is to keep good records of contributions and processes. This kind of transparency goes a long way in building trust that lasts. If you’re looking to really dig in, check out the Ethereum blog. It’s got some great insights!

3) Deterministic Deployment Playbook

Hey, just a quick reminder: don’t forget to write down the CREATE2 salts and initcode for any counterfactual deployments you’re working on! It’s super important to keep track of those. Hey, just a quick reminder: make sure to include the derivation formula and the preimage elements in the handoff pack. That way, the legal team can easily verify the address determinism. Thanks! Take a look at it here: eips-wg.github.io. You won’t want to miss this! Make sure to snag the chain ID and network parameters from your deployment manifest, following the guidelines laid out in EIP-155. Taking this step is super important because it helps avoid any replay problems and confusion between different environments. If you're looking for more info, check it out here: eips.ethereum.org.

4) Supply Chain Evidence That Unblocks Procurement

For every release, make sure to export those CycloneDX SBOMs and go ahead and sign them with Cosign. Don't forget to add SLSA provenance attestations! They should really cover the builder's identity, the source commit, any dependencies, and the parameters that make everything reproducible. If you want to dive deeper into it, check it out here.
You know what? It’s actually really smart to align your development lifecycle with the SSDF 1.

A handy list of tasks all in one spot so buyers can quickly check them out whenever they need. Just a quick reminder to make sure you emphasize the importance of secure build environments in your notes!

and provenance (PS.

3. 2). If you want to explore further, take a look at the details here. You'll find some great info!

Emerging best practices we implement by default

“Exact-match” verification as a deployment checkpoint: So here’s the deal--your Continuous Integration (CI) process is going to hit a snag if either Sourcify or Etherscan can’t find a match between the bytecode and the metadata or inputs you’ve provided. This way, you can avoid any last-minute scrambling for information later on. (docs.sourcify.dev).
SPDX + License Policy Linting: We’ve hit the pause button on any merges that attempt to slip in licenses that haven't been approved.
Hey there! Just a quick reminder that all your source files should include those SPDX headers. And whenever you’re working on a pull request, we create license diffs to help our Legal team spot any changes right from the get-go. It’s a smooth way to keep everything in check! (spdx.org).
SLSA-attested releases signed with Sigstore: Imagine this as a cool method for signing your containers and artifacts without needing a physical key. It’s all about creating a secure identity while keeping everything transparent with verifiable logs. Pretty neat, right? Pretty slick, right? (docs.sigstore.dev).
ZK Artifact Escrow with Integrity Checks: So, here’s the deal: we’re looking at escrowed proving keys and verifiers that are paired up with SHA-256 checksums. It’s all about making sure everything stays secure and trustworthy! When we talk about release validation, we go ahead and rebuild the verifiers to double-check everything. We ensure that the on-chain verification holds up by using the escrowed verification key. It's all about making sure things are legit! (docs.circom.io).
GitHub Enterprise rulesets and CODEOWNERS: These tools are great for keeping your projects organized. They help ensure everyone knows their roles and responsibilities, while also giving you a clear record of changes made. And hey, you can totally stream those audit logs to your SIEM for extra security, keeping everything safe beyond just what's visible in the UI. (docs.github.com).

What you get from 7Block (deliverables)

IP/License Packet: This part covers your SPDX license inventory, any exceptions to policies you might have, and notes that are all set for your legal team to review.
Build + Verify Bundle: In this section, you’ll discover some standard JSON inputs, the specific versions of Solc we’ve pinned, along with our EVM/optimizer settings. We’ve also included some really useful automated scripts to help you with verification on Sourcify and Etherscan. Check it out here.
ZK Package: This package is loaded with all sorts of goodies! You’ll find circuits, R1CS/WASM, proving and verification keys, notes from ceremonies, Solidity verifiers, and a bunch of test vectors. It’s a comprehensive toolkit for diving deep into ZK technology! If you're curious and want to explore further, check out the details here. It's a great resource!
Security + Compliance Evidence: We've pulled together the CycloneDX SBOM, SLSA provenance, SSDF mapping, and signed release artifacts - everything’s ready to go! You can check out more details here. It's definitely worth a look!
Escrow Kit: This kit includes everything you need--like the full source code, definitions for the build pipeline, environment manifests, and keys (following the policy guidelines). Plus, it comes with a runbook that’s been put through its paces for release validation, which covers all the usual release triggers. Curious to dive deeper? Check out escrowlondon.com for more info!

GTM metrics we commit to in pilot programs

We're giving a big boost to our enterprise security reviews, slashing the time by about 30-45%! Gone are the days of wrestling with those annoying questionnaires. Now, we're rolling out a signed SBOM and SLSA provenance bundle with every build we ship. How cool is that? Before we roll out anything into production, we always take the time to do a complete, 100% byte-for-byte contract verification on the networks we support in our continuous integration process. It’s just a crucial step for us to ensure everything runs smoothly! We've taken measurements across our pilot groups. Hey, just a heads up! If we ever find ourselves in the middle of a disaster simulation, we can get our build and verify capability back online using the escrow materials in just a day. And the best part? We won’t even need 7Block access for that!
As far as licensing goes, we're all set! We have zero unresolved license exceptions as we head into go-live. Thanks to our PR-level license diffs, we’ve been able to slash the Legal review process from weeks down to just a few days. It’s a game changer! Here’s a neat little fact: any engineer--yeah, not just the original creators--can whip up a ZK proof using the escrowed keys and get it through on-chain verification in roughly 90 to 120 minutes. We’ve got this info straight from our runbooks, so you know it’s solid!

How we align to your outcomes

Procurement and compliance: Don't worry, we've got your back! We've got everything you need, from SOC 2-aligned evidence to SSDF mappings, plus all those traceable artifacts that your auditors will absolutely appreciate. Take a look at this link: aicpa-cima.com. You'll find some interesting information there!
Engineering and Security: Our repository and pipeline are all set to go! We're talking about deterministic builds, so you can count on everything being the same every time. Plus, we've got reproducible verification and signed artifacts that you can actually trust. It's all about giving you that extra peace of mind!
Legal and Risk: We’ve got your back when it comes to handling redlines. We make the whole process super easy! We take care of your license hygiene with the help of SPDX, making sure everything's in order. Plus, we don’t just store a bunch of tarballs; we keep the whole tested operational setup secure for you. It’s all about making your life easier! Check it out here: spdx.org. You won’t want to miss it!

Where 7Block plugs in

Get your project rolling with our fantastic custom blockchain development services! Plus, don't miss out on exploring smart contract development - it's a game changer! Enhance your platform with our comprehensive security audit services so you can keep everything running like a well-oiled machine. You can easily link up with your existing legacy systems using our blockchain integration services. Plus, take your user experience to the next level with our awesome dApp development. It's all about making things run smoother and better for you! Got cross-chain needs? It's a good idea to think ahead! You can ensure smooth sailing with deterministic addressing and message verification. Check out our cross-chain solutions to get started, and don't forget to look into our bridge development for a seamless experience.

Summary for executives

It's not just a matter of “who owns the code,” but also “who’s actually going to be able to run the system on Monday morning after all those changes.” We’ve set up our handoffs to be super clear and easy to follow, so you never have to worry about audits. You’ll be able to recreate processes on your own and meet any legal requirements without a hitch. This way, you’re totally in control, both as the owner and the operator.

Get ready to see some great returns! We’re talking fewer redlines, builds that are reliable from the get-go, and a solid continuity plan that keeps Security, Legal, and Procurement in the loop and satisfied.

Book a 90-Day Pilot Strategy Call

Are you excited to elevate your project? Let’s jump right in and sketch out a solid plan that’ll help you get there! Hey there! Find a time that suits you, and let’s have a chat about your goals, any challenges you’re facing, and how we can really make some progress in the next 90 days. Just click the link below to schedule your call. Looking forward to it!

Book Your 90-Day Pilot Strategy Call! Let’s get started!

Cited References

Hey there! Curious about Solidity's SPDX header requirements or how to add some metadata to your code? You've come to the right place! Check out this link for all the details: Solidity Documentation. Happy coding!

Sourcify/Etherscan Verification: Want to dig into exact matches and understand how metadata moves around? This will definitely help! (docs.sourcify.dev).
SPDX License List and OSI Markers: Check out this spot for a handy list of licenses, plus a little info about the BSL. (spdx.org).

Hey there! If you're getting into secure software development, NIST has some great suggestions for you to check out. Look into SSDF, CycloneDX (ECMA-424), SLSA, and Sigstore Cosign--they're all worth your time! (nist.gov).

GitHub Enterprise Controls and Audit Logs: Curious about code owners? GitHub has a great breakdown that makes it super easy to understand! Check it out! (docs.github.com).
Circom/Groth16 Workflow: If you're curious about the KZG ceremony and how to keep track of provenance, be sure to take a look at the guide linked here. It's super helpful! (docs.circom.io).
Understanding CREATE2: Let’s take a moment to dive into EIP-155 and see how chain IDs are woven into deployment manifests. (eips-wg.github.io).
Escrow Release Events: Curious about how release events and clauses work in software escrow agreements? Check out this awesome resource that breaks it all down for you! (escrowlondon.com).