Anchor - Solana Program Framework for Rust and TypeScript

Anchor is the Solana program framework — Rust macros that handle account validation, serialisation and instruction dispatch, plus a TypeScript client generated from your program’s interface. It is dual licensed (MIT OR Apache-2.0), and the client package @coral-xyz/anchor is at version 0.32.1.

Before anything about the framework, there is a practical confusion to clear up, because searching for it returns three repositories.

Three GitHub repositories, one codebase

Search for Anchor and you will find coral-xyz/anchor, otter-sec/anchor and solana-foundation/anchor. All three serve an identical README. It is reasonable to wonder which is real and whether the others are stale forks.

We checked the cheapest possible way, by asking each remote for its current HEAD:

git ls-remote https://github.com/coral-xyz/anchor.git HEAD
git ls-remote https://github.com/otter-sec/anchor.git HEAD
git ls-remote https://github.com/solana-foundation/anchor.git HEAD

All three returned the same commit: 50c68b9b9b57ce7a6f6014e707febef9abb33401.

So the content is identical and in sync — none of them is a stale fork you would be unlucky to clone. For the question of which to treat as canonical, the npm package is the tiebreaker: @coral-xyz/anchor declares repository.url as git+https://github.com/coral-xyz/anchor.git. That is where the published client points, so that is the one to reference, star and read issues on. (The README’s own CI badge points at otter-sec, which is presumably a leftover and is the likely source of the confusion.)

The useful takeaway is the method rather than the answer: git ls-remote <url> HEAD resolves “is this fork current?” in under a second, without cloning, for any repository.

Still pre-1.0, which is the real planning fact

Anchor is at 0.32.1. Years into being the default way to write Solana programs, with substantial value secured by programs built on it, the framework has not declared a 1.0.

For most dependencies that would be a footnote. Here it is not, because Anchor’s version affects deployed on-chain artefacts: the macros determine your account layouts and instruction discriminators. An Anchor upgrade is therefore not purely a build-time concern — it can change the binary interface your clients and your existing accounts depend on.

The discipline that follows is stricter than for an ordinary library:

Pin the exact version in Cargo.toml and in package.json, and keep the Rust and TypeScript sides on matching versions. Mismatched Anchor versions between program and client produce deserialisation errors that look like data corruption.
Record the version that compiled your deployed program. Reproducing a build later — for a verification, an audit, or a patch — requires the same toolchain, and “whatever was current” is not a record.
Read the changelog for breaking changes before upgrading, then test against a local validator with real account data rather than freshly initialised accounts. Fresh accounts hide layout incompatibilities that existing accounts expose immediately.

None of this is unusual advice for on-chain code. It is just advice that pre-1.0 versioning makes mandatory rather than prudent.

What the framework actually removes

It is worth being concrete about the value, because “framework” undersells it.

Writing a raw Solana program means deserialising instruction data by hand, validating every account passed to you — is it the right program owner, is it the signer, is it rent-exempt, is it the PDA you expected — and encoding the results back. The validation is both the bulk of the code and where the vulnerabilities live. Missing one ownership check is a class of exploit, not a bug.

Anchor turns most of that into declarations. You describe the accounts an instruction needs and their constraints as attributes, and the macro generates the checks. The generated code is more consistent than hand-written validation precisely because it is generated.

The second half is the IDL — an interface description emitted at build time, from which the TypeScript client is produced. Your frontend’s types come from your program rather than from a developer’s memory of it, which eliminates the drift that otherwise accumulates between on-chain and off-chain code.

That is the trade: you accept a macro layer you must understand to debug, and you get the account-validation boilerplate and the client types for free.

Where to be careful

The macros are not a security guarantee. Anchor enforces the constraints you declare. It cannot know which constraints you forgot. Account validation is where Solana programs get exploited, and a framework that makes the checks easy to write also makes them easy to omit quietly. Audits of Anchor programs still find missing constraints.

Compilation errors are macro errors. When a declaration is wrong, the message comes from expanded code rather than from the line you wrote. This is the main learning curve, and it is steeper than the framework’s surface suggests.

The ecosystem moves faster than tutorials. Given the pre-1.0 cadence, a guide from eighteen months ago may not compile. Check the version a tutorial targets before following it.

Who it is for

Anyone writing Solana programs, essentially — it is the default for good reasons. If you are approaching Solana from the payments side rather than the program side, Pay is the layer that handles HTTP payment challenges and stablecoin signing without writing a program at all, which is a different and often sufficient answer. The rest of our coverage of this tooling sits in the dev-tools archive.

The finding: the three Anchor repositories on GitHub are byte-identical at the same HEAD commit, and @coral-xyz/anchor is the one the published client names — so clone whichever you like, but reference that one. More consequentially, Anchor is still 0.32.x, and because its macros define your deployed account layouts, pinning the exact version and recording which version built a live program is not optional hygiene.