From 086d812ee9fef720efbad1cdad2ef11c3fec7445 Mon Sep 17 00:00:00 2001 From: mikemaccana-edwardbot Date: Thu, 14 May 2026 22:18:39 +0000 Subject: [PATCH] docs: link canonical Solana terms to terminology page on first mention MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What - Walked every README in the repo and added a markdown link to https://solana.com/docs/terminology for the first prose mention of each canonical Solana term: program, instruction, instruction handler, account, PDA, mint / mint account, token account, ATA, rent, lamport, CPI / cross-program invocation, Token Extensions, onchain, Anchor, Classic Token Program. Why - Readers new to Solana can click straight from any example into the canonical definition of unfamiliar terms without leaving the repo. Rules followed - First prose mention only; subsequent mentions stay plain. - Code blocks, inline code, headers, and pre-existing markdown links untouched. - Case-preserving link text ("Programs" stays "Programs", "PDA" stays "PDA"). - "instruction handler" and "mint account" link once; their constituents ("instruction", "mint") are linked at their next standalone prose mention. - "program" is not linked inside compound proper nouns like "System Program", "Token Program", or "Classic Token Program" (would read oddly mid-name). Anchor corrections vs the original spec - program-derived address → #program-derived-address-pda (spec said #program-derived-account) - mint account / mint → #token-mint (spec said #mint-account) - associated token account → #associated-token-account-ata (spec said #associated-token-account) - Token Extensions → #token-extensions-program (spec said #token-extensions) - Classic Token Program → #token-program (the Solana terminology page uses the older shorter name "Token Program"; same concept — this is the classic SPL token program, as opposed to Token Extensions which has its own anchor). Deliberately unlinked - "signer" and "offchain" have no corresponding anchor on the Solana terminology page (it has #signature but not #signer; #onchain but not #offchain). Left unlinked rather than pointed at wrong/approximate targets. --- README.md | 26 +++++++++---------- basics/checking-accounts/README.md | 4 +-- basics/close-account/anchor/README.md | 8 +++--- basics/counter/anchor/README.md | 4 +-- basics/counter/mpl-stack/README.md | 2 +- basics/counter/native/README.md | 2 +- basics/counter/pinocchio/README.md | 2 +- basics/create-account/README.md | 4 +-- basics/cross-program-invocation/README.md | 10 +++---- .../cross-program-invocation/quasar/README.md | 10 +++---- basics/favorites/anchor/README.md | 2 +- basics/hello-solana/README.md | 4 +-- basics/pda-rent-payer/README.md | 4 +-- basics/processing-instructions/README.md | 4 +-- basics/realloc/README.md | 4 +-- basics/rent/README.md | 4 +-- basics/repository-layout/README.md | 4 +-- basics/transfer-sol/README.md | 4 +-- compression/cnft-burn/anchor/README.md | 4 +-- compression/cnft-vault/anchor/README.md | 4 +-- compression/cutils/anchor/README.md | 8 +++--- oracles/pyth/README.md | 6 ++--- tokens/create-token/README.md | 6 ++--- tokens/escrow/anchor/README.md | 8 +++--- tokens/nft-minter/README.md | 4 +-- tokens/nft-operations/anchor/README.md | 20 +++++++------- tokens/pda-mint-authority/README.md | 4 +-- .../default-account-state/native/README.md | 4 +-- .../anchor-example/README.md | 12 ++++----- .../anchor-example/anchor/README.md | 2 +- .../account-data-as-seed/anchor/README.md | 6 ++--- .../allow-block-list-token/README.md | 6 ++--- .../transfer-hook/block-list/readme.md | 4 +-- .../transfer-hook/whitelist/anchor/README.md | 4 +-- tokens/token-fundraiser/anchor/README.md | 16 ++++++------ tokens/token-minter/README.md | 2 +- tokens/token-swap/README.md | 12 ++++----- tokens/transfer-tokens/README.md | 4 +-- tools/clockwork/README.md | 2 +- tools/shank-and-solita/native/README.md | 6 ++--- 40 files changed, 123 insertions(+), 123 deletions(-) diff --git a/README.md b/README.md index 3a15fef95..9bbb1c7c2 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Quicknode Solana Program Examples -> A fork of the [Solana Foundation program examples](https://github.com/solana-developers/program-examples) with current versions, more programs, and additional frameworks. +> A fork of the [Solana Foundation program examples](https://github.com/solana-developers/program-examples) with current versions, more [programs](https://solana.com/docs/terminology#program), and additional frameworks. [![Anchor](../../actions/workflows/anchor.yml/badge.svg)](../../actions/workflows/anchor.yml) [![Quasar](../../actions/workflows/quasar.yml/badge.svg)](../../actions/workflows/quasar.yml) [![Pinocchio](../../actions/workflows/pinocchio.yml/badge.svg)](../../actions/workflows/pinocchio.yml) [![Native](../../actions/workflows/native.yml/badge.svg)](../../actions/workflows/native.yml) [![ASM](../../actions/workflows/solana-asm.yml/badge.svg)](../../actions/workflows/solana-asm.yml) @@ -13,7 +13,7 @@ Each example is available in one or more of the following frameworks: - [🧬 ASM](https://github.com/blueshift-gg/sbpf) — hand-written sBPF assembly built with the `sbpf` toolchain. Run `pnpm build-and-test` to build and test. > [!NOTE] -> You don't need to write your own program for basic tasks like creating accounts, transferring SOL, or minting tokens. These are handled by existing programs like the System Program and Token Program. +> You don't need to write your own program for basic tasks like creating [accounts](https://solana.com/docs/terminology#account), transferring SOL, or minting tokens. These are handled by existing programs like the System Program and Token Program. ## Financial Software @@ -37,7 +37,7 @@ Create a fundraiser specifying a target mint and amount. Contributors deposit to ### Pyth Price Feeds -Read offchain price data onchain using the Pyth oracle network. +Read offchain price data [onchain](https://solana.com/docs/terminology#onchain) using the Pyth oracle network. [⚓ Anchor](./oracles/pyth/anchor) [💫 Quasar](./oracles/pyth/quasar) @@ -57,7 +57,7 @@ Store and retrieve data using Solana accounts. ### Counter -Use a PDA to store global state — a counter that increments when called. +Use a [PDA](https://solana.com/docs/terminology#program-derived-address-pda) to store global state — a counter that increments when called. [⚓ Anchor](./basics/counter/anchor) [💫 Quasar](./basics/counter/quasar) [🤥 Pinocchio](./basics/counter/pinocchio) [🦀 Native](./basics/counter/native) @@ -69,13 +69,13 @@ Save and update per-user state, ensuring users can only modify their own data. ### Checking Accounts -Validate that accounts provided in incoming instructions meet specific criteria. +Validate that accounts provided in incoming [instructions](https://solana.com/docs/terminology#instruction) meet specific criteria. [⚓ Anchor](./basics/checking-accounts/anchor) [💫 Quasar](./basics/checking-accounts/quasar) [🤥 Pinocchio](./basics/checking-accounts/pinocchio) [🦀 Native](./basics/checking-accounts/native) [🧬 ASM](./basics/checking-accounts/asm) ### Close Account -Close an account and reclaim its lamports. +Close an account and reclaim its [lamports](https://solana.com/docs/terminology#lamport). [⚓ Anchor](./basics/close-account/anchor) [💫 Quasar](./basics/close-account/quasar) [🤥 Pinocchio](./basics/close-account/pinocchio) [🦀 Native](./basics/close-account/native) @@ -93,13 +93,13 @@ Call one program from another — the hand program invokes the lever program to ### PDA Rent Payer -Use a PDA to pay rent for creating a new account. +Use a PDA to pay [rent](https://solana.com/docs/terminology#rent) for creating a new account. [⚓ Anchor](./basics/pda-rent-payer/anchor) [💫 Quasar](./basics/pda-rent-payer/quasar) [🤥 Pinocchio](./basics/pda-rent-payer/pinocchio) [🦀 Native](./basics/pda-rent-payer/native) ### Processing Instructions -Add parameters to an instruction handler and use them. +Add parameters to an [instruction handler](https://solana.com/docs/terminology#instruction-handler) and use them. [⚓ Anchor](./basics/processing-instructions/anchor) [💫 Quasar](./basics/processing-instructions/quasar) [🤥 Pinocchio](./basics/processing-instructions/pinocchio) [🦀 Native](./basics/processing-instructions/native) @@ -155,7 +155,7 @@ Create an NFT collection, mint NFTs, and verify NFTs as part of a collection usi ### Token Minter -Mint tokens from inside your own program using the Classic Token Program. +Mint tokens from inside your own program using the [Classic Token Program](https://solana.com/docs/terminology#token-program). [⚓ Anchor](./tokens/token-minter/anchor) [💫 Quasar](./tokens/token-minter/quasar) [🦀 Native](./tokens/token-minter/native) @@ -181,19 +181,19 @@ Control token transfers using an external secp256k1 delegate signature. ### Basics -Create token mints, mint tokens, and transfer tokens using Token Extensions. +Create token mints, mint tokens, and transfer tokens using [Token Extensions](https://solana.com/docs/terminology#token-extensions-program). [⚓ Anchor](./tokens/token-extensions/basics/anchor) [💫 Quasar](./tokens/token-extensions/basics/quasar) ### CPI Guard -Prevent certain token actions from occurring within cross-program invocations. +Prevent certain token actions from occurring within [cross-program invocations](https://solana.com/docs/terminology#cross-program-invocation-cpi). [⚓ Anchor](./tokens/token-extensions/cpi-guard/anchor) [💫 Quasar](./tokens/token-extensions/cpi-guard/quasar) ### Default Account State -Create new token accounts that are frozen by default. +Create new [token accounts](https://solana.com/docs/terminology#token-account) that are frozen by default. [⚓ Anchor](./tokens/token-extensions/default-account-state/anchor) [💫 Quasar](./tokens/token-extensions/default-account-state/quasar) [🦀 Native](./tokens/token-extensions/default-account-state/native) @@ -223,7 +223,7 @@ Require all transfers to include a descriptive memo. ### Onchain Metadata -Store metadata directly inside the token mint account, without needing additional programs. +Store metadata directly inside the token [mint account](https://solana.com/docs/terminology#token-mint), without needing additional programs. [⚓ Anchor](./tokens/token-extensions/metadata/anchor) diff --git a/basics/checking-accounts/README.md b/basics/checking-accounts/README.md index e163e7c25..0ca58ec2c 100644 --- a/basics/checking-accounts/README.md +++ b/basics/checking-accounts/README.md @@ -1,9 +1,9 @@ # Checking Accounts -Solana programs should check the instructions they receive to ensure security and to make sure required invariants hold. +Solana [programs](https://solana.com/docs/terminology#program) should check the [instructions](https://solana.com/docs/terminology#instruction) they receive to ensure security and to make sure required invariants hold. The exact checks depend on what the program does. Common ones include: - Verifying that the `program_id` on the instruction matches your own program. -- Verifying the order and number of accounts. +- Verifying the order and number of [accounts](https://solana.com/docs/terminology#account). - Checking the initialization state of an account. diff --git a/basics/close-account/anchor/README.md b/basics/close-account/anchor/README.md index 030e494aa..47c9c0253 100644 --- a/basics/close-account/anchor/README.md +++ b/basics/close-account/anchor/README.md @@ -1,8 +1,8 @@ # Close Account -Two instruction handlers: `create_user` initializes a PDA `UserState` account, and `close_user` closes it and returns the rent to the user. +Two [instruction handlers](https://solana.com/docs/terminology#instruction-handler): `create_user` initializes a [PDA](https://solana.com/docs/terminology#program-derived-address-pda) `UserState` [account](https://solana.com/docs/terminology#account), and `close_user` closes it and returns the [rent](https://solana.com/docs/terminology#rent) to the user. -1. `create_user` initializes the PDA with Anchor's `init` constraint: +1. `create_user` initializes the PDA with [Anchor](https://solana.com/docs/terminology#anchor)'s `init` constraint: ```rust #[account( @@ -17,7 +17,7 @@ Two instruction handlers: `create_user` initializes a PDA `UserState` account, a See [`programs/close-account/src/instructions/create_user.rs`](programs/close-account/src/instructions/create_user.rs). -2. `close_user` closes the account using Anchor's `close` constraint, which returns lamports to the given account: +2. `close_user` closes the account using Anchor's `close` constraint, which returns [lamports](https://solana.com/docs/terminology#lamport) to the given account: ```rust #[account( @@ -33,7 +33,7 @@ Two instruction handlers: `create_user` initializes a PDA `UserState` account, a ## Tests -Tests live in [`programs/close-account/tests/test_close_account.rs`](programs/close-account/tests/test_close_account.rs) and run against litesvm. `Anchor.toml`'s `scripts.test` is `cargo test`, so `anchor test` builds the program and runs the Rust tests: +Tests live in [`programs/close-account/tests/test_close_account.rs`](programs/close-account/tests/test_close_account.rs) and run against litesvm. `Anchor.toml`'s `scripts.test` is `cargo test`, so `anchor test` builds the [program](https://solana.com/docs/terminology#program) and runs the Rust tests: ```bash anchor test diff --git a/basics/counter/anchor/README.md b/basics/counter/anchor/README.md index 07bf09ca3..1d8a36d39 100644 --- a/basics/counter/anchor/README.md +++ b/basics/counter/anchor/README.md @@ -1,5 +1,5 @@ # Anchor Counter -Anchor enforces `init` constraints that nudge you towards good programming patterns. +[Anchor](https://solana.com/docs/terminology#anchor) enforces `init` constraints that nudge you towards good programming patterns. -This program has an additional initialization handler for `Counter`s that the Solana native equivalent does not. +This [program](https://solana.com/docs/terminology#program) has an additional initialization handler for `Counter`s that the Solana native equivalent does not. diff --git a/basics/counter/mpl-stack/README.md b/basics/counter/mpl-stack/README.md index bd1543eac..bf6c733f4 100644 --- a/basics/counter/mpl-stack/README.md +++ b/basics/counter/mpl-stack/README.md @@ -4,7 +4,7 @@ A Solana-native counter built using the MPL (Metaplex) stack. ## Setup -1. Build the program: `cargo build-sbf` +1. Build the [program](https://solana.com/docs/terminology#program): `cargo build-sbf` 2. Build the IDL: `shank build` 3. Build the TypeScript SDK: `pnpm solita` - Temporary workaround: edit `ts/generated/accounts/Counter.ts` line 58 to diff --git a/basics/counter/native/README.md b/basics/counter/native/README.md index 05336d246..250d59d9b 100644 --- a/basics/counter/native/README.md +++ b/basics/counter/native/README.md @@ -4,7 +4,7 @@ Counter written in Solana native, using only the Solana toolchain. ## Setup -1. Build the program: `cargo build-sbf` +1. Build the [program](https://solana.com/docs/terminology#program): `cargo build-sbf` 2. Run the tests: `pnpm test` ## Debugging diff --git a/basics/counter/pinocchio/README.md b/basics/counter/pinocchio/README.md index be5a616cd..c6701d400 100644 --- a/basics/counter/pinocchio/README.md +++ b/basics/counter/pinocchio/README.md @@ -4,7 +4,7 @@ Counter written using the Pinocchio framework, with only the Solana toolchain. ## Setup -1. Build the program: `cargo build-sbf` +1. Build the [program](https://solana.com/docs/terminology#program): `cargo build-sbf` 2. Run the tests: `pnpm test` ## Debugging diff --git a/basics/create-account/README.md b/basics/create-account/README.md index 9255bf2ce..5fff31e4e 100644 --- a/basics/create-account/README.md +++ b/basics/create-account/README.md @@ -1,12 +1,12 @@ # Create Account -Create a Solana account. +Create a Solana [account](https://solana.com/docs/terminology#account). The account is a **system account** — owned by the System Program, which means only the System Program can modify its data. In this example, the account simply holds some SOL. The tests cover two ways to create the account: -1. **Via cross-program invocation (CPI):** the client sends a transaction to our deployed program, which in turn calls the System Program. +1. **Via [cross-program invocation](https://solana.com/docs/terminology#cross-program-invocation-cpi) (CPI):** the client sends a transaction to our deployed [program](https://solana.com/docs/terminology#program), which in turn calls the System Program. 2. **Directly:** the client sends the create-account transaction straight to the System Program. See [cross-program-invocation](../cross-program-invocation) for more CPI examples. diff --git a/basics/cross-program-invocation/README.md b/basics/cross-program-invocation/README.md index 2c05d4166..6e81fc624 100644 --- a/basics/cross-program-invocation/README.md +++ b/basics/cross-program-invocation/README.md @@ -1,14 +1,14 @@ # Cross-Program Invocation (CPI) -A cross-program invocation is calling one program from another. You use CPIs when your program needs to compose with other onchain programs to do its work. +A [cross-program invocation](https://solana.com/docs/terminology#cross-program-invocation-cpi) is calling one [program](https://solana.com/docs/terminology#program) from another. You use CPIs when your program needs to compose with other [onchain](https://solana.com/docs/terminology#onchain) programs to do its work. Whether a given operation should be done via a CPI or via separate RPC calls from the client is a design choice. The main reason to use a CPI is a **dependent operation** that must happen atomically with the rest of your logic. -Consider this sequence in a token mint program: +Consider this sequence in a token [mint](https://solana.com/docs/terminology#token-mint) program: 1. Create and initialize the mint. -2. Create a metadata account for the mint. -3. Create and initialize a user's token account for the mint. +2. Create a metadata [account](https://solana.com/docs/terminology#account) for the mint. +3. Create and initialize a user's [token account](https://solana.com/docs/terminology#token-account) for the mint. 4. Mint some tokens to the user's token account. You cannot create a metadata account without first having the mint. Once you decide that steps 1 and 4 must be onchain, the only sensible option is to also do steps 2 and 3 onchain — you cannot pause a program mid-flight to let the client do work. @@ -56,4 +56,4 @@ See the [Features chapter of the Cargo Book](https://doc.rust-lang.org/cargo/ref lever -The `hand` program's `pull_lever` instruction handler does a CPI into the `lever` program's `switch_power` instruction handler. Pull the lever, switch the power. +The `hand` program's `pull_lever` [instruction handler](https://solana.com/docs/terminology#instruction-handler) does a CPI into the `lever` program's `switch_power` instruction handler. Pull the lever, switch the power. diff --git a/basics/cross-program-invocation/quasar/README.md b/basics/cross-program-invocation/quasar/README.md index f86ba4c4d..edf789ca4 100644 --- a/basics/cross-program-invocation/quasar/README.md +++ b/basics/cross-program-invocation/quasar/README.md @@ -1,9 +1,9 @@ # Cross-Program Invocation — Quasar -This example contains **two separate Quasar programs** that work together: +This example contains **two separate Quasar [programs](https://solana.com/docs/terminology#program)** that work together: -- **`lever/`** — A program with onchain `PowerStatus` state and a `switch_power` instruction handler that toggles a boolean. -- **`hand/`** — A program that calls the lever program's `switch_power` via CPI. +- **`lever/`** — A program with [onchain](https://solana.com/docs/terminology#onchain) `PowerStatus` state and a `switch_power` [instruction handler](https://solana.com/docs/terminology#instruction-handler) that toggles a boolean. +- **`hand/`** — A program that calls the lever program's `switch_power` via [CPI](https://solana.com/docs/terminology#cross-program-invocation-cpi). ## Building @@ -27,10 +27,10 @@ The hand tests load **both** programs into `QuasarSvm` and verify that the CPI c ## CPI pattern -Quasar doesn't have a `declare_program!` equivalent for importing arbitrary program instruction types (unlike Anchor). Instead, the hand program: +Quasar doesn't have a `declare_program!` equivalent for importing arbitrary program [instruction](https://solana.com/docs/terminology#instruction) types (unlike [Anchor](https://solana.com/docs/terminology#anchor)). Instead, the hand program: 1. Defines a **marker type** (`LeverProgram`) that implements the `Id` trait with the lever's program address. -2. Uses `Program` in the accounts struct for compile-time address and executable validation. +2. Uses `Program` in the [accounts](https://solana.com/docs/terminology#account) struct for compile-time address and executable validation. 3. Builds the CPI instruction data **manually** using `BufCpiCall`, constructing the lever's wire format directly. This is lower-level than Anchor's CPI pattern but gives full control and works with any program. diff --git a/basics/favorites/anchor/README.md b/basics/favorites/anchor/README.md index 6153598f6..d3dc10b9b 100644 --- a/basics/favorites/anchor/README.md +++ b/basics/favorites/anchor/README.md @@ -1,6 +1,6 @@ # Favorites -A basic Anchor app that uses PDAs to store per-user data, and Anchor account constraints to ensure each user can only modify their own data. +A basic [Anchor](https://solana.com/docs/terminology#anchor) app that uses [PDAs](https://solana.com/docs/terminology#program-derived-address-pda) to store per-user data, and Anchor [account](https://solana.com/docs/terminology#account) constraints to ensure each user can only modify their own data. Used by the [Solana Professional Education](https://github.com/solana-developers/professional-education) course. diff --git a/basics/hello-solana/README.md b/basics/hello-solana/README.md index 721c5f4c2..4ba5ce526 100644 --- a/basics/hello-solana/README.md +++ b/basics/hello-solana/README.md @@ -1,6 +1,6 @@ # Hello Solana -Our first Solana program — a "hello, world" that logs a greeting. Along the way, a quick look at what's inside a Solana transaction. +Our first Solana [program](https://solana.com/docs/terminology#program) — a "hello, world" that logs a greeting. Along the way, a quick look at what's inside a Solana transaction. ## Transactions @@ -9,7 +9,7 @@ Our first Solana program — a "hello, world" that logs a greeting. Along the wa Two things to keep separate: - :key: **Transactions** are for **the Solana runtime**. They contain everything the runtime needs to allow or deny a transaction (signers, recent blockhash, etc.) and to decide what can run in parallel. -- :key: **Instructions** are for **Solana programs**. They tell a program what to do. +- :key: **[Instructions](https://solana.com/docs/terminology#instruction)** are for **Solana programs**. They tell a program what to do. - :key: Your program receives one instruction at a time (`program_id`, `accounts`, `instruction_data`). ### Transaction diff --git a/basics/pda-rent-payer/README.md b/basics/pda-rent-payer/README.md index 7111f7057..61d665291 100644 --- a/basics/pda-rent-payer/README.md +++ b/basics/pda-rent-payer/README.md @@ -1,5 +1,5 @@ # PDA Rent-Payer -Use a PDA to pay rent for a new account. +Use a [PDA](https://solana.com/docs/terminology#program-derived-address-pda) to pay [rent](https://solana.com/docs/terminology#rent) for a new [account](https://solana.com/docs/terminology#account). -Accounts on Solana are created under ownership of the System Program when you transfer lamports to them, so you can pay for a new account simply by transferring lamports from your PDA to the new account's public key. +Accounts on Solana are created under ownership of the System Program when you transfer [lamports](https://solana.com/docs/terminology#lamport) to them, so you can pay for a new account simply by transferring lamports from your PDA to the new account's public key. diff --git a/basics/processing-instructions/README.md b/basics/processing-instructions/README.md index a28188815..f8d31a61a 100644 --- a/basics/processing-instructions/README.md +++ b/basics/processing-instructions/README.md @@ -1,6 +1,6 @@ # Custom Instruction Data -Pass your own custom instruction data to a program. The data must be serialized in a format the Solana runtime can read — typically via the `borsh` crate on both the client and program sides. +Pass your own custom [instruction](https://solana.com/docs/terminology#instruction) data to a [program](https://solana.com/docs/terminology#program). The data must be serialized in a format the Solana runtime can read — typically via the `borsh` crate on both the client and program sides. - **For `native`:** add `borsh` and `borsh-derive` to `Cargo.toml` so you can mark a struct as serializable. -- **For Anchor:** the framework handles serialization for you via the IDL. +- **For [Anchor](https://solana.com/docs/terminology#anchor):** the framework handles serialization for you via the IDL. diff --git a/basics/realloc/README.md b/basics/realloc/README.md index 95c6c9a99..1f68ec971 100644 --- a/basics/realloc/README.md +++ b/basics/realloc/README.md @@ -1,9 +1,9 @@ # Realloc -Resize a Solana account after it has been created — grow or shrink the data it can hold. +Resize a Solana [account](https://solana.com/docs/terminology#account) after it has been created — grow or shrink the data it can hold. ## A note on `realloc` vs `resize` The runtime method `AccountInfo::realloc` has been deprecated in favor of `AccountInfo::resize` ([anchor#4526](https://github.com/solana-foundation/anchor/issues/4526)). New code should call `AccountInfo::resize`. -The Anchor account-constraint macros (`#[account(realloc = ..., realloc::payer = ..., realloc::zero = ...)]`) are **not yet renamed** and still use the `realloc` spelling. That is the correct form to use today; track the issue above for any future change. +The [Anchor](https://solana.com/docs/terminology#anchor) account-constraint macros (`#[account(realloc = ..., realloc::payer = ..., realloc::zero = ...)]`) are **not yet renamed** and still use the `realloc` spelling. That is the correct form to use today; track the issue above for any future change. diff --git a/basics/rent/README.md b/basics/rent/README.md index 0795bcc85..92b3ec7ee 100644 --- a/basics/rent/README.md +++ b/basics/rent/README.md @@ -1,7 +1,7 @@ # Rent -All storage on Solana costs **rent**. +All storage on Solana costs **[rent](https://solana.com/docs/terminology#rent)**. -In practice, rent is a small amount and accounts that hold at least two years' worth of rent are **rent-exempt** — they pay nothing. If your account holds more lamports than the two-year cost, it isn't charged rent. +In practice, rent is a small amount and [accounts](https://solana.com/docs/terminology#account) that hold at least two years' worth of rent are **rent-exempt** — they pay nothing. If your account holds more [lamports](https://solana.com/docs/terminology#lamport) than the two-year cost, it isn't charged rent. Rent is calculated from the size of the data stored in the account. diff --git a/basics/repository-layout/README.md b/basics/repository-layout/README.md index d9e214505..0a9d74757 100644 --- a/basics/repository-layout/README.md +++ b/basics/repository-layout/README.md @@ -1,7 +1,7 @@ # Recommended Program Layout -A typical layout for a Solana program as it grows in size and starts to need multiple Rust files. Many programs follow this shape. +A typical layout for a Solana [program](https://solana.com/docs/terminology#program) as it grows in size and starts to need multiple Rust files. Many programs follow this shape. > You can structure your `src` folder however you like, as long as it follows Cargo's conventions. This layout is shown so that the patterns in other programs are recognizable. -The `native` and `anchor` layouts are similar. The main difference is the `processor.rs` file in the `native` setup — one of the things Anchor abstracts away for you. +The `native` and `anchor` layouts are similar. The main difference is the `processor.rs` file in the `native` setup — one of the things [Anchor](https://solana.com/docs/terminology#anchor) abstracts away for you. diff --git a/basics/transfer-sol/README.md b/basics/transfer-sol/README.md index c1fec6815..9378106ee 100644 --- a/basics/transfer-sol/README.md +++ b/basics/transfer-sol/README.md @@ -1,5 +1,5 @@ # Transfer SOL -A simple example of transferring SOL between two system accounts. SOL can be transferred between many kinds of accounts, not just system accounts (accounts owned by the System Program). +A simple example of transferring SOL between two system [accounts](https://solana.com/docs/terminology#account). SOL can be transferred between many kinds of accounts, not just system accounts (accounts owned by the System Program). -The tests generate a fresh keypair for both the `native` and `anchor` versions. Transferring SOL to the new keypair's address initializes it as a default system account — hence the `/// CHECK` annotation above it in the Anchor example. +The tests generate a fresh keypair for both the `native` and `anchor` versions. Transferring SOL to the new keypair's address initializes it as a default system account — hence the `/// CHECK` annotation above it in the [Anchor](https://solana.com/docs/terminology#anchor) example. diff --git a/compression/cnft-burn/anchor/README.md b/compression/cnft-burn/anchor/README.md index ff90a49ac..715afc8d0 100644 --- a/compression/cnft-burn/anchor/README.md +++ b/compression/cnft-burn/anchor/README.md @@ -1,6 +1,6 @@ # cnft-burn -An Anchor program that burns compressed NFTs (cNFTs) in your collection. The program performs a CPI into the Metaplex Bubblegum program to do the burn. +An [Anchor](https://solana.com/docs/terminology#anchor) [program](https://solana.com/docs/terminology#program) that burns compressed NFTs (cNFTs) in your collection. The program performs a [CPI](https://solana.com/docs/terminology#cross-program-invocation-cpi) into the Metaplex Bubblegum program to do the burn. ## Components @@ -17,5 +17,5 @@ To deploy your own copy, change the program ID in `lib.rs` and `Anchor.toml`, th ## Acknowledgements -- [Metaplex](https://github.com/metaplex-foundation/) for the Bubblegum program and instruction builders. +- [Metaplex](https://github.com/metaplex-foundation/) for the Bubblegum program and [instruction](https://solana.com/docs/terminology#instruction) builders. - [@nickfrosty](https://twitter.com/nickfrosty) for the sample code that fetches and creates cNFTs. diff --git a/compression/cnft-vault/anchor/README.md b/compression/cnft-vault/anchor/README.md index 47451153a..687cb0a31 100644 --- a/compression/cnft-vault/anchor/README.md +++ b/compression/cnft-vault/anchor/README.md @@ -1,8 +1,8 @@ # cNFT Vault -Example code for working with Metaplex compressed NFTs (cNFTs) inside Solana Anchor programs. +Example code for working with Metaplex compressed NFTs (cNFTs) inside Solana [Anchor](https://solana.com/docs/terminology#anchor) [programs](https://solana.com/docs/terminology#program). -The program keeps a PDA-owned vault. You send cNFTs to the vault, then withdraw them via the program's instruction handlers. +The program keeps a PDA-owned vault. You send cNFTs to the vault, then withdraw them via the program's [instruction handlers](https://solana.com/docs/terminology#instruction-handler). Two handlers: diff --git a/compression/cutils/anchor/README.md b/compression/cutils/anchor/README.md index d46460fa0..7fe7e594f 100644 --- a/compression/cutils/anchor/README.md +++ b/compression/cutils/anchor/README.md @@ -1,11 +1,11 @@ # cNFT Utils -Example code for working with Metaplex compressed NFTs (cNFTs) inside Solana Anchor programs. +Example code for working with Metaplex compressed NFTs (cNFTs) inside Solana [Anchor](https://solana.com/docs/terminology#anchor) [programs](https://solana.com/docs/terminology#program). -This program shows how to add custom logic around the Bubblegum mint via CPI. Two handlers: +This program shows how to add custom logic around the Bubblegum [mint](https://solana.com/docs/terminology#token-mint) via [CPI](https://solana.com/docs/terminology#cross-program-invocation-cpi). Two handlers: -1. `mint` — mints a cNFT to your collection by CPI'ing Bubblegum. You can also initialize your own program-specific PDA in this handler. -2. `verify` — verifies that the owner of a given cNFT actually invoked the instruction. Useful as a building block for permissioned cNFT-gated logic. +1. `mint` — mints a cNFT to your collection by CPI'ing Bubblegum. You can also initialize your own program-specific [PDA](https://solana.com/docs/terminology#program-derived-address-pda) in this handler. +2. `verify` — verifies that the owner of a given cNFT actually invoked the [instruction](https://solana.com/docs/terminology#instruction). Useful as a building block for permissioned cNFT-gated logic. Use this as a reference for working with cNFTs in your own programs. diff --git a/oracles/pyth/README.md b/oracles/pyth/README.md index cbea80352..408175848 100644 --- a/oracles/pyth/README.md +++ b/oracles/pyth/README.md @@ -1,14 +1,14 @@ # Pyth Price Feeds -[Pyth](https://pyth.network/) is an oracle that publishes low-latency market data from institutional sources onchain. You can use it to read real-world asset prices from Solana programs. +[Pyth](https://pyth.network/) is an oracle that publishes low-latency market data from institutional sources [onchain](https://solana.com/docs/terminology#onchain). You can use it to read real-world asset prices from Solana [programs](https://solana.com/docs/terminology#program). -Each asset's price lives in its own Solana account — a **price feed**. +Each asset's price lives in its own Solana [account](https://solana.com/docs/terminology#account) — a **price feed**. For example, the SOL/USD price feed on mainnet lives at `H6ARHf6YXhGYeQfUzQNGk6rDNnLBQKrenN712K4AQJEG`. You can find more feeds in the [Pyth feed list](https://pyth.network/price-feeds?cluster=mainnet-beta). -To use a feed, pass its account into your instruction handler's context, then read the account's data. A feed contains: +To use a feed, pass its account into your [instruction handler](https://solana.com/docs/terminology#instruction-handler)'s context, then read the account's data. A feed contains: - A price. - A confidence interval. diff --git a/tokens/create-token/README.md b/tokens/create-token/README.md index ed85237f6..2300cb026 100644 --- a/tokens/create-token/README.md +++ b/tokens/create-token/README.md @@ -2,7 +2,7 @@ Create a token on Solana with metadata such as a symbol and an icon. -All fungible assets and NFTs on Solana are tokens. They follow the Classic Token Program standard (similar in spirit to ERC-20), or the newer Token Extensions standard. +All fungible assets and NFTs on Solana are tokens. They follow the [Classic Token Program](https://solana.com/docs/terminology#token-program) standard (similar in spirit to ERC-20), or the newer [Token Extensions](https://solana.com/docs/terminology#token-extensions-program) standard. ```text Typical fungible tokens : 9 decimals @@ -19,7 +19,7 @@ For a token JOE with 9 decimals: ## Mint and metadata -A token is represented onchain by a **Mint Account**: +A token is represented [onchain](https://solana.com/docs/terminology#onchain) by a **[Mint Account](https://solana.com/docs/terminology#token-mint)**: ```typescript { @@ -31,7 +31,7 @@ A token is represented onchain by a **Mint Account**: } ``` -Metadata about a mint — name, symbol, image URI — lives in a separate **Metadata Account**: +Metadata about a mint — name, symbol, image URI — lives in a separate **Metadata [Account](https://solana.com/docs/terminology#account)**: ```typescript { diff --git a/tokens/escrow/anchor/README.md b/tokens/escrow/anchor/README.md index 310a17e70..ef5ba5ef2 100644 --- a/tokens/escrow/anchor/README.md +++ b/tokens/escrow/anchor/README.md @@ -2,7 +2,7 @@ ## Introduction -This Solana program is an **escrow** — it lets a user swap a specific amount of one token for a desired amount of another token. +This Solana [program](https://solana.com/docs/terminology#program) is an **escrow** — it lets a user swap a specific amount of one token for a desired amount of another token. For example: Alice offers 10 USDC and wants 100 WIF in return. @@ -24,14 +24,14 @@ One challenge when teaching is avoiding ambiguity — names have to be clear and - Several custom handler functions were replaced by helpers from `@solana-developers/helpers` to reduce file size. - Shared token-transfer logic now lives in `instructions/shared.rs`. -- The upstream project uses a custom file layout. This version uses the 'multiple files' Anchor layout. +- The upstream project uses a custom file layout. This version uses the 'multiple files' [Anchor](https://solana.com/docs/terminology#anchor) layout. - Contexts are separate data structures from the functions that use them. There's no need for OO-style `impl` patterns here — no mutable state is stored in the context, and the methods don't mutate it. - The name 'deposit' was overloaded. `deposit` is both a verb and a noun, which made the code hard to read: - deposit #1 → `token_a_offered_amount` - deposit #2 (in `make()`) → `send_offered_tokens_to_vault` - deposit #3 (in `take()`) → `send_wanted_tokens_to_maker` -- `seed` was renamed to `id`, because it conflicted with the `seeds` used for PDA derivation. -- `Escrow` was used for both the program name and the account that records an offer. People kept confusing the offer account with the vault. +- `seed` was renamed to `id`, because it conflicted with the `seeds` used for [PDA](https://solana.com/docs/terminology#program-derived-address-pda) derivation. +- `Escrow` was used for both the program name and the [account](https://solana.com/docs/terminology#account) that records an offer. People kept confusing the offer account with the vault. - `Escrow` (the program) → still `Escrow`. - `Escrow` (the offer) → `Offer`. - `receive` was renamed to `token_b_wanted_amount`, since `receive` is a verb and not a good name for an integer. diff --git a/tokens/nft-minter/README.md b/tokens/nft-minter/README.md index 9582cf121..8a17c967d 100644 --- a/tokens/nft-minter/README.md +++ b/tokens/nft-minter/README.md @@ -2,11 +2,11 @@ Minting NFTs is the same as [minting any token on Solana](../token-minter/), with one extra step at the end. -When you mint tokens, you can in most cases continue to mint more later, growing the supply. An NFT is supposed to have a supply of **one**, so no more can ever be minted. +When you [mint](https://solana.com/docs/terminology#token-mint) tokens, you can in most cases continue to mint more later, growing the supply. An NFT is supposed to have a supply of **one**, so no more can ever be minted. The way to do that is to remove the mint authority from the mint: -> The Mint Authority is the account allowed to mint new tokens into supply. +> The Mint Authority is the [account](https://solana.com/docs/terminology#account) allowed to mint new tokens into supply. Setting the mint authority to `null` permanently disables minting. **This is irreversible.** diff --git a/tokens/nft-operations/anchor/README.md b/tokens/nft-operations/anchor/README.md index 199c74414..f05d26974 100644 --- a/tokens/nft-operations/anchor/README.md +++ b/tokens/nft-operations/anchor/README.md @@ -4,7 +4,7 @@ Create an NFT collection, mint an NFT, and verify an NFT as part of a collection ## Program setup -This example clones the Metaplex Token Metadata program from mainnet. See `Anchor.toml`: +This example clones the Metaplex Token Metadata [program](https://solana.com/docs/terminology#program) from mainnet. See `Anchor.toml`: ```toml [test.validator] @@ -14,7 +14,7 @@ url = "https://api.mainnet-beta.solana.com" address = "metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s" ``` -The program is needed for CPIs that create metadata accounts and master edition accounts, and to verify NFTs as part of a collection. +The program is needed for [CPIs](https://solana.com/docs/terminology#cross-program-invocation-cpi) that create metadata [accounts](https://solana.com/docs/terminology#account) and master edition accounts, and to verify NFTs as part of a collection. ## Create an NFT collection @@ -61,17 +61,17 @@ pub struct CreateCollection<'info> { ### Account breakdown -- `user`: the account creating the collection NFT and the owner of the destination token account. -- `mint`: the collection NFT mint account. Initialized with 0 decimals; the mint authority and freeze authority are set to `mint_authority`. -- `mint_authority`: the PDA authority used to mint tokens from the collection mint. +- `user`: the account creating the collection NFT and the owner of the destination [token account](https://solana.com/docs/terminology#token-account). +- `mint`: the collection NFT [mint account](https://solana.com/docs/terminology#token-mint). Initialized with 0 decimals; the mint authority and freeze authority are set to `mint_authority`. +- `mint_authority`: the [PDA](https://solana.com/docs/terminology#program-derived-address-pda) authority used to mint tokens from the collection mint. - `metadata`: the metadata account of the collection NFT. - `master_edition`: the master edition account of the collection NFT. - `destination`: the token account that receives the collection NFT. - `system_program`: initializes new accounts. -- `token_program` / `associated_token_program`: create new ATAs and mint tokens. +- `token_program` / `associated_token_program`: create new [ATAs](https://solana.com/docs/terminology#associated-token-account-ata) and mint tokens. - `token_metadata_program`: the MPL Token Metadata program, used to create the metadata and master edition accounts. -Both `metadata` and `master_edition` are `UncheckedAccount` because they are uninitialized at the start of the instruction — the Token Metadata program initializes them via CPI. +Both `metadata` and `master_edition` are `UncheckedAccount` because they are uninitialized at the start of the [instruction](https://solana.com/docs/terminology#instruction) — the Token Metadata program initializes them via CPI. Had we written: @@ -85,13 +85,13 @@ pub struct CreateCollection<'info> { } ``` -the instruction would fail because Anchor would expect the accounts to already be initialized. +the instruction would fail because [Anchor](https://solana.com/docs/terminology#anchor) would expect the accounts to already be initialized. When an account *is* already initialized (as in the verify-collection flow below), use the specific account types. ### Implementation for `CreateCollection` -Each instruction handler is a free function (`pub fn handler(accounts: &mut X, bumps: &XBumps)`) called from the `#[program]` module in `lib.rs`. The account-validation struct lives in the same file as the handler. +Each [instruction handler](https://solana.com/docs/terminology#instruction-handler) is a free function (`pub fn handler(accounts: &mut X, bumps: &XBumps)`) called from the `#[program]` module in `lib.rs`. The account-validation struct lives in the same file as the handler. ```rust pub fn handler(accounts: &mut CreateCollection, bumps: &CreateCollectionBumps) -> Result<()> { @@ -170,7 +170,7 @@ pub fn handler(accounts: &mut CreateCollection, bumps: &CreateCollectionBumps) - Three steps: -1. Mint one token to the destination token account via a CPI to the Classic Token Program. +1. Mint one token to the destination token account via a CPI to the [Classic Token Program](https://solana.com/docs/terminology#token-program). 2. Create a metadata account for the mint via a CPI to the Token Metadata program. The mint authority signs the CPI, so we use `invoke_signed` with the authority PDA's seeds. 3. Create a master edition account for the mint via a CPI to the Token Metadata program. This enforces the NFT-specific constraints and transfers both the mint authority and freeze authority to the Master Edition PDA. Again, the mint authority signs. diff --git a/tokens/pda-mint-authority/README.md b/tokens/pda-mint-authority/README.md index e8b58df23..4616744e4 100644 --- a/tokens/pda-mint-authority/README.md +++ b/tokens/pda-mint-authority/README.md @@ -1,5 +1,5 @@ # PDA Mint Authority -The same as the [NFT Minter](../nft-minter) example, except the **mint authority** is a PDA rather than a system account belonging to the payer. +The same as the [NFT Minter](../nft-minter) example, except the **[mint](https://solana.com/docs/terminology#token-mint) authority** is a [PDA](https://solana.com/docs/terminology#program-derived-address-pda) rather than a system [account](https://solana.com/docs/terminology#account) belonging to the payer. -💡 Notice the use of `invoke_signed` for CPIs. +💡 Notice the use of `invoke_signed` for [CPIs](https://solana.com/docs/terminology#cross-program-invocation-cpi). diff --git a/tokens/token-extensions/default-account-state/native/README.md b/tokens/token-extensions/default-account-state/native/README.md index 705ceaa52..fffb36345 100644 --- a/tokens/token-extensions/default-account-state/native/README.md +++ b/tokens/token-extensions/default-account-state/native/README.md @@ -1,8 +1,8 @@ # Token Extensions — Default Account State -This extension sets a default state for all token accounts of a given mint. +This extension sets a default state for all [token accounts](https://solana.com/docs/terminology#token-account) of a given [mint](https://solana.com/docs/terminology#token-mint). -Account states: +[Account](https://solana.com/docs/terminology#account) states: - **initialized:** a normal token account that can transfer, etc. - **frozen:** the owner cannot perform any token actions until the account is unfrozen. diff --git a/tokens/token-extensions/nft-meta-data-pointer/anchor-example/README.md b/tokens/token-extensions/nft-meta-data-pointer/anchor-example/README.md index ac1221e2c..36be1cd09 100644 --- a/tokens/token-extensions/nft-meta-data-pointer/anchor-example/README.md +++ b/tokens/token-extensions/nft-meta-data-pointer/anchor-example/README.md @@ -1,8 +1,8 @@ # Token Extensions Metadata-Pointer NFT -An Anchor program that mints an NFT using the Token Extensions metadata-pointer extension. The mint itself stores its own metadata via the metadata extension, so no separate Metaplex metadata account is needed. +An Anchor [program](https://solana.com/docs/terminology#program) that mints an NFT using the [Token Extensions](https://solana.com/docs/terminology#token-extensions-program) metadata-pointer extension. The mint itself stores its own metadata via the metadata extension, so no separate Metaplex metadata [account](https://solana.com/docs/terminology#account) is needed. -This is particularly useful for games — you get arbitrary key/value metadata stored onchain that you can use to record character state. In this example, the player's level and collected wood are stored on the NFT. +This is particularly useful for games — you get arbitrary key/value metadata stored [onchain](https://solana.com/docs/terminology#onchain) that you can use to record character state. In this example, the player's level and collected wood are stored on the NFT. When marketplaces support additional metadata, NFTs can be filtered or ranked by those fields, e.g. by character level. @@ -30,12 +30,12 @@ pnpm dev Creating an NFT this way: -1. Create the mint account. +1. Create the [mint account](https://solana.com/docs/terminology#token-mint). 2. Initialize the metadata pointer (must happen *before* initializing the mint). 3. Initialize the mint with 0 decimals. 4. Initialize the metadata extension on the mint itself. 5. Add any custom fields (e.g. `level`). -6. Create the player's Associated Token Account. +6. Create the player's [Associated Token Account](https://solana.com/docs/terminology#associated-token-account-ata). 7. Mint one token to the ATA. 8. Remove the mint authority — irreversible, makes it an NFT. @@ -70,11 +70,11 @@ anchor/programs/extension_nft/src/ └── lib.rs ``` -`PlayerData::update_energy` (in `state/player_data.rs`) is where the lazy refill is computed; there is no separate `update_energy.rs` instruction handler. +`PlayerData::update_energy` (in `state/player_data.rs`) is where the lazy refill is computed; there is no separate `update_energy.rs` [instruction handler](https://solana.com/docs/terminology#instruction-handler). ## Session keys -The example uses [Gum session keys](https://github.com/magicblock-labs/session-keys) to auto-approve transactions: a local keypair is topped up with a small amount of SOL and is allowed to sign specific program instructions for a limited window (currently 23h). When it expires, the SOL is returned and a new session can be created. +The example uses [Gum session keys](https://github.com/magicblock-labs/session-keys) to auto-approve transactions: a local keypair is topped up with a small amount of SOL and is allowed to sign specific program [instructions](https://solana.com/docs/terminology#instruction) for a limited window (currently 23h). When it expires, the SOL is returned and a new session can be created. Neither the program nor the session-keys library has been audited. Use at your own risk. diff --git a/tokens/token-extensions/nft-meta-data-pointer/anchor-example/anchor/README.md b/tokens/token-extensions/nft-meta-data-pointer/anchor-example/anchor/README.md index 267c6883a..6a2d9aac0 100644 --- a/tokens/token-extensions/nft-meta-data-pointer/anchor-example/anchor/README.md +++ b/tokens/token-extensions/nft-meta-data-pointer/anchor-example/anchor/README.md @@ -5,7 +5,7 @@ anchor build anchor deploy ``` -Copy the **program ID** from the output logs and paste it into `Anchor.toml` and `lib.rs`. Then rebuild, redeploy, and run the tests: +Copy the **[program](https://solana.com/docs/terminology#program) ID** from the output logs and paste it into `Anchor.toml` and `lib.rs`. Then rebuild, redeploy, and run the tests: ```bash anchor build diff --git a/tokens/token-extensions/transfer-hook/account-data-as-seed/anchor/README.md b/tokens/token-extensions/transfer-hook/account-data-as-seed/anchor/README.md index 43cbb37f1..e6af5c16f 100644 --- a/tokens/token-extensions/transfer-hook/account-data-as-seed/anchor/README.md +++ b/tokens/token-extensions/transfer-hook/account-data-as-seed/anchor/README.md @@ -1,6 +1,6 @@ # Using Token Account Data as a Seed in a Transfer Hook -Sometimes you want to use account data to derive additional accounts in the extra-account-metas. For example, you might want to use the token account's owner as a seed for a PDA. +Sometimes you want to use [account](https://solana.com/docs/terminology#account) data to derive additional accounts in the extra-account-metas. For example, you might want to use the [token account](https://solana.com/docs/terminology#token-account)'s owner as a seed for a [PDA](https://solana.com/docs/terminology#program-derived-address-pda). When creating an `ExtraAccountMeta`, the data of any account can be used as an extra seed. In this example we derive a counter account from the token account owner and the literal `"counter"`. The counter records how many times that owner has transferred tokens. @@ -26,7 +26,7 @@ impl<'info> InitializeExtraAccountMetaList<'info> { } ``` -The token account layout is what makes `data_index: 32, length: 32` mean "the owner field". Bytes 0..32 are the mint and bytes 32..64 are the owner: +The token account layout is what makes `data_index: 32, length: 32` mean "the owner field". Bytes 0..32 are the [mint](https://solana.com/docs/terminology#token-mint) and bytes 32..64 are the owner: ```rust /// Token account data. @@ -80,7 +80,7 @@ pub struct InitializeExtraAccountMetaList<'info> { } ``` -The counter account also has to appear on the `TransferHook` struct — the program needs to know about every account passed in by the runtime: +The counter account also has to appear on the `TransferHook` struct — the [program](https://solana.com/docs/terminology#program) needs to know about every account passed in by the runtime: ```rust #[derive(Accounts)] diff --git a/tokens/token-extensions/transfer-hook/allow-block-list-token/README.md b/tokens/token-extensions/transfer-hook/allow-block-list-token/README.md index f58862726..b59cd6ef4 100644 --- a/tokens/token-extensions/transfer-hook/allow-block-list-token/README.md +++ b/tokens/token-extensions/transfer-hook/allow-block-list-token/README.md @@ -1,8 +1,8 @@ # Allow/Block-List Token -A Token Extensions example that gates transfers through an allow/block list managed by a separate authority. The list is consumed by a transfer hook. +A [Token Extensions](https://solana.com/docs/terminology#token-extensions-program) example that gates transfers through an allow/block list managed by a separate authority. The list is consumed by a transfer hook. -One list authority can manage lists for many mints — useful when an issuer wants a third-party-managed list or wants to share a single list across a set of assets. +One list authority can manage lists for many [mints](https://solana.com/docs/terminology#token-mint) — useful when an issuer wants a third-party-managed list or wants to share a single list across a set of assets. ## Features @@ -37,5 +37,5 @@ pnpm run dev # serve the UI Scripts manage the local validator and deployment: -- `./scripts/start.sh` — start the local validator and deploy the program (uses the Anchor CLI and the default Anchor keypair). +- `./scripts/start.sh` — start the local validator and deploy the [program](https://solana.com/docs/terminology#program) (uses the [Anchor](https://solana.com/docs/terminology#anchor) CLI and the default Anchor keypair). - `./scripts/stop.sh` — stop the local validator. diff --git a/tokens/token-extensions/transfer-hook/block-list/readme.md b/tokens/token-extensions/transfer-hook/block-list/readme.md index 32d952447..2106810e6 100644 --- a/tokens/token-extensions/transfer-hook/block-list/readme.md +++ b/tokens/token-extensions/transfer-hook/block-list/readme.md @@ -1,12 +1,12 @@ # Block List -A block-list program that implements the Token Extensions transfer-hook `execute` instruction. +A block-list [program](https://solana.com/docs/terminology#program) that implements the [Token Extensions](https://solana.com/docs/terminology#token-extensions-program) transfer-hook `execute` [instruction](https://solana.com/docs/terminology#instruction). A central authority maintains a block list — a collection of blocked wallets. Token issuers (transfer-hook extension authorities) can wire this program in as their hook and choose an operation mode: filter the source wallet only, or both source and destination. ## Operation modes -The mode depends on whether the block list is empty, plus the issuer's choice. Each mode corresponds to a different `extra-account-metas` account built for the mint (see `setup_extra_metas` below). When the list goes from empty to non-empty, the issuer must call `setup_extra_metas` again. +The mode depends on whether the block list is empty, plus the issuer's choice. Each mode corresponds to a different `extra-account-metas` [account](https://solana.com/docs/terminology#account) built for the [mint](https://solana.com/docs/terminology#token-mint) (see `setup_extra_metas` below). When the list goes from empty to non-empty, the issuer must call `setup_extra_metas` again. - **Empty extra metas** — default when the config counter is 0. - **Check source** — default when the config counter is > 0. diff --git a/tokens/token-extensions/transfer-hook/whitelist/anchor/README.md b/tokens/token-extensions/transfer-hook/whitelist/anchor/README.md index 9d76cf18a..98a50dba5 100644 --- a/tokens/token-extensions/transfer-hook/whitelist/anchor/README.md +++ b/tokens/token-extensions/transfer-hook/whitelist/anchor/README.md @@ -1,5 +1,5 @@ # Transfer Hook — Whitelist (Anchor) -A whitelist enforced by a Token Extensions transfer hook. The whitelist is stored inline on a single account. +A whitelist enforced by a [Token Extensions](https://solana.com/docs/terminology#token-extensions-program) transfer hook. The whitelist is stored inline on a single [account](https://solana.com/docs/terminology#account). -This approach doesn't scale: the whitelist eventually runs out of account space. For larger lists, store entries in external PDAs (one PDA per whitelisted wallet) — see the [`block-list`](../../block-list/) example for that pattern. +This approach doesn't scale: the whitelist eventually runs out of account space. For larger lists, store entries in external [PDAs](https://solana.com/docs/terminology#program-derived-address-pda) (one PDA per whitelisted wallet) — see the [`block-list`](../../block-list/) example for that pattern. diff --git a/tokens/token-fundraiser/anchor/README.md b/tokens/token-fundraiser/anchor/README.md index a17df4069..73c17984c 100644 --- a/tokens/token-fundraiser/anchor/README.md +++ b/tokens/token-fundraiser/anchor/README.md @@ -1,6 +1,6 @@ # Token Fundraiser -Create a fundraiser that collects tokens. A user creates a fundraiser account, specifies the mint they want to receive, the target amount, and a duration. Other users contribute. If the target is reached, the maker can claim the funds; if it isn't reached within the duration, contributors can refund. +Create a fundraiser that collects tokens. A user creates a fundraiser [account](https://solana.com/docs/terminology#account), specifies the [mint](https://solana.com/docs/terminology#token-mint) they want to receive, the target amount, and a duration. Other users contribute. If the target is reached, the maker can claim the funds; if it isn't reached within the duration, contributors can refund. ## Architecture @@ -28,9 +28,9 @@ Fields: - `current_amount` — total amount currently contributed. - `time_started` — when the fundraiser was created. - `duration` — fundraising window in days. -- `bump` — canonical bump for the Fundraiser PDA. +- `bump` — canonical bump for the Fundraiser [PDA](https://solana.com/docs/terminology#program-derived-address-pda). -The `InitSpace` derive macro implements the `Space` trait, which calculates the size of the account (not counting the Anchor discriminator). +The `InitSpace` derive macro implements the `Space` trait, which calculates the size of the account (not counting the [Anchor](https://solana.com/docs/terminology#anchor) discriminator). A per-contributor record: @@ -63,7 +63,7 @@ pub const PERCENTAGE_SCALER: u64 = 100; ### Code layout -Each instruction handler is a free function (`pub fn handle_(accounts: &mut , ...)`) called from the `#[program]` module in `lib.rs`. Account-validation structs sit in the same file as the handler. +Each [instruction handler](https://solana.com/docs/terminology#instruction-handler) is a free function (`pub fn handle_(accounts: &mut , ...)`) called from the `#[program]` module in `lib.rs`. Account-validation structs sit in the same file as the handler. ## Instruction handlers @@ -100,10 +100,10 @@ pub struct Initialize<'info> { Account breakdown: -- `maker` — the person starting the fundraiser. Signs; mutable so we can deduct lamports. +- `maker` — the person starting the fundraiser. Signs; mutable so we can deduct [lamports](https://solana.com/docs/terminology#lamport). - `mint_to_raise` — the mint the maker wants to receive. - `fundraiser` — the state account. Derived from `b"fundraiser"` and the maker's public key; Anchor calculates the canonical bump and stores it in the struct. -- `vault` — the ATA that receives contributions, owned by the Fundraiser PDA. +- `vault` — the [ATA](https://solana.com/docs/terminology#associated-token-account-ata) that receives contributions, owned by the Fundraiser PDA. - `system_program`, `token_program`, `associated_token_program` — needed to initialize the new accounts. The handler requires `amount >= MIN_AMOUNT_TO_RAISE.pow(mint.decimals)` and initializes the Fundraiser state. @@ -119,13 +119,13 @@ Account-validation struct: see source. The handler performs four `require!` chec 3. `fundraiser.duration <= (current_time - time_started) / SECONDS_TO_DAYS` — see the [duration semantics note](#duration-check-semantics) below. 4. Cumulative contributor cap: this contributor's running total (existing + new) must not exceed 10% of the target. -If all four checks pass, tokens are transferred from `contributor_ata` to `vault` via a CPI to the Classic Token Program, and both `Fundraiser.current_amount` and `Contributor.amount` are updated. +If all four checks pass, tokens are transferred from `contributor_ata` to `vault` via a [CPI](https://solana.com/docs/terminology#cross-program-invocation-cpi) to the [Classic Token Program](https://solana.com/docs/terminology#token-program), and both `Fundraiser.current_amount` and `Contributor.amount` are updated. ### `check_contributions` [`programs/fundraiser/src/instructions/checker.rs`](programs/fundraiser/src/instructions/checker.rs). -Lets the maker claim the funds. Requires `vault.amount >= amount_to_raise`. The CPI uses `new_with_signer` with the Fundraiser PDA's seeds because the vault is owned by the PDA. The Fundraiser account is closed (via the `close = maker` constraint) and its rent is refunded to the maker. +Lets the maker claim the funds. Requires `vault.amount >= amount_to_raise`. The CPI uses `new_with_signer` with the Fundraiser PDA's seeds because the vault is owned by the PDA. The Fundraiser account is closed (via the `close = maker` constraint) and its [rent](https://solana.com/docs/terminology#rent) is refunded to the maker. ### `refund` diff --git a/tokens/token-minter/README.md b/tokens/token-minter/README.md index 36902a3c3..b8d12b06f 100644 --- a/tokens/token-minter/README.md +++ b/tokens/token-minter/README.md @@ -2,7 +2,7 @@ Minting tokens is conceptually straightforward. The subtle part is understanding how Solana tracks per-user token balances. -Every account on Solana tracks its own balance of SOL. It can't possibly also track its own balance of every token on the network. Instead, token balances are held in separate accounts that are specific to a given mint and a given owner. These are called **Associated Token Accounts (ATAs)**. +Every [account](https://solana.com/docs/terminology#account) on Solana tracks its own balance of SOL. It can't possibly also track its own balance of every token on the network. Instead, token balances are held in separate accounts that are specific to a given [mint](https://solana.com/docs/terminology#token-mint) and a given owner. These are called **[Associated Token Accounts](https://solana.com/docs/terminology#associated-token-account-ata) (ATAs)**. To know what someone's balance of token JOE is, you would: diff --git a/tokens/token-swap/README.md b/tokens/token-swap/README.md index 434fe237b..0f753ccff 100644 --- a/tokens/token-swap/README.md +++ b/tokens/token-swap/README.md @@ -1,6 +1,6 @@ # Token Swap (AMM) -A Constant Product Automated Market Maker (AMM) in Anchor — the model popularized by Uniswap V2. +A Constant Product Automated Market Maker (AMM) in [Anchor](https://solana.com/docs/terminology#anchor) — the model popularized by Uniswap V2. The pool keeps `x * y = K` invariant: if `x` is the reserve of token A and `y` is the reserve of token B, then `x * y` stays constant for a given liquidity quantity. @@ -13,7 +13,7 @@ Other bonding-curve designs exist: - **Uniswap V3 Concentrated Liquidity AMM (CLAMM):** splits the curve into buckets; LPs supply liquidity to specific price ranges. - **Trader Joe CLAMM:** like Uniswap V3, but each bucket is a CSAMM. -A CPAMM is the simplest and the cheapest to keep in account state — one pool, one mint, easy to reason about. That's what this example implements. +A CPAMM is the simplest and the cheapest to keep in [account](https://solana.com/docs/terminology#account) state — one pool, one [mint](https://solana.com/docs/terminology#token-mint), easy to reason about. That's what this example implements. ## Design @@ -21,19 +21,19 @@ Requirements: - **Fee distribution.** Every pool charges a trading fee, paid in the traded token, that rewards LPs. To stay consistent across pools, the fee is shared. - **Single pool per asset pair.** Avoids liquidity fragmentation. -- **LP accounting.** The program tracks each LP's deposits. +- **LP accounting.** The [program](https://solana.com/docs/terminology#program) tracks each LP's deposits. Implementation choices: - **Shared parameters.** A single AMM account stores the shared trading-fee config and admin. Each pool then has its own account. -- **Unique pools.** Each pool is a PDA seeded from the AMM, `mint_a`, and `mint_b` (in that order, with `mint_a < mint_b`). +- **Unique pools.** Each pool is a [PDA](https://solana.com/docs/terminology#program-derived-address-pda) seeded from the AMM, `mint_a`, and `mint_b` (in that order, with `mint_a < mint_b`). - **LP accounting via tokens.** LP positions are tracked as tokens (the `mint_liquidity` mint), so they're composable with any wallet or downstream protocol. ## Onchain-design principles applied here - **Store keys in the account.** Even for PDAs, storing the parent keys in the account state makes lookups easier (you can rebuild the PDA without consulting external data) and works well with Anchor's `has_one` constraint. - **Keep seeds simple.** Start with the parent's seeds, then the current object's identifiers in alphabetical order. For the pool, that means `[amm, mint_a, mint_b]`. -- **Keep instruction scope small.** Smaller instructions touch fewer accounts, leaving room in the transaction and improving composability and security. +- **Keep [instruction](https://solana.com/docs/terminology#instruction) scope small.** Smaller instructions touch fewer accounts, leaving room in the transaction and improving composability and security. ## File structure @@ -76,7 +76,7 @@ Initializes an `Amm` account with the supplied `id`, `admin`, and `fee`. Enforce ### `create_pool` -Initializes a `Pool` account, an LP mint (`mint_liquidity`), and the two pool ATAs (`pool_account_a`, `pool_account_b`). Enforces `mint_a < mint_b` for canonical pool addressing. +Initializes a `Pool` account, an LP mint (`mint_liquidity`), and the two pool [ATAs](https://solana.com/docs/terminology#associated-token-account-ata) (`pool_account_a`, `pool_account_b`). Enforces `mint_a < mint_b` for canonical pool addressing. ### `deposit_liquidity` diff --git a/tokens/transfer-tokens/README.md b/tokens/transfer-tokens/README.md index b1a9f9b6b..56dc493b9 100644 --- a/tokens/transfer-tokens/README.md +++ b/tokens/transfer-tokens/README.md @@ -1,7 +1,7 @@ # Transfer Tokens -Like minting, token transfers happen between Associated Token Accounts. +Like minting, token transfers happen between [Associated Token Accounts](https://solana.com/docs/terminology#associated-token-account-ata). -Use the Classic Token Program's `transfer` instruction handler to move tokens, given the appropriate permissions. +Use the [Classic Token Program](https://solana.com/docs/terminology#token-program)'s `transfer` [instruction handler](https://solana.com/docs/terminology#instruction-handler) to move tokens, given the appropriate permissions. See [Token Minter](../token-minter) and [NFT Minter](../nft-minter) for more on Associated Token Accounts. diff --git a/tools/clockwork/README.md b/tools/clockwork/README.md index 18b909e12..aba2413ea 100644 --- a/tools/clockwork/README.md +++ b/tools/clockwork/README.md @@ -1,5 +1,5 @@ # Clockwork -[Clockwork](https://github.com/clockwork-xyz/clockwork) is automation infrastructure for Solana. It lets you schedule transactions and build automated, event-driven programs. +[Clockwork](https://github.com/clockwork-xyz/clockwork) is automation infrastructure for Solana. It lets you schedule transactions and build automated, event-driven [programs](https://solana.com/docs/terminology#program). See the upstream [Clockwork repository](https://github.com/clockwork-xyz/clockwork) for examples and documentation. diff --git a/tools/shank-and-solita/native/README.md b/tools/shank-and-solita/native/README.md index f36d801a4..9fc8c5509 100644 --- a/tools/shank-and-solita/native/README.md +++ b/tools/shank-and-solita/native/README.md @@ -1,12 +1,12 @@ # Shank and Solita -The Metaplex team built **Shank** and **Solita** so that native Solana programs can have serialization and IDL support similar to Anchor. +The Metaplex team built **Shank** and **Solita** so that native Solana [programs](https://solana.com/docs/terminology#program) can have serialization and IDL support similar to [Anchor](https://solana.com/docs/terminology#anchor). ## Shank [Shank](https://github.com/metaplex-foundation/shank) is a Rust crate that generates an IDL for your program. -Mark a struct as an account: +Mark a struct as an [account](https://solana.com/docs/terminology#account): ```rust #[derive(BorshDeserialize, BorshSerialize, Clone, ShankAccount)] @@ -17,7 +17,7 @@ pub struct Car { } ``` -Mark an enum as your instruction set: +Mark an enum as your [instruction](https://solana.com/docs/terminology#instruction) set: ```rust #[derive(BorshDeserialize, BorshSerialize, Clone, ShankInstruction)]