Here is a working fundraiser. Now make it yours.

anchor test builds, boots a local validator, deploys, and runs Mocha. Any of those four can be what broke:

• ANCHOR_PROVIDER_URL is not defined — you ran ts-mocha directly instead of through anchor test. Use anchor test, or export ANCHOR_PROVIDER_URL and ANCHOR_WALLET yourself.
• Address already in use — a validator is still running from last time. Kill it, or use anchor test --skip-local-validator against one you started yourself.
• A missing target/types/fundraiser.ts — anchor build generates it. Build before you test, every time.

The idea. Something happens the moment the vault crosses 25%, 50% and 75% of the target. What "something" is, is up to you: release a tranche of the money to the maker early, raise or lower the per-contributor cap, unlock a bonus for everyone who got in before the halfway mark, or simply emit an event a front end can listen for.

Difficulty: moderate. Best for: most people — it is the only option here with no external dependency and no clock problem.

State you need. One byte on Fundraiser. A bitmask is the tidy version:

pub milestones_fired: u8,   // bit 0 = 25%, bit 1 = 50%, bit 2 = 75%

Where it hooks. The end of contribute, after current_amount has been updated. Nothing else changes the total upward.

Second trap. refund reduces current_amount. Decide deliberately whether a milestone can un-fire, and write your decision in the README. ("Milestones are one-way; a refund does not retract one" is a perfectly good answer, and it is a better answer than not having thought about it.)

The idea. Contributing buys tickets in proportion to the amount. When the fundraiser succeeds, one ticket wins — a slice of the pot, a special NFT, bragging rights.

Difficulty: hard, and the hard part is not the code.

State you need. A running total_tickets on Fundraiser, and on Contributor the range of ticket numbers they own:

pub ticket_start: u64,
pub ticket_end: u64,     // exclusive

The real problem: randomness. Solana has none. Every value a program can read is a value the caller could read first, off-chain, before deciding whether to send the transaction at all. A naive draw from Clock means anyone can simulate, see that they lose, and simply not submit — then try again next slot.

Three answers, in increasing order of honesty:

• SlotHashes sysvar. Readable on-chain, contains recent block hashes, much better than Clock. Still influenced by whoever is producing blocks. Cheap and standard for low-stakes draws.
• Commit–reveal. The maker commits hash(secret) at initialize and reveals secret at draw time; the winner is derived from the secret combined with something the maker cannot control. The maker can refuse to reveal, so pair it with a deadline.
• A VRF — Switchboard or ORAO. This is what production does, and integrating one is a whole assignment by itself.

Pick one, implement it, and write down in your README exactly how it can be gamed. A correct description of your own scheme's weakness will score better than a scheme presented as secure that is not.

The idea. Your first contribution mints you a one-of-one token — proof you backed this campaign, held in your wallet, transferable or not as you choose.

Difficulty: moderate if you keep it simple, hard if you reach for Metaplex.

The simple version, and the one to start with: an NFT is just a mint with 0 decimals and a supply of exactly 1. Derive the mint as a PDA so you never have to store its address:

[b"receipt", fundraiser.key(), contributor.key()]

Mint authority is the fundraiser PDA. On a contributor's first contribution, create the mint and their ATA with init_if_needed, mint 1, and — if you want it to be a true one-of-one — set the mint authority to None afterwards so no more can ever exist.

The better version. You already did Token-2022 metadata in the last assignment. A receipt with a metadata_pointer back to itself, carrying a name and a URI, is a genuinely nice artifact and reuses work you have already done.

The ambitious version. Metaplex Token Metadata via CPI. Be warned that mpl-token-metadata and anchor-spl have version opinions about each other, and the program's dependencies are pinned to exactly =1.1.2 — so you may spend your afternoon in Cargo.toml rather than in your program.

The idea. Contribute 100 USDC, receive 100 (or 10, or 1,000) CAMPAIGN tokens. A governance token, a points balance, a claim on something later.

Difficulty: moderate, and the gentlest introduction to a PDA acting as a mint authority.

State you need. A reward_mint: Pubkey on Fundraiser, chosen at initialize, whose mint authority is the fundraiser PDA. Optionally a reward_rate if you do not want to hardcode it.

Where it hooks. contribute, right after the transfer into the vault succeeds.

Encouraged, and it has to clear the same bar. Ideas that have worked well:

• Matching funds. A sponsor deposits a pool at the start that matches contributions 1:1 up to a limit.
• Refund insurance. A small fee on each contribution funds a pool that pays contributors a little extra if the campaign fails.
• Tiers. Contribute above a threshold and you are a "founding backer" — recorded on-chain and unforgeable.
• An early-bird curve. Rewards that decay with time or with how full the vault already is.
• Multiple campaigns per maker. Add a campaign id to the seeds and work out everything that breaks.

Run it past your TA before you start. Not for permission — to catch the case where the idea is secretly three assignments, which is the most common way this goes wrong.

Seeds are how your program answers "which one of these is this?". The existing ones are a good model to copy:

[b"fundraiser", maker]                       // one per maker
[b"contributor", fundraiser, contributor]    // one per person per campaign

Read them as a sentence. "One X per Y per Z" — and the seeds are literally [b"x", y, z]. If you want one receipt per contributor per campaign, your seeds write themselves.

Include a literal prefix so two different kinds of account can never collide, and store the bump in the account so you are not paying for find_program_address on every instruction.

The feature is on in Cargo.toml, and contribute already uses it for the contributor account — which is how a second contribution from the same person reuses the first account instead of failing.

Use it, and remember what it does not do: it will not re-run your initialisation. An account that already exists arrives with its old contents, so any "set this up" logic you write has to be safe to skip, or guarded by a flag you check yourself. This is the single most common source of "it works the first time" bugs in Anchor.

Anything triggered by a condition rather than by a caller needs a "has this already happened" flag, because the condition stays true after the first time. A bool per event, or one u8 used as a bitmask for up to eight of them.

Set the flag before you do the work, not after. If the work is a CPI that fails, the whole instruction unwinds and the flag goes back with it — so ordering costs you nothing and protects you from the case where the work partially succeeds in some future version of your code.

Time-based features are harder to test than amount-based ones, and the difficulty has nothing to do with your program. anchor test runs against a real local validator whose clock is the real clock, and there is no RPC call that moves it. You cannot wait out a 14-day campaign in CI.

Your options are to trigger on amounts instead, to use a duration short enough to sit through, or to switch your tests to solana-bankrun, which can set the clock directly. Checkpoint 6 covers the third one. Decide now, because it is much cheaper than discovering it at the end.

Create the mint in initialize (for a campaign-wide reward token) or with init_if_needed in contribute (for a per-contributor receipt), with mint::authority = fundraiser. Then:

use anchor_spl::token::{mint_to, MintTo};

mint_to(
    CpiContext::new_with_signer(
        self.token_program.key(),
        MintTo {
            mint: self.reward_mint.to_account_info(),
            to: self.contributor_reward_ata.to_account_info(),
            authority: self.fundraiser.to_account_info(),
        },
        &signer_seeds,
    ),
    reward_amount,
)?;

For a true one-of-one, follow the mint with set_authority to None. An NFT whose mint authority still exists is a promise, not a guarantee.

The sysvar is too large for Anchor to deserialize, so you take it as an unchecked account pinned to the right address and read the bytes yourself:

/// CHECK: address-checked below; read as raw bytes
#[account(address = anchor_lang::solana_program::sysvar::slot_hashes::ID)]
pub slot_hashes: UncheckedAccount<'info>,

The first 8 bytes are the entry count; each entry after that is a slot (u64) followed by a 32-byte hash, most recent first. Take the bytes you want, hash them with something else, reduce modulo total_tickets.

And then write the paragraph in your README explaining that a block producer can influence this. The paragraph is the deliverable.

Milestones are much more useful if something can listen for them:

#[event]
pub struct MilestoneReached {
    pub fundraiser: Pubkey,
    pub quarter: u8,
    pub amount: u64,
}

emit!(MilestoneReached { fundraiser: self.fundraiser.key(), quarter, amount });

Events are program logs, not state. They are cheap, they show up in the transaction, and they are gone once nobody is indexing them — so emit them as well as recording what matters on-chain, never instead of it.

anchor test cannot move the clock. solana-bankrun can — it runs the program against an in-process bank instead of a validator, and lets you set the sysvar directly.

Both packages are already in package.json, so yarn install is all you need.

import { startAnchor, BankrunProvider } from "anchor-bankrun";
import { Clock } from "solana-bankrun";

const context = await startAnchor("", [], []);
const provider = new BankrunProvider(context);
anchor.setProvider(provider);

// ... run initialize and a contribution ...

const clock = await context.banksClient.getClock();
context.setClock(new Clock(
  clock.slot,
  clock.epochStartTimestamp,
  clock.epoch,
  clock.leaderScheduleEpoch,
  clock.unixTimestamp + 15n * 86_400n,   // fifteen days later
));

Every field is a bigint. Changing the clock affects everything from that point on, so create the campaign first and then move time — moving it first only changes what gets stamped into time_started.

Anchor regenerates the IDL on every build, so a field you added in Rust is available in TypeScript with no client work at all:

const account = await program.account.fundraiser.fetch(fundraiser);
assert.strictEqual(account.milestonesFired, 3);   // 25% and 50%

Anchor camel-cases field names on the way out. If the field is missing or undefined, you are running against a stale IDL — rebuild.

AnchorProvider.env() reads two environment variables that anchor test sets for you. Run anchor test rather than ts-mocha directly, or export them yourself:

export ANCHOR_PROVIDER_URL=http://127.0.0.1:8899
export ANCHOR_WALLET=~/.config/solana/id.json

Anchor resolves some accounts for you and refuses to let .accounts() set them. Use .accountsPartial({ ... }), which the shipped tests already do. If you copied a snippet from pre-0.30 docs, this is why it does not compile.

The IDL is regenerated by anchor build and the TypeScript types come from it. Rebuild, and check target/types/fundraiser.ts actually contains your field. Remember Anchor camel-cases on the way out: milestones_fired becomes milestonesFired.

You inserted a field in the middle of an account struct rather than appending it, and you are reading an account created before the change. Every byte after the insertion point has shifted.

Append the field instead. In tests, a fresh validator makes this invisible; on devnet it is permanent.

The seeds you passed do not derive the account you are signing for. Compare them against the derivation one element at a time — b"fundraiser", the maker's key, the bump — in that order, bump last, nothing extra.

If you are minting, check the mint's authority is actually the fundraiser PDA and not the maker.

Both minimums are in whole tokens, scaled by the mint's decimals. On a 6-decimal mint that is 1_000_000 raw units per token — so a contribution must be at least 1_000_000, and a target must be more than 3_000_000.

Contributions are also capped at 10% of the target per contributor, so a target of 30 tokens allows at most 3 tokens from any one person. If you are writing a test that needs to fill the vault, use several contributors.

The condition that triggered it is still true afterwards. Conditions do not consume themselves — you need a flag, checked and set in the same instruction. Checkpoint 4.

Then it is testing the program you already had. Usually one of: asserting the transaction succeeded rather than asserting on state; a try/catch with no assert.fail in the try; or reading a value that would have been that number anyway.

Deleting your own logic and watching the suite go red is the only way to know. Do it before you open the PR, not after someone asks.

It will not — anchor test uses a real validator and there is no RPC to set the time. Either make your trigger amount-based, use a duration short enough to wait out, or move the suite to solana-bankrun. Checkpoint 6 has the setup.