Invariant Labs

• If the program is final, revoke the upgrade authority. It then reads as immutable.
• Otherwise move the authority to a multisig or a DAO. For a multisig, use a threshold of at least 2, add a time lock, and do not keep a separate config authority that can change members without a vote.
• Publish the multisig or DAO address on your own website so the page and the on-chain account can be tied together.

How we check: We read the program’s upgrade authority on Solana (public RPC) and recognise Squads, Serum-style multisigs and SPL Governance accounts. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Build the program reproducibly from your public source with the Solana verifiable-build tooling (solana-verify).
• Submit the build to the registry so that it appears in the OtterSec registry (verify.osec.io). The check reads that registry; it does not rebuild anything itself.

How we check: We ask the OtterSec build registry (verify.osec.io, a third party) whether the deployed program matches a build from the public source. We report what the registry says; we do not rebuild or vouch for anything ourselves. Any registry entry that matches the program’s current on-chain hash counts, not only the registry’s default entry (method 0.2.5). This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• If the program is final, revoke the upgrade authority. It then reads as immutable.
• Otherwise move the authority to a multisig or a DAO. For a multisig, use a threshold of at least 2, add a time lock, and do not keep a separate config authority that can change members without a vote.
• Publish the multisig or DAO address on your own website so the page and the on-chain account can be tied together.

How we check: We read the program’s upgrade authority on Solana (public RPC) and recognise Squads, Serum-style multisigs and SPL Governance accounts. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Build the program reproducibly from your public source with the Solana verifiable-build tooling (solana-verify).
• Submit the build to the registry so that it appears in the OtterSec registry (verify.osec.io). The check reads that registry; it does not rebuild anything itself.

How we check: We ask the OtterSec build registry (verify.osec.io, a third party) whether the deployed program matches a build from the public source. We report what the registry says; we do not rebuild or vouch for anything ourselves. Any registry entry that matches the program’s current on-chain hash counts, not only the registry’s default entry (method 0.2.5). This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Link each audit report from an official page: your docs, your website or an audits folder in your GitHub repository.
• Tell us the page through the corrections form so it can be added. The check only confirms that the document is reachable. It does not assess the audit’s quality or whether it covers the current code.

How we check: Audit links come from official pages found for the project, not from a search of the web. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Add a standard licence file (for example Apache-2.0 or MIT) that GitHub recognises.
• Custom or source-available terms are shown as partial: we do not judge them.

How we check: We read the licence field GitHub detects. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

Nothing for the project to do. Our checker could not read the source this time, so the check is “Not read”: no points are lost. It is tried again at the next run. If you think the data behind it is wrong, send a correction.

• Publish a text file at https://your-domain/.well-known/security.txt (or /security.txt) with a Contact: line, for example Contact: mailto:security@your-domain.
• RFC 9116 also asks for an Expires: line. We look only for Contact:, but add Expires: too so the file stays correct.

How we check: We fetch the two standard locations over HTTPS. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Link your bug bounty (for example an Immunefi, HackerOne or Cantina page, or a /bug-bounty page of your own) from the homepage, the sitemap or your security.txt.
• “Unknown” here means we found no link. It does not mean you have no programme.

How we check: We look at the homepage links (also as rendered in a browser), sitemap.xml and security.txt, and at Immunefi’s public list for on-chain security.txt names. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Embed a security.txt block in the program with the solana-security-txt crate: name, project_url, contacts and policy. Redeploy to publish it.
• This also tells us which programs belong to you, and which are shared programs that do not.

How we check: We read the program account on Solana (public RPC). This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• List your official program addresses on a page of your own domain (for example a docs page called “Addresses”). A list only on GitHub reads as partial, and one only on a third-party page as not met.

How we check: We use the pages the project itself publishes. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Name the legal entity behind the project in the terms or privacy text, for example “Example Labs Ltd” or “Example Foundation”.
• We do not check a company registry.

How we check: We read the terms and privacy text and look for a company-style name. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Send these four response headers on your homepage: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and X-Frame-Options.
• The check looks only at whether each header is present, not how strict it is.

How we check: We read the headers of one homepage request. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Nothing to configure: a domain registered more than a year ago reads as met, 90 days to a year as partial.

How we check: We read the registration date from the public domain registry (RDAP). This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.

• Publish your official program addresses on your own domain and link your GitHub organisation from the website, so the three can be tied together.

How we check: We compare what the project’s own pages say with the on-chain addresses and the GitHub organisation. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score.