Don’t trust us. Check the release.

What each release publishes

A signed statement names the exact commit we deploy, its source tree and every pinned dependency, by their hashes. Beside it: an SBOM listing every package in the release, what our gate checked (build, tests, vulnerability and lint scanners), and the measurement of the enclave that holds the agents’ keys. The container images are checked by our own production servers before they run, and their digests are not published.

The code that runs on chain is published in full: the Solidity contracts, the records of where they are deployed, and our agents’ ERC-8004 cards. The rest of the repository stays private, and only its hashes are published. That is a choice, and we would rather state it than blur it.

Reviewed by autonomous agents, every time

Before a release is signed, several AI agents review everything that changed since the previous release: one looks for ways money could move when it should not, one for plain bugs, one for what could break in deployment, and one for the on-chain code when it changed. A second, independent agent then tries to refute every finding, and marks it confirmed, plausible or rejected.

The signing script refuses to sign while a confirmed high-severity finding is unresolved, meaning neither fixed nor acknowledged in writing in the repository. The signed statement carries the review’s summary: the findings by severity and how many highs are unresolved. The full report is not published, because it describes private code; its hash is signed, so anyone who is later handed the report can check that it is the one this release was signed with.

What that proves: the review ran on that release, with the models the statement names, and found what its summary counts. What it does not prove: that the code has no bugs. A model can miss things. It is evidence, not a guarantee, and anyone who tells you an AI review is a guarantee is selling something.

One link that does not change

Each of our agents’ ERC-8004 cards names this list as its “verification” service. The cards and the chain stay the same from release to release; the list grows by one entry each time.

Releases

The same list, machine-readable: https://defiloops.com/verify/releases.json

How to check a release

1. Fetch a bundle by its CID and check the signature with cosign, using one of the keys below:

   ipfs get <cid> -o bundle && cd bundle
   cosign verify-blob --key keys/<fingerprint>.pub \
       --bundle statement.sigstore.json --insecure-ignore-tlog=true statement.json

2. Check that the SBOM is the one that was signed (the hash must equal the statement’s sbom.sha256), and every other file:

   sha256sum sbom.spdx.json
   sha256sum -c SHA256SUMS

3. Recompute the bundle’s CID yourself. It must equal the one listed here:

   ipfs add -r -n -Q --cid-version=0 bundle

Our release keys

Each bundle carries the public keys, but a bundle cannot vouch for itself: compare their fingerprints with these. The first lives on a hardware key and cannot be copied off it; the second is an offline backup.

• sha256:0f94ff99b58ff464bf002bb431c575c37c81b019a7878d1c1728087ae77e6921
• sha256:392431900b5e9b16f93939b5e7098c15f41103a5e53a1c0c8e4c02b3c5824e6d