Claim the page for Marinade

Claiming is free and takes about a minute. It proves that your team controls the project’s upgrade authority, official domain or GitHub organisation. You can then add your own statements and respond next to any check, get the embeddable badge and ask for unlisting. Claiming never changes the automated score, and we do not review your statements.

A. Sign with your wallet

An off-chain message signature. It sends no transaction, costs no SOL and gives no access to funds. It works for the address that holds the upgrade authority of a listed program, or a member of the multisig / DAO council that holds it.

Checking who can sign for this project on-chain…

Advanced: sign with another tool

Text to sign (exact) Signing addressSignature (base58)

B. Add a DNS record

Works for any project with an official domain, i.e. one linked from the project's own listing, GitHub or on-chain security.txt. The record must stay in place.

Domain

C. Publish a file

Publish one line of text where only the project can write: on your own website, or in a repository of your GitHub organisation. That proves control, because nobody else can put a file there. The file must stay in place.

What goes in the file

A text file with exactly one line, for example:

recheckable-claim=marinade:<your one-time code>

The line contains only the project's name in our list and a random one-time code. No wallet address, key, password or personal data.
Pressing the button below only shows you your code. It does not change anything, sign anything or send anything. The file is only created if you publish it yourself.
Publish it within 7 days. Keep the file in place afterwards: if it is gone for 14 days in a row, we ask you to claim again.

On your website In your GitHub organisation Domain

File: on

It will be fetched from:

The file contains exactly this one line:

GitHub rules

The repository must be public, owned by a GitHub organisation (not a personal account), not a fork and not archived. The organisation must be linked to the project by its listing, its on-chain security.txt, or its website (a link from the homepage, with the website also set on the organisation's GitHub profile).

For the DNS record, two independent public resolvers (Cloudflare and Google) must both show it. For the file, we fetch it over https and show the URL, status and a hash in our records so anyone can open the same URL. We never ask for a seed phrase, a transaction or a payment. Wrong party? Send a correction.

What would show up as met

Open checks for this page, with what each one looks for. The tick boxes are only for you; nothing is saved. This is what the check looks for. It makes no promise about a score or grade, and claiming or paying never changes a score. See all checks.

Who can change the program · Partial
- 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.
Can anyone rebuild the program from the source? · Not met
- 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.
Who can mint the token · Unknown
- 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.
Licence · Partial
- 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.
Security headers · Partial
- 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.
Security contact (security.txt) · Not met
- 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.