How we enforce every Arkis release

We have already shown how we build and attest every Arkis release: a sealed Docker image carrying the compiled bytecode and a chain of cryptographic signatures from everyone who built and reviewed it. Now we want to talk about enforcement - how we check those attestations at every step and block unattested code from reaching production. For the funds lending through Arkis, enforcement is the difference between being told the system is safe and being able to check it. The code their capital depends on cannot change unless independent parties verify and sign it, and every step leaves a record anyone can inspect.

The release path is built as a funnel of independent layers. A release starts with a single developer, the most vulnerable point in any software organization. Every step toward production adds a layer that verifies it independently: the build infrastructure and external attestors first, then a group of approvers inside Arkis, separate from the team that built the release, then a governance board operating on infrastructure Arkis does not control. By the time a release can touch client collateral, several independent parties have verified and signed it, and if it fails verification at any layer, it stops there.

Promotion of new smart contract release

The release is verified at multiple steps on its way to production, each time independently and by a different stakeholder. Each verification examines the provenance of the release: the record has to be complete, tie back to the builder who produced it, show no tampering during the build, and carry a security specialist's resolution to promote the new version.

Layer 1: policy checks the attestation before code runs

A release enters our infrastructure as the sealed Docker image. In our Kubernetes cluster, Kyverno policies verify the attestation automatically, checking the image origin, the signature chain, and the quorum of attesters. An image that is unattested, or attested by the wrong identities, is rejected by policy before it can run.

Deploy new smart contract & propose upgrade on-chain

Once the new version is deployed onchain, Arkis submits the upgrade proposal to the multisig upgrade contract and receives the release identifier used in every later verification.

Layer 2: separation of duties inside Arkis

Deployed contracts do not upgrade automatically. An upgrade starts as a proposal to our multisig upgrade contract, and the proposal itself is controlled by an MPC wallet. The blockchain team verifies the release and constructs the proposal transaction. It then goes through that wallet, where the security team holds approval rights, and each approver independently runs the same verification before signing. This structure means the team that builds a release cannot ship it on its own. The proposal reaches the chain only after enough approvers have signed, and once submitted it emits an identifier for the release, which the governance board later uses to identify and verify the release.

Layer 3: the governance board enforces from outside Arkis

The governance board is the layer on top, and its value is that it shares none of our infrastructure. A board member operates on their own custody, their own wallets, and their own processes.

To verify a release, a board member runs the verification script on their own machine, with only publicly available information and the release image attested by the auditors. The script first receives the release identifier, then fetches the release proposal from the governance contract onchain. The proposal contains the list of contracts to be upgraded and their addresses. The script then opens the release image and recomputes the release identifier locally, checking the proposal's integrity. Next it reads the file with the attestation details, which lists the bytecode hash of every contract in the release. For each upgrade, the script fetches the new implementation's bytecode from the chain, hashes that bytecode, and compares the hash against the one recorded in the attestation. Every hash must match, along with the image's signature chain and the full set of required attestations.

Nothing in this procedure requires access to Arkis systems or permission from anyone at Arkis: the script, the image, and the chain are all a counterparty needs. The upgrade proceeds only after the board's signatures are onchain.

The layers do not share failure modes, so an attacker who compromises any one of the layers, including Arkis, gains little - the next layer independently re-verifies everything the compromised layer produced, so shipping malicious code would take simultaneous control of too many independent systems. The governance board completes this design. Counterparties do not have to trust Arkis, because anyone can run the same checks and see the result on their own.

Read the announcement: Arkis Establishes an Institutional Governance Board with Spark. For the attestation part of the process: How we built a verifiable release cycle at Arkis.