How we independently verify and sign every Arkis release

How we independently verify and sign every Arkis release

This is the Spearbit side of a joint write-up with Arkis. For how they rebuilt the pipeline that feeds our review, read "How we built a verifiable release cycle at Arkis."

Institutions lend real capital into Arkis, and that capital sits behind a set of smart contracts. When the stakes are that high, being told the contracts were audited is thin comfort. What a lender actually needs is confidence that the code running on-chain is the exact code that was reviewed, with nothing changed on the way to deployment.

For a long time, an audit could not give them that. A review looks at the code at one commit and produces a report. What gets deployed is the end of a longer process, where dependencies are pulled in, artifacts are compiled, and deployment scripts run. The report describes a single moment, and the deployment sits at the end of a chain the report never sees. The reader is left trusting that the version that shipped still matches the version that was read.

Arkis set out to close that gap, and doing so changed what our review produces. We no longer hand over a document and step away. We sign the exact build that is going on-chain, and that signature is a required approval before it can ship.

We sit at the third link in the chain

Arkis seals each build into an immutable image that carries a build attestation: a record of what the bytecode is, where and when it was built, and that it came from their official pipeline. That is the second link. Our attestation is the third. When the sealed image reaches us, we review the image itself, not a branch or an archive of source. The image is the thing we examine and the thing we sign.

First, prove the artifact is the code

The assigned auditor pulls the sealed image, reads the bytecode inside it, and then compiles the source independently on their own machine to check that the result is byte-for-byte identical. This works because the build is deterministic: the same source and toolchain produce the same bytecode every time, so any difference is a real difference rather than build noise. If the two do not match, the review stops, because the artifact and the source have parted ways and there is nothing worth reviewing until that is explained. When they match, we have proof, before any security analysis begins, that the code we are about to review is the code that will deploy.

The review the signature stands on

From there, the security review runs against that verified bytecode. This is the part that takes the time and the judgment: reading the contracts, modeling how they fail, finding the issues, and working through each one with the Arkis team. Some findings get fixed. Others get discussed and accepted with reasons on the record. That conversation resolves before anything is signed, and the auditor issues an attestation only when they are satisfied the release is sound.

The signature is a named person, recorded in public

When the review is done, the auditor issues a signed attestation, the next signed record in the chain after the build. It is deliberately personal. The signature is the individual auditor's, bound to their own verified identity rather than a firm-level stamp, and it says one engineer reviewed this exact bytecode and is willing to be named as the reason it shipped.

We and Arkis use the Sigstore ecosystem to make that signature verifiable. Fulcio issues a short-lived certificate that ties the signature to the auditor's verified identity, so there is no long-lived signing key to store, leak, or rotate. Cosign produces the signature and verifies it later. Rekor writes it into a public transparency log.

Anyone can check it

This is the part that matters most to the people relying on the protocol. Our sign-off is not a private assurance passed between Arkis and us. A lender, a partner, or a governance participant can pull the deployment artifact, run a verification against the public transparency log, and confirm for themselves that a valid Spearbit attestation exists over that exact bytecode, including who signed it and when. They do not have to take our word, or Arkis's, that a review happened. The proof travels with the code, and it is open to everyone.

Mario, who runs incident command at Spearbit and signs these releases, puts it plainly:

"We act as an independent attestor in Arkis's release process. Once we've audited a release, we cryptographically sign the exact build that's set to go on-chain, binding our review to that specific code rather than a report that sits to the side. Our signature is one of the required approvals: the deployment won't proceed without it, and the check is enforced automatically rather than left to manual trust. Anyone can independently verify our attestation is present and valid. The point: it's not 'trust us, it was audited.' Our sign-off travels with the code all the way to deployment, and it's verifiable by everyone." - Mario, Head of Incident Command, Spearbit

If the auditor is not satisfied, they do not sign. A missing Spearbit signature is not a loose end to tidy up later. The check is enforced automatically: the pipeline and the governance board will not promote a release without it, and its absence is treated as an incident to investigate.

What this changes

Downstream, our attestation is one of the approvals the Arkis infrastructure and governance board require before a release can become effective, and the requirement is enforced by the system rather than left to someone remembering to check. A report can be filed and overruled. A missing signature stops the line. That moves the security reviewer from someone who hands over an opinion to someone whose sign-off is load-bearing. For the people whose capital depends on the system, the result is concrete: they can verify the provenance of the code running on-chain themselves, end to end.

The model also travels beyond Arkis. The hard part of software supply chain security, in Web3 and well outside it, has always been connecting a specific review to the specific artifact that ships, in a form a stranger can verify. A reproducible bytecode, an independent named attestation, and a public transparency log are a workable answer, and other protocols and the firms that review them can adopt the same pattern.

For the build pipeline, the SLSA foundation, and how the sealed image is produced, read Arkis's companion article here.