Security and production

Common Sealevel attack patterns, footguns to avoid, and how to ship verifiable Solana programs.

Sealevel attacks

A curated list of common Solana security exploits and Anchor-idiomatic fixes from the Sealevel attacks repo.

Anchor eliminates many common footguns, but anything shipped to mainnet should be understood end to end. The Sealevel attacks repository catalogs common exploit patterns. Each entry comes in three variants: an insecure version showing the flawed code, a secure version with a fix, and a recommended version that uses idiomatic Anchor.

Important (Not a substitute for review)

These examples are not exhaustive nor guaranteed to be secure on their own. Each one isolates a single issue and its fix for study. Real programs combine multiple checks, and a clean entry here does not mean a program built around that pattern is automatically safe.

Footguns

Common footguns in Anchor that can lead to security or correctness issues.

Zeroed discriminators#

Anchor supports overriding discriminators with custom values for accounts, events, and instructions. All-zero discriminators are only supported on events and instructions. The following forms are rejected for accounts:

#[account(discriminator = [0, 0, 0])]
#[account(discriminator = 0)]
#[account(discriminator = ZERO_CONSTANT)]

Danger (Why all-zero account discriminators are rejected)

An all-zero account discriminator is indistinguishable from a freshly allocated, uninitialized account. A program-owned account whose data is still zero (for example, an AccountInfo that has been allocated but not yet written, or one prepared for #[zero] initialization) would pass the discriminator check, exposing the program to takeover via IDL instructions and other security and usability issues.

Verifiable builds

Use Anchor's Docker-backed CLI to produce reproducible Solana program binaries that can be verified against a deployed program.

Building Solana programs with the Solana CLI can embed machine-specific code into the resulting binary, so the same source on different machines may produce different executables. Anchor solves this by building inside a Docker image with pinned dependencies, producing a verifiable build.

Install Docker first, then use the Anchor CLI commands below.

Building#

Produce a verifiable build:

$anchor build --verifiable

Verifying#

Verify a build against a program deployed on mainnet:

$anchor verify -p <lib-name> <program-id>

The <lib-name> is the library name defined in the program’s Cargo.toml. If the program has an IDL, the IDL deployed on chain is also checked against the local IDL.

Images#

A Docker image for each version of Anchor is published on Docker Hub under tags of the form solanafoundation/anchor:<version>. To pull the image for Anchor v1.0.1:

$docker pull solanafoundation/anchor:v1.0.1

Removing an image#

If a CLI verifiable build exits prematurely, the underlying Docker container may still be running in the background. Remove it with:

$docker rm -f anchor-program

anchor-program is the default image name the Anchor CLI uses.