Metaplex

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

• If no more tokens will ever be minted, revoke the mint authority. It then reads as met.
• If minting must stay possible, move the authority to a multisig (threshold 2 or more, time lock) or a DAO and publish that address on your site.

How we check: We read the mint 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.

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

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

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