Orca

• 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.

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.

• 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 to configure: a deploy more than 30 days ago reads as met, a more recent deploy as partial because the code changed recently.

How we check: We read the last deploy time on Solana. 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 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.

• 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.