Ship a token that says what it is.

1 · Fork, clone, branch

# Fork on GitHub first (button, top right), then:
git clone https://github.com/<you>/solana-summer-t22.git
cd solana-summer-t22

git remote add upstream https://github.com/ASCorreia/solana-summer-t22.git
git remote -v   # origin = yours, upstream = theirs

git switch -c feat/token-metadata

2 · Write a .gitignore — this repo has none

cat > .gitignore <<'EOF'
/target
node_modules/
.anchor/
test-ledger/
*.log
EOF

Include this in your pull request. It is a genuine improvement to the repo and every future contributor benefits.

3 · Point ADMIN at your own wallet

constants.rs hardcodes a single admin address, and initialize refuses anyone else:

pub const ADMIN: Pubkey = pubkey!("AHYic562KhgtAEkb1rSesqS87dFYRcfXb4WwWus3Zc9C");

Meanwhile the test harness loads your local CLI wallet from ~/.config/solana/id.json and signs as the admin with it. Unless you happen to hold that exact key, every test fails immediately at init_config with Unauthorized — including tests you have not touched.

solana address        # copy this
# paste it into constants.rs as the ADMIN value

4 · Build, then test

anchor build
cargo test

All seven existing test files should pass once ADMIN is yours. If they do not, fix that before writing code — you cannot tell your breakage from the environment's otherwise.

There is no README. So part of the work is reading an unfamiliar codebase and deciding what is in scope.

The program

The forced instructions are the interesting ones. They work because the mint was created with the permanent delegate extension pointing at the authority PDA — so the program can move tokens it does not own. That is an extension doing something no ordinary token program could.

The three files that matter to you

What is missing

• No metadata. The mint has no name, symbol, or URI. That's step 1 of the challenge.
• No way to mint. Search the whole src/ tree for mint_to or associated_token and you get nothing. Tokens can be transferred and burned, but never created. That's step 3, and it is more work than it sounds.

The challenge asks for one extension besides metadata that fits your token's story, and why you picked it. So decide the story first. A concert ticket, a membership badge, a game currency, a stablecoin, a bond — each one implies different rules, and the extension is how you enforce them.

What Anchor will let you declare

This constrains your choice more than you would expect. Anchor 1.0 understands exactly six mint extensions inside #[account(init ...)]:

Why the bottom four are harder

Token-2022 requires most extensions to be initialized after the account is allocated but before InitializeMint runs. Anchor's init does allocation and initialization as one atomic step, so there is no gap to slip them into. Choosing one of those means abandoning init and creating the mint by hand — a real project, not a checkpoint.

Metadata is the exception, and understanding why is the point of checkpoint 3.

What this does. Puts a name, symbol, and image URI on the mint — stored in the mint account itself, not in some separate registry.

This is the part of Token-2022 that replaces Metaplex for simple cases. Instead of a separate metadata account owned by another program, the token carries its own.

Two pieces, and they are not the same thing

The metadata pointer is a fixed-size extension that says "my metadata lives at this address." You declare it in init, and you point it at the mint itself.

The metadata is the actual name, symbol, and URI. It is variable length — it depends on how long your strings are — which is exactly why init cannot allocate space for it.

Requirements

1. Add extensions::metadata_pointer::authority and ::metadata_address to the init constraint. The address is the mint itself.
2. Take name, symbol, uri as instruction arguments and forward them from lib.rs.
3. Work out how many bytes the metadata needs, and transfer enough lamports from the payer to cover rent at the new size.
4. Call token_metadata_initialize, signed by the authority PDA.

let signer_seeds: &[&[&[u8]]] = &[&[b"authority", &[ctx.bumps.authority]]];

If you picked from the declarative six, this is one line in the init constraint. That is not a shortcut — it is the payoff for having chosen well in checkpoint 2.

#[account(
    init,
    payer = payer,
    mint::decimals = 6,
    mint::authority = authority,
    mint::token_program = token_program,
    extensions::permanent_delegate::delegate = authority,
    extensions::metadata_pointer::authority = authority,
    extensions::metadata_pointer::metadata_address = mint,
    // your extension goes here
)]

Then justify it

Write down what your token is and why this extension makes it that. Two or three sentences. This is a graded part of the challenge, and it is the part that shows whether you understand what you built or just made the compiler happy.

A weak answer names the extension again in different words. A strong one describes a situation the token would face and what the extension does about it.

What this does. Creates a wallet's associated token account if it does not have one, then mints tokens into it.

There is no instruction for this in the repo — you are writing a new one. This is the largest single piece of work in the assignment.

What an ATA is

A wallet cannot hold tokens directly. Each wallet needs a separate token account per mint, and the associated token account is the one at a deterministic address derived from the wallet and the mint. That determinism is why anyone can send you tokens without asking you to create an account first — the address is computable.

Requirements

1. New file src/instructions/mint_to.rs, registered in instructions.rs and given a wrapper in lib.rs.
2. Gate it to config.admin, the same way initialize_mint does.
3. The recipient's ATA is created if missing — init_if_needed with the associated_token:: constraints.
4. Mint with a new_with_signer CPI, since the mint authority is the authority PDA.

anchor-lang = { version = "1.0.2", features = ["init-if-needed"] }

Adding name, symbol and uri to initialize_mint changes its serialized data, so every test that builds that instruction stops compiling. There are two places.

Keep init_mint's signature as it is and have it pass sensible defaults, then add a second helper that takes the strings. Six test files call init_mint and do not care about metadata; only your new test does. One change, no churn in files you are not working on.

The challenge names them, and they get progressively more interesting:

1. A successful mint. The mint is created and carries the metadata you asked for.
2. A base flow. Mint to two wallets, then move tokens between them. The ordinary life of your token.
3. An extension-specific assertion. Prove the extension you chose is actually doing something — a state change, a fee, a UI amount, or a failure that should happen.

Reading extensions back off the mint

The existing harness reads raw byte offsets, which works for base fields but not for extensions. For those, unpack properly:

use anchor_spl::token_2022::spl_token_2022::{
    extension::{BaseStateWithExtensions, StateWithExtensions},
    state::Mint as MintState,
};

let account = svm.get_account(&mint.pubkey()).unwrap();
let state = StateWithExtensions::<MintState>::unpack(&account.data)?;

From there, state.get_extension::<T>() for fixed-size extensions, and get_variable_len_extension::<TokenMetadata>() for the metadata.

let err = res.unwrap_err();
let logs = err.meta.logs.join("\n");
assert!(logs.contains("Unauthorized"), "got: {logs}");

1 · Take the ADMIN change back out

You pointed ADMIN at your own wallet in checkpoint 0. That must not go upstream. Restore the original value before you commit:

git checkout upstream/main -- programs/solana-summer-t22/src/constants.rs
git diff upstream/main -- programs/solana-summer-t22/src/constants.rs   # should be empty

Your tests will fail locally again after this. That is expected and correct — put your address back to keep working, and take it out again right before you push.

2 · Look before you stage

git status
git diff

3 · Commit in logical pieces

git add .gitignore
git commit -m "Add gitignore for build output"

git add programs/solana-summer-t22/src programs/solana-summer-t22/Cargo.toml
git commit -m "Add token metadata and mint-to instruction"

git add programs/solana-summer-t22/tests
git commit -m "Test metadata, minting to two wallets, and the close authority"

4 · Sync, push, open

git fetch upstream
git rebase upstream/main
git push -u origin feat/token-metadata

5 · The description carries your reasoning

## What
Adds token metadata (name, symbol, URI) to the mint, a close-authority
extension, and a mint_to instruction that creates the recipient's ATA.

## The token
<two or three sentences: what your token is, and why this extension
fits it. This is the part the challenge actually grades.>

## Notes
- TokenMetadata is variable length, so `init` cannot size the account for
  it. The handler tops up rent for the metadata before initializing it.
- `init_if_needed` is enabled for the ATA in mint_to. Safe here: the
  instruction is admin-gated and an ATA address is fully determined.
- Added a .gitignore — the repo had none, so `target/` was untracked.

## Testing
`anchor build && cargo test` — all existing tests pass, plus three new
ones covering the mint, a two-wallet mint-and-transfer flow, and an
extension-specific assertion.