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

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

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

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

• Link both a Terms page and a Privacy Policy page from the homepage, or list them in sitemap.xml.
• We check that the pages exist. We do not read or assess their content.

How we check: We look at homepage links, sitemap.xml and common paths. 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.