How to Verify a Program

This guide is meant to be a reference for developers who want to implement verified builds for their programs on Solana. We will cover what verified builds are, how to use them, special considerations, and best practices to ensure the authenticity of your program onchain.

What are verified builds? #

Verified builds ensure that the executable program you deploy to Solana’s network matches the source code in your repository. By doing this, developers and users can have confidence that the program running onchain corresponds exactly to the public codebase, promoting transparency and security.

The verification process involves comparing the hash of the onchain program with the hash of the locally built program from the source code. This ensures no discrepancies between the two versions.

Info

While a verified build should not be considered more secure than an unverified build, the build enables developers to self verify the source code matches what is deployed onchain. Using the source code, a developer can then validate what the code executes when sending a transaction.

The verified builds pipeline was thought out and is maintained by Ellipsis Labs and OtterSec. For more details, follow the guide in the original verified builds repository as well and the verify build process directly into the Anza tool suite, once supported there.

How does it work? #

The verification process is done by comparing the hash of the onchain program with the hash of the locally built program from the source code. You build your program in a controlled environment using the Solana Verify CLI and Docker. This ensures that the build process is deterministic and consistent across different systems. Once you have the executable, you can deploy it to the Solana network. During the build process a PDA of the verify program will be created. This PDA contains all the data necessary to verify the program. The PDA contains the program address, git url, commit hash and the arguments used to build the program.

Using the data in the PDA everyone can run the verify program command locally and check if the program was built from the provided source code. Then everyone can verify for themselves completely trustlessly or can run their own verify API maintained by OtterSec to provide an easy access point for users to check the verification. You can already see these API calls being used in the Solana Explorer and SolanaFM, among other places.

Why should I use verified builds? #

Using verified builds provides the following benefits:

Security: Guarantee that the program running onchain matches the source code, preventing malicious alterations.
Transparency: Allows other users and developers to validate that the onchain program is trustworthy by comparing it with the public codebase.
Trust: Increase user confidence, as verified builds demonstrate that your program's onchain behavior is aligned with your public code. When building verifiable programs, you minimize risks associated with running unauthorized or malicious code. It also ensures you comply with best practices and give security researchers an easy way to contact you. Also wallets and other tools can allow transactions from your program more easily as long as it is verified.
Discoverability: When you provide a verified build of you program everyone can find your source code, docs, program SDK or IDL and they can also easily contact you via github in case there is an issue.

How do I create verified builds? #

To create verified builds, you'll need to follow these steps:

Summary:

Commit your code to a public repository
Build a verified build in docker
Deploy the verified build
Verify the deployed program against public API

If you verify your program which is not build in a docker container it will most likely fail because Solana program builds are not deterministic across different systems.

Install Docker and Cargo #

Install the necessary tools ensure you have Docker and Cargo installed. Docker provides a controlled build environment to ensure consistency, and Cargo is used for managing Rust packages.

Docker: Follow the steps on the Docker website to install Docker for your platform. Once installed, ensure the Docker service is running following this guide further.
Cargo: If you don’t already have Cargo installed, you can install it by running the following command:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Install the Solana Verify CLI #

The Solana Verify CLI is the primary tool used to verify builds. Solana Verify CLI is currently maintained by Ellipsis Labs and can be installed using Cargo.

You can install it by running:

cargo install solana-verify

If you need a specific version of the CLI, you can pin the version with:

cargo install solana-verify --version $VERSION

If desired, you can install a version directly from a specific commit:

cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2

Prepare project #

To verify against a repository it needs to have a Cargo.lock file in the root directory of your repository. If you only have one program in your repository and a cargo.lock file in your root you can directly go to the next step and build your program.

If your program is in a subfolder and you have a rust workspace you need to create a workspace Cargo.toml file in the root directory of your repository.

You can use this Cargo.toml example as a preset:

Cargo.toml

[workspace]
members = ["program/programs/*"]
resolver = "2"
 
[profile.release]
overflow-checks = true
lto = "fat"
codegen-units = 1
 
[profile.release.build-override]
opt-level = 3
incremental = false
codegen-units = 1

Make sure that your program is in the workspace/members array and that the Cargo.toml of your program has the correct lib name configured.

Info

Important is the lib name not the package name!

Something like this:

waffle/Cargo.toml

[package]
name = "waffle"
version = "0.1.0"
edition = "2021"
 
[lib]
name = "waffle"
crate-type = ["cdylib", "lib"]
 
[dependencies]
solana-program = "2.1.0"

In this repository you can see an example of a workspace with a program in a subfolder. Notice also that when the program is in a subfolder you later need to add this folder as --mount-path to the verify-from-repo command.

In this repository you can find an anchor example. In this repository you can find a native rust example.

With this Cargo.toml file in place you can then run cargo generate-lockfile to create a lock file and continue to building your program.

Building Verifiable Programs #

To verifiably build your Solana program, navigate to the directory containing your workspace's Cargo.toml file and run:

solana-verify build

This will copy your environment into a docker container and build it in a deterministic way.

Info

Make sure that you actually deploy the verified build and don't accidentally overwrite it with anchor build or cargo build-sbf since these will most likely not result into the same hash and though your verification will fail.

For projects with multiple programs, you can build a specific program by using the library name (not the package name):

solana-verify build --library-name $PROGRAM_LIB_NAME

This process ensures deterministic builds and can take some time, especially on certain systems (e.g., M1 MacBook) because it is running within a docker container. For faster builds, using a Linux machine running x86 architecture is recommended.

Once the build completes, you can retrieve the hash of the executable using the following command:

solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so

Deploying Verifiable Programs #

Once you have built your program and retrieved its hash, you can deploy it to the Solana network. It is recommended to use a multi-signature or governance solution like Squads Protocol for safe deployments, but you can also directly deploy with:

solana program deploy -u $NETWORK_URL target/deploy/$PROGRAM_LIB_NAME.so --program-id $PROGRAM_ID --with-compute-unit-price 50000 --max-sign-attempts 100 --use-rpc

A currently fitting low priority fee you can request from your rpc provider for example Quicknode.

To verify the deployed program matches the built executable, run:

solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID

Info

You may have different versions deployed on different Solana clusters (i.e. devnet, testnet, mainnet). Ensure you use the correct network URL for the desired Solana cluster you want to verify a program against. Remote verification will only work on mainnet.

Now you can already get the hash of your program and compare it to your binary hash from earlier if you want:

solana-verify get-program-hash $PROGRAM_ID

Verifying against repositories #

To verify a program against its public repository, use:

solana-verify verify-from-repo -u $NETWORK_URL --program-id $PROGRAM_ID https://github.com/$REPO_PATH --commit-hash $COMMIT_HASH --library-name $PROGRAM_LIB_NAME --mount-path $MOUNT_PATH

Info

While you run the verified build in your program directory, when running verify-from-repo you need to add the --mount-path flag. This will be the path to the folder containing the Cargo.toml that contains your program's library name.

This command compares the onchain program hash with the executable hash built from the source at the specified commit hash.

At the end the command will ask you if you want to upload your verification data onchain. If you do that the Solana Explorer will immediately show your program's verification data. Until it was verified by a remote build it will show as unverified. Learn how you can verify your program against a public API in the next step.

If you want to lock the verification to a certain release, you can append the --commit-hash flag to the command.

Verify against public API #

Finally you can also directly verify the program against anyone that is running the verify API::

solana-verify verify-from-repo --remote -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1

Info

It is recommended to use a payed RPC Url because otherwise you may run into rate limits of the free RPCs. So instead of -um you should use --url yourRpcUrl for a more reliable verification.

The --remote flag sends a build request to the OtterSec API, which triggers a remote build of your program. Once the build is complete, the system verifies that the onchain hash of your program matches the hash of the generated build artifact from your repository.

The default is the OtterSec API.

Make sure to pick yes when you are asked to upload the verification data onchain. This is used by the API to verify that you uploaded the verification data.

You can also trigger a remote job manually by using:

solana-verify remote submit-job --program-id <program-id> --uploader <address>

Where the uploader is the address that has the authority to write to the PDA. That should be program authority in most cases. If your program is controlled by a multisig please continue in the multisig verification part of this guide below.

This will submit a job to the OtterSec API and you can then verify the job status with:

solana-verify remote get-job-status --job-id <job-id>

Once the verification has completed successfully, which may take awhile, you will be able to see your program as verified in the OtterSec API for single programs and in the Solana Explorer, SolanaFM, SolScan and eventually also on the community-run website SolanaVerify.org maintained by 0xDeep and the OtterSec verified programs API and at last in the Verified Programs Dune Dashboard contributing to a more healthy Solana ecosystem.

How to verify your program when its controlled by a Multisig like Squads #

For the remote verification to work you need to write the verification data into a PDA signed by the program authority. If your program is controlled by a multisig you can export this write PDA transaction and submit it through Squads Protocol or another multisig solution of your choice.

1. Build the verifiable program #

First build the program:

solana-verify build

This will build a verifiable build using a docker container using the solana version specified in the Cargo.lock file.

2. Deploy the program #

solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too much
solana program deploy target/deploy/verify_squads.so

For the rest of this multisig guide, we will use an example program ID of 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD.

3. Commit and verify against repository #

Once that is done we commit the project to to github. Here is an example: https://github.com/solana-developers/verify-squads

Optional: See if you can verify locally first (this command uses example program ID 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD):

solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD

Just to make sure your parameters are correct.

4. Transfer program authority to multisig #

If you have not yet transfer your programs authority to the multisig and copy the multisig authority. You need it in the next step.

5. Export PDA transaction #

When you have you program authority locally you are prompted to upload the build data onchain when using the command solana-verify verify-from-repo.

Since you can not do that when you are using a multisig you need to export the PDA transaction manually and then trigger the transaction through Squads.

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader <your program authority> --encoding base58 --compute-unit-price 0

This will return you a base58 transcation. If you want a base64 encoded transaction for use in a transaction inspector, you can use --encoding base64.

P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D

6. Submit transaction through Squads #

Go to the squads transaction builder and import the base58 encoded transaction. Make sure that in the simulation the transaction only has a call to the osec verify program and the computer budget program and nothing else!

7. Submit remote verification job #

Once the transaction to squads was successful you can submit the remote job:

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
--uploader <your program authority>

This is it! You have verified your program against a public repository and submitted a remote job to the OtterSec API. You should be able to see it reflect in the solana explorer and other places now.

8. Updating the program (Optional) #

When you update your program you need to export a new PDA transaction and submit it through Squads again.

Doing an update to the program:

solana-verify build
solana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50

Then transfer that buffer authority to the multisig or directly create the buffer with the authority of the multisig.

solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

9. Export and submit new PDA transaction #

Don't forget to commit your changes to github. Export the PDA upgrade transaction again:

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

Submit the transaction through Squads again.

You can see an example transaction here:

https://solana.fm/tx/4zJ1vK2KToAwxuEYzTMLqPkcebjoi9rdeeyxtEEx9L5Q4vWDA8h6Rr4kPRuRxcV7ZLKMr6qx1LTWb6x3ZpUJaFUW?cluster=mainnet-alpha

Then submit for another remote build:

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

Should result in something like this:

Verification request sent with request id: b63339d2-163e-49ac-b55d-3454c1c2b5b3
Verification in progress... ⏳ [00:18:02] ✅ Process completed. (Done in 18
minutes) Program 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD has been verified.
✅ The provided GitHub build matches the on-chain hash. On Chain Hash:
96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Executable
Hash: 96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Repo URL:
https://github.com/Woody4618/verify-squads/tree/0fb0a2e30c15c51732c0ad5e837975a6f7bbc7ed
Check the verification status at:
https://verify.osec.io/status/6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD Job
url: https://verify.osec.io/job/b63339d2-163e-49ac-b55d-3454c1c2b5b3

Congratulations you have verified your program after a multisig upgrade!

Verify from docker image #

You can also verify your program against a docker image by running the following command:

solana-verify verify-from-image -e
examples/hello_world/target/deploy/hello_world.so -i
ellipsislabs/hello_world_verifiable_build:latest -p
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn

This command loads up the image stored at ellipsislabs/hello_world_verifiable_build:latest, and verifies that the hash of the executable path in the container is the same as the hash of the on-chain program supplied to the command. Because the build was already uploaded to an image, there is no need for a full rebuild of the executable which can take a long time.

The Dockerfile that creates the image ellipsislabs/hello_world_verifiable_build:latest can be found in the ellipsis labs repository /examples/hello_world.

Below is the expected output:

Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network
"https://api.mainnet-beta.solana.com" against program ID
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:
"examples/hello_world/target/deploy/hello_world.so"
 
Executable hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executable
matches on-chain program data ✅

Example verified build #

Here’s an example of verifying an example program with the ID FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv using the source code from this repository:

solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

By default the verify-from-repo command takes the last commit on the main branch. You can also define a certain commit in case you want to continue working on the repository by using the commit-hash parameter: --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Finally you can also directly verify the program against the OtterSec API:

solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --remote --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

The --remote command sends a build request to the OtterSec API, which triggers a remote build of your program. Once the build is complete, the system verifies that the onchain hash of your program matches the hash of the generated build artifact from your repository.

Popular programs that are already verified #

Phoenix #

solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1

Final Output:

Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
On-chain Program Hash: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
Program hash matches ✅

Squads V3 #

solana-verify verify-from-repo https://github.com/Squads-Protocol/squads-mpl --commit-hash c95b7673d616c377a349ca424261872dfcf8b19d --program-id SMPLecH534NA9acpos4G6x7uf3LWbCAwZQE9e8ZekMu -um --library-name squads_mpl --bpf

Info

Notice we needed to specify the library-name because the Squads repo includes multiple programs. We use the --bpf flag because squads_mpl was previously verified with Anchor.

Final Output:

Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
On-chain Program Hash: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Program hash matches ✅

Drift V2 #

solana-verify verify-from-repo -um --program-id dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH https://github.com/drift-labs/protocol-v2 --commit-hash 110d3ff4f8ba07c178d69f9bfc7b30194fac56d6 --library-name drift

Final Output:

Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
On-chain Program Hash: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Program hash matches ✅

Marginfi V2 #

solana-verify verify-from-repo -um --program-id MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA https://github.com/mrgnlabs/marginfi-v2 --commit-hash d33e649e415c354cc2a1e3c49131725552d69ba0 --library-name marginfi -- --features mainnet-beta

Final Output:

Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
On-chain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Program hash matches ✅

Conclusion #

Using verified builds on Solana ensures the integrity and trustworthiness of your programs on the network and allow developers to find your SDKs directly from a Solana Explorer. By leveraging tools like the Solana Verify CLI and Docker, you can maintain verifiable and secure builds that align with your source code. Always take the necessary precautions to use consistent environments, and consider governance solutions for safe upgrades and deployments.

Security + Disclaimer #

While verified builds are a powerful tool for ensuring the integrity of your Solana programs it is not completely trustless in the default setup. The docker images are built and hosted by the Solana Foundation.

Be aware that you are building your project in a downloaded docker image and that your whole setup gets copied into that docker image for building including potentially sensitive information.

If you want to have a completely trustless setup you can build the docker images yourself and host them on your own infrastructure. This way you can be sure that the docker images are not tampered with. You can find the scripts to create your own docker images in the Verified builds repository and you can fork it and run the github actions yourself or validate that they are correct.

Furthermore for the remote verification you are trusting the OtterSec API and the Solana Explorer to a certain degree.

The API or Solana Explorer may potentially display incorrect information if compromised.

If you want to have a completely trustless setup you can run the Verify API yourself or run the program verification locally yourself using the verify-from-repo command using the on chain verify data that is saved in a PDA that is derived from the programs deploy authority and the verify program.

The verify program is deployed by the OtterSec team and is not yet frozen so it can be upgraded at any time.

The Solana Foundation, OtterSec and the Ellipsis Labs team are not responsible for any losses or damages that may occur from using the verified builds pipeline.

Security.txt for Solana programs #

In addition to verified builds you can also add a security.txt file to your program. In the future, once implemented, the security.txt will hold the verifier public key for easy access to the verification data stored in the verification PDA. The PDA containing all the information needed to build and verify a program is derived from the programs address and the verifier pubkey. By default this is the same pubkey that built and deployed the program. But it can also be another pubkey that can be specified in the security.txt.

The security.txt feature allows developers to embed contact and security information directly within their Solana smart contracts. Inspired by securitytxt.org, this approach provides a standardized way for security researchers to reach out to project maintainers, even if they only know the contract's address.

Why use security.txt? #

For many projects, especially smaller or private ones, identifying the developers from just the contract address can be difficult and time-consuming. Embedding a security.txt file within the program ensures that security researchers can easily contact the correct people, potentially preventing exploits and ensuring timely bug reports.

How to implement security.txt #

To add a security.txt to your Solana program, include the following steps:

Add the solana-security-txt dependency to your Cargo.toml:

Cargo.toml

[dependencies]
solana-security-txt = "1.1.1"

Use the security_txt! macro in your contract to define your security information. You can include contact details, project URLs, and even a security policy. Here's an example:

#[cfg(not(feature = "no-entrypoint"))]
use {default_env::default_env, solana_security_txt::security_txt};
 
#[cfg(not(feature = "no-entrypoint"))]
security_txt! {
    name: "MyProject",
    project_url: "https://myproject.com",
    contacts: "email:security@myproject.com,discord:security#1234",
    policy: "https://myproject.com/security-policy",
 
    // Optional Fields
    preferred_languages: "en,de",
    source_code: "https://github.com/solana-developers/solana-game-preset",
    source_revision: "5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    source_release: "",
    encryption: "",
    auditors: "Verifier pubkey: 5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    acknowledgements: "Thank you to our bug bounty hunters!"
}

Once the security.txt information is embedded in your program, it can be easily queried via tools like the Solana Explorer, ensuring that your contact and security details are available to anyone looking to report potential issues.

Best practices #

Use Links: For information likely to change (e.g., contact details), it's recommended to link to a web page rather than hard-coding them into the contract. This avoids the need for frequent program upgrades.
Verification: Before deploying, verify the format and content using the query-security-txt tool, which can validate both onchain programs and local binaries:

query-security-txt target/bpfel-unknown-unknown/release/my_contract.so

By embedding security contact information directly into your contract, you make it easier for researchers to reach you, fostering better security and communication within the Solana ecosystem.

This is an example of how security.txt looks in the Solana Explorer

The security.txt project is maintained by Neodyme Labs