anchor-audit 0.1.0

package/rules/031-reinitialization-attack.md

@@ -0,0 +1,50 @@
+# Rule 031: Reinitialization Attack
+
+**Severity:** High
+**Category:** Auth
+
+## Description
+An initialization instruction can be invoked more than once against the same account, resetting its state. If the account is already in use — holding a balance, an authority, or accumulated state — a second `init`-style call lets an attacker overwrite critical fields (e.g. reset the authority to themselves) or wipe accounting. Manual init flows that don't guard against re-entry, and `init_if_needed` used carelessly, are the usual culprits.
+
+## Vulnerable pattern
+```rust
+pub fn initialize(ctx: Context<Initialize>, authority: Pubkey) -> Result<()> {
+    let state = &mut ctx.accounts.state;
+    // No check whether `state` was already initialized — callable repeatedly
+    state.authority = authority;
+    state.balance = 0; // wipes any existing balance on re-call
+    Ok(())
+}
+```
+
+## Why this is dangerous
+After legitimate setup, the attacker calls `initialize` again, setting `authority` to their own key (taking over the account) or zeroing accounting fields to erase debts/balances. Because the account already exists and is owned by the program, only an explicit "already initialized" guard prevents the overwrite.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Initialize<'info> {
+    // `init` fails if the account already exists / has a discriminator
+    #[account(init, payer = payer, space = 8 + State::INIT_SPACE)]
+    pub state: Account<'info, State>,
+    #[account(mut)]
+    pub payer: Signer<'info>,
+    pub system_program: Program<'info, System>,
+}
+// For manual flows: require!(!state.is_initialized, ErrorCode::AlreadyInit);
+//                   state.is_initialized = true;
+```
+
+## Detection heuristic
+- "initialize"/"setup"/"create" handlers that write state without `init` or an `is_initialized` guard
+- `init_if_needed` on accounts whose re-initialization would reset sensitive fields (see Rule 033)
+- Authority/owner fields assignable by an instruction reachable more than once
+- Manual account creation followed by configuration that can be replayed
+
+## References
+- Coral sealevel-attacks — 4-initialization (https://github.com/coral-xyz/sealevel-attacks/tree/master/programs/4-initialization)
+- Solana program security course — reinitialization attacks (https://solana.com/developers/courses/program-security/reinitialization-attacks)
+- Anchor docs — init / init_if_needed (https://www.anchor-lang.com/docs/account-constraints)
+
+## Real-world exploits (if any)
+No single attributed public headline exploit; reinitialization is a standard high/critical finding in public audits, especially for config and authority accounts.

package/rules/032-closed-account-revival.md

@@ -0,0 +1,49 @@
+# Rule 032: Closed Account Revival
+
+**Severity:** High
+**Category:** Auth
+
+## Description
+The counterpart to Rule 010. An account "closed" by only draining its lamports keeps its data for the rest of the transaction and is garbage-collected only after the transaction ends. An attacker re-funds the account (sending it rent-exempt lamports in a later instruction of the same transaction, or before GC) so it survives, then reuses the stale-but-valid account in subsequent instructions that assume it was destroyed.
+
+## Vulnerable pattern
+```rust
+pub fn close(ctx: Context<Close>) -> Result<()> {
+    let acc = ctx.accounts.position.to_account_info();
+    let dest = ctx.accounts.owner.to_account_info();
+    **dest.try_borrow_mut_lamports()? += acc.lamports();
+    **acc.try_borrow_mut_lamports()? = 0; // data NOT zeroed, no closed marker
+    Ok(())
+}
+// Attacker, in the same tx: transfer rent-exempt lamports back to `position`,
+// then call an instruction that still treats `position` as a live, funded position.
+```
+
+## Why this is dangerous
+The revived account retains its old discriminator and field values, so type and owner checks still pass. The attacker double-claims rewards tied to a "closed" position, keeps using collateral that was supposed to be released, or replays one-time actions. The lamport drain alone is not a close.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Close<'info> {
+    #[account(mut, has_one = owner, close = owner)] // zeroes data + closed marker
+    pub position: Account<'info, Position>,
+    #[account(mut)]
+    pub owner: Signer<'info>,
+}
+```
+Anchor's `close` writes `CLOSED_ACCOUNT_DISCRIMINATOR`, so a revived account fails the discriminator check on next use.
+
+## Detection heuristic
+- Manual lamport-draining closes (see Rule 010) without zeroing data and writing a closed discriminator
+- Accounts that are "closed" in one instruction and read in another within plausible transaction flows
+- Reward/claim/one-time-action accounts closed without Anchor's `close` constraint
+- No re-check of discriminator/initialized flag on accounts that may have been closed
+
+## References
+- Coral sealevel-attacks — 9-closing-accounts (https://github.com/coral-xyz/sealevel-attacks/tree/master/programs/9-closing-accounts)
+- Solana program security course — closing accounts & revival (https://solana.com/developers/courses/program-security/closing-accounts)
+- Neodyme — Solana common pitfalls (https://neodyme.io/en/blog/solana_common_pitfalls/)
+
+## Real-world exploits (if any)
+No single attributed public headline exploit; account-revival is a well-documented critical pattern in the sealevel-attacks corpus and recurs in audits.

package/rules/033-init-if-needed-misuse.md

@@ -0,0 +1,66 @@
+# Rule 033: `init_if_needed` Misuse
+
+**Severity:** High
+**Category:** Auth
+
+## Description
+Anchor's `init_if_needed` initializes an account if it doesn't exist and otherwise loads it. It is convenient but dangerous: when the account already exists, the initialization body is skipped, so any field-setting logic placed in the handler runs against existing state — or, conversely, an attacker can pre-create the account so "needed" init never happens. Used without a follow-up guard, it enables reinitialization-style takeovers and state resets.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Deposit<'info> {
+    #[account(
+        init_if_needed,
+        payer = user,
+        space = 8 + Position::INIT_SPACE,
+        seeds = [b"position", user.key().as_ref()],
+        bump,
+    )]
+    pub position: Account<'info, Position>,
+    #[account(mut)]
+    pub user: Signer<'info>,
+    pub system_program: Program<'info, System>,
+}
+
+pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
+    // Runs every call. On an existing account this is fine; but if the
+    // handler (re)sets owner/authority here, it overwrites it each call.
+    ctx.accounts.position.owner = ctx.accounts.user.key();
+    ctx.accounts.position.amount += amount;
+    Ok(())
+}
+```
+
+## Why this is dangerous
+If sensitive fields are (re)assigned in the handler, a second caller's data can clobber the first's (when seeds aren't user-bound), or accumulated state is reset. When `init_if_needed` is enabled program-wide, every account it touches must be analyzed for reinitialization (Rule 031). Attackers also pre-create accounts to control which branch runs.
+
+## Fix pattern
+```rust
+pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
+    let position = &mut ctx.accounts.position;
+    // Only set identity once; never overwrite on subsequent calls.
+    if position.owner == Pubkey::default() {
+        position.owner = ctx.accounts.user.key();
+    } else {
+        require_keys_eq!(position.owner, ctx.accounts.user.key());
+    }
+    position.amount = position.amount.checked_add(amount).ok_or(ErrorCode::Overflow)?;
+    Ok(())
+}
+```
+Prefer a separate explicit `init` instruction where feasible; bind PDA seeds to the user.
+
+## Detection heuristic
+- `init_if_needed` anywhere — each use needs reinitialization analysis
+- Handlers that unconditionally assign identity/authority fields on an `init_if_needed` account
+- `init_if_needed` PDAs whose seeds are not bound to the calling principal
+- The `init-if-needed` Anchor feature enabled without per-account guards
+
+## References
+- Anchor docs — init_if_needed (https://www.anchor-lang.com/docs/account-constraints)
+- Solana program security course — reinitialization attacks (https://solana.com/developers/courses/program-security/reinitialization-attacks)
+- Sec3 — init_if_needed risks (https://www.sec3.dev/blog)
+
+## Real-world exploits (if any)
+No single attributed public exploit; `init_if_needed` misuse is a recurring high-severity audit finding and the reason the feature is gated behind a Cargo flag.

package/rules/034-missing-has-one.md

@@ -0,0 +1,55 @@
+# Rule 034: Missing `has_one` Relationship Enforcement
+
+**Severity:** High
+**Category:** Auth
+
+## Description
+A state account stores pubkeys describing its relationships (`owner`, `mint`, `vault`, `authority`), but the instruction doesn't enforce that the corresponding passed-in accounts actually match those stored fields. `has_one = x` makes Anchor assert `account.x == x.key()`. Omitting it (and not replacing it with an explicit check) lets an attacker pass a mismatched but otherwise-valid account.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Harvest<'info> {
+    #[account(mut)] // Farm stores `authority` and `reward_vault` — neither enforced
+    pub farm: Account<'info, Farm>,
+    pub authority: Signer<'info>,
+    #[account(mut)]
+    pub reward_vault: Account<'info, TokenAccount>,
+}
+
+pub fn harvest(ctx: Context<Harvest>) -> Result<()> {
+    // Uses farm.reward_vault implicitly, but reward_vault could be any account
+    // and authority could be anyone — no link to farm.authority is checked.
+    Ok(())
+}
+```
+
+## Why this is dangerous
+Without `has_one`, the signer need not be the farm's authority, and the reward vault need not be the farm's real vault. The attacker harvests someone else's farm, or redirects rewards to a vault they control, because the program trusts the passed accounts instead of the relationships recorded in state.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Harvest<'info> {
+    #[account(mut, has_one = authority, has_one = reward_vault)]
+    pub farm: Account<'info, Farm>,
+    pub authority: Signer<'info>,
+    #[account(mut)]
+    pub reward_vault: Account<'info, TokenAccount>,
+}
+```
+Each `has_one = field` requires a matching context account named `field` and asserts equality.
+
+## Detection heuristic
+- State structs with relationship pubkey fields (`authority`, `owner`, `mint`, `vault`, `pool`) whose instructions lack matching `has_one`
+- Accounts used in logic by reference to a stored pubkey but passed in unconstrained
+- Authority signers not tied to the state account via `has_one`/`address`/explicit check
+- `require_keys_eq!` checks that are present in some handlers but missing in siblings
+
+## References
+- Anchor docs — has_one constraint (https://www.anchor-lang.com/docs/account-constraints)
+- Solana program security course — account data matching (https://solana.com/developers/courses/program-security/account-data-matching)
+- Neodyme — Solana common pitfalls (https://neodyme.io/en/blog/solana_common_pitfalls/)
+
+## Real-world exploits (if any)
+No single attributed public headline exploit; missing relationship checks are among the most common high/critical audit findings (closely related to Cashio's unvalidated account chain).

package/rules/035-insecure-admin-transfer.md

@@ -0,0 +1,49 @@
+# Rule 035: Insecure Admin Transfer (No Acceptance Handshake)
+
+**Severity:** Medium
+**Category:** Auth
+
+## Description
+Transferring a privileged role (admin, owner, upgrade authority) in a single instruction that immediately sets the new authority is fragile: a typo or a wrong/uncontrolled address permanently locks out administration with no recovery. The safe pattern is a two-step handshake — the current admin *nominates* a pending admin, and the nominee must *accept* — so an unusable address can never take ownership.
+
+## Vulnerable pattern
+```rust
+pub fn set_admin(ctx: Context<SetAdmin>, new_admin: Pubkey) -> Result<()> {
+    // One-step: if new_admin is wrong or unowned, admin control is lost forever
+    ctx.accounts.config.admin = new_admin;
+    Ok(())
+}
+```
+
+## Why this is dangerous
+A single-step transfer to a mistyped address, an exchange deposit address, or a contract that can't sign irreversibly bricks every admin-gated function (pause, upgrade, fee changes, emergency withdrawal). There is no way to prove the new admin can actually sign before handing over control. This is a self-inflicted-loss and incident-response risk, not a direct theft vector.
+
+## Fix pattern
+```rust
+pub fn nominate_admin(ctx: Context<AdminOnly>, candidate: Pubkey) -> Result<()> {
+    ctx.accounts.config.pending_admin = candidate;
+    Ok(())
+}
+
+pub fn accept_admin(ctx: Context<AcceptAdmin>) -> Result<()> {
+    require_keys_eq!(ctx.accounts.config.pending_admin, ctx.accounts.candidate.key());
+    ctx.accounts.config.admin = ctx.accounts.candidate.key(); // candidate must sign
+    ctx.accounts.config.pending_admin = Pubkey::default();
+    Ok(())
+}
+```
+The `accept_admin` context requires `candidate: Signer`, proving control.
+
+## Detection heuristic
+- Admin/owner/authority fields reassigned in one instruction from an argument, with no `pending_*` field
+- Absence of a paired nominate/accept (or propose/claim) instruction set
+- Upgrade-authority or critical-role transfers without a signature from the incoming party
+- No `Pubkey::default()` / sanity guard on the new authority value
+
+## References
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+- Sec3 — privileged role management (https://www.sec3.dev/blog)
+- OpenZeppelin — Ownable2Step (concept reference) (https://docs.openzeppelin.com/contracts/4.x/api/access#Ownable2Step)
+
+## Real-world exploits (if any)
+No theft exploit; single-step authority transfers have caused permanent loss of admin control (bricked protocols) across ecosystems. Standard medium audit finding.

package/rules/036-missing-pause-guards.md

@@ -0,0 +1,50 @@
+# Rule 036: Missing Pause / Freeze Guards
+
+**Severity:** Low
+**Category:** Auth
+
+## Description
+Critical value-moving instructions (deposit, withdraw, swap, borrow) have no mechanism to be paused or frozen in an emergency. When a vulnerability or anomaly is detected in production, the team has no way to halt the affected paths short of an upgrade, which takes time and may not be possible if the program is immutable. A pause flag, gated to an admin/guardian, is a standard defense-in-depth control.
+
+## Vulnerable pattern
+```rust
+pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
+    // No pause check anywhere in the program; if an exploit is live,
+    // there is no way to stop withdrawals while a fix is prepared.
+    transfer_out(ctx, amount)
+}
+```
+
+## Why this is dangerous
+Lacking a circuit breaker turns a contained incident into a full drain: once exploitation begins, the team can only watch until an upgrade lands (and immutable programs can't even do that). A pause/freeze guard buys time to investigate, patch, and protect remaining funds. Its absence is a missing safety control rather than an exploitable bug by itself.
+
+## Fix pattern
+```rust
+#[account]
+pub struct Config { pub admin: Pubkey, pub paused: bool /* ... */ }
+
+pub fn set_paused(ctx: Context<AdminOnly>, paused: bool) -> Result<()> {
+    ctx.accounts.config.paused = paused; // admin/guardian gated
+    Ok(())
+}
+
+pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
+    require!(!ctx.accounts.config.paused, ErrorCode::Paused);
+    transfer_out(ctx, amount)
+}
+```
+Consider granular pausing (per-instruction) and a separate, fast-acting guardian role.
+
+## Detection heuristic
+- No `paused`/`frozen` field on the program's config/global state
+- Value-moving instructions with no `require!(!config.paused, ...)` guard
+- No admin/guardian instruction to toggle a pause
+- Immutable programs (upgrade authority burned) with no in-program emergency stop
+
+## References
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+- Sec3 — emergency controls and circuit breakers (https://www.sec3.dev/blog)
+- Solana program security best practices (https://solana.com/developers/courses/program-security)
+
+## Real-world exploits (if any)
+No exploit caused by this directly; in numerous incidents the absence of a pause turned a detectable exploit into a total loss. Common informational/low audit recommendation.

package/rules/037-clock-manipulation.md

@@ -0,0 +1,53 @@
+# Rule 037: Clock / Time-Based Logic Without Bounds
+
+**Severity:** Medium
+**Category:** Auth
+
+## Description
+Logic that depends on the Clock sysvar (`unix_timestamp` or `slot`) for vesting, auctions, cooldowns, TWAPs, or expiry must account for the fact that timestamps are validator-influenced and can drift, and that slot-to-time conversions are approximate. Using raw timestamps without sanity bounds, staleness checks, or monotonicity guards lets edge cases and minor manipulation skew time-sensitive outcomes.
+
+## Vulnerable pattern
+```rust
+pub fn claim_vested(ctx: Context<Claim>) -> Result<()> {
+    let now = Clock::get()?.unix_timestamp;
+    // Assumes `now` is exact and strictly increasing; no bounds, no
+    // check that start <= now, no guard against a recorded future time.
+    let elapsed = now - ctx.accounts.vest.start_ts;
+    let vested = ctx.accounts.vest.total * elapsed as u64 / ctx.accounts.vest.duration;
+    // ...
+    Ok(())
+}
+```
+
+## Why this is dangerous
+`unix_timestamp` can be slightly ahead of or behind real time and is not guaranteed strictly monotonic across the boundary cases the program may assume. If `now < start_ts`, `elapsed` underflows (Rule 023); unbounded `elapsed` can over-vest. For oracle/auction logic, even small timestamp influence lets a validator-adjacent actor nudge outcomes. Relying on time for high-value, fine-grained decisions is fragile.
+
+## Fix pattern
+```rust
+pub fn claim_vested(ctx: Context<Claim>) -> Result<()> {
+    let now = Clock::get()?.unix_timestamp;
+    let v = &ctx.accounts.vest;
+    require!(now >= v.start_ts, ErrorCode::NotStarted);
+    let elapsed = (now - v.start_ts).min(v.duration as i64) as u64; // clamp
+    let vested = (v.total as u128)
+        .checked_mul(elapsed as u128).ok_or(ErrorCode::Overflow)?
+        .checked_div(v.duration as u128).ok_or(ErrorCode::DivByZero)? as u64;
+    // ...
+    Ok(())
+}
+```
+Clamp ranges, reject out-of-order timestamps, and avoid time as the sole gate for high-value actions.
+
+## Detection heuristic
+- `Clock::get()?.unix_timestamp` / `slot` used in subtraction without a `now >= start` guard (underflow risk)
+- Time deltas not clamped to a maximum (over-vesting / over-accrual)
+- Slot-count used as wall-clock time via a hardcoded slot duration
+- Auction/oracle/expiry decisions gated solely on validator-influenced time
+
+## References
+- Solana docs — Clock sysvar and timestamp semantics (https://docs.solanalabs.com/runtime/sysvars#clock)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+- Sec3 — time-based logic pitfalls (https://www.sec3.dev/blog)
+
+## Real-world exploits (if any)
+No single attributed public Solana exploit; time-handling issues are recurring medium audit findings in vesting, auction, and oracle code.

package/rules/038-missing-address-validation.md

@@ -0,0 +1,53 @@
+# Rule 038: Missing `address` Validation on Fixed-Identity Accounts
+
+**Severity:** Medium
+**Category:** Constraints
+
+## Description
+Some accounts have a single correct value known at compile time or stored in config: a specific fee recipient, a known oracle, the protocol treasury, a particular program. When such an account is accepted without an `address = ...` constraint (or equivalent check), an attacker substitutes their own account, redirecting fees, feeding a fake oracle, or pointing the program at the wrong fixed dependency.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Swap<'info> {
+    // Fee should always go to the protocol treasury, but any account passes
+    #[account(mut)]
+    pub fee_recipient: Account<'info, TokenAccount>,
+    // Oracle should be a specific known account, but unvalidated
+    /// CHECK: price oracle
+    pub oracle: AccountInfo<'info>,
+    // ...
+}
+```
+
+## Why this is dangerous
+The attacker passes their own token account as `fee_recipient` and collects the protocol's fees, or supplies a fake `oracle` account with attacker-chosen prices that the program reads as authoritative (mispricing swaps/liquidations). Any account whose identity is supposed to be fixed but isn't pinned is an injection point.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Swap<'info> {
+    #[account(mut, address = config.treasury)]
+    pub fee_recipient: Account<'info, TokenAccount>,
+    /// CHECK: pinned to the configured oracle
+    #[account(address = config.oracle)]
+    pub oracle: AccountInfo<'info>,
+    pub config: Account<'info, Config>,
+    // ...
+}
+```
+For compile-time constants use `address = some_known_pubkey::ID`.
+
+## Detection heuristic
+- Accounts representing fixed dependencies (treasury, fee recipient, oracle, known program/account) without an `address =` constraint
+- Pubkeys stored in config but the corresponding account passed unconstrained
+- `/// CHECK:` accounts that are dereferenced for trusted data with no address pin
+- Fee/royalty destinations taken from instruction input rather than config
+
+## References
+- Anchor docs — address constraint (https://www.anchor-lang.com/docs/account-constraints)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+- Neodyme — Solana common pitfalls (https://neodyme.io/en/blog/solana_common_pitfalls/)
+
+## Real-world exploits (if any)
+No single attributed public exploit; unvalidated oracle/fee accounts are recurring medium/high audit findings, and fake-oracle injection underlies several DeFi price-manipulation incidents.

package/rules/039-constraint-evaluation-stage.md

@@ -0,0 +1,54 @@
+# Rule 039: Constraint Evaluation Stage (Pre- vs Post-State)
+
+**Severity:** Medium
+**Category:** Constraints
+
+## Description
+Anchor evaluates account constraints during account validation, before the instruction handler body runs. A `constraint = ...` expression therefore sees the *pre-handler* state of the accounts. Developers sometimes write constraints expecting them to hold after the handler mutates state, or place a critical invariant only in a constraint that is checked too early, leaving a window where the post-state violates the intended invariant.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Withdraw<'info> {
+    // Evaluated BEFORE the handler runs, so it validates the OLD balance,
+    // not the balance after the withdrawal. It does not guarantee the
+    // post-withdraw invariant the author intended.
+    #[account(mut, constraint = vault.balance >= MIN_RESERVE @ ErrorCode::ReserveBreached)]
+    pub vault: Account<'info, Vault>,
+    // ...
+}
+
+pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
+    ctx.accounts.vault.balance -= amount; // post-state never re-checked
+    Ok(())
+}
+```
+
+## Why this is dangerous
+The reserve check passes against the pre-withdrawal balance, then the handler withdraws an amount that breaches the reserve — the invariant the constraint was meant to protect is violated after the fact. Relying on a pre-state constraint to guard a post-state property is a logic gap an attacker exercises by choosing `amount` to slip through the early check.
+
+## Fix pattern
+```rust
+pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
+    let vault = &mut ctx.accounts.vault;
+    vault.balance = vault.balance.checked_sub(amount).ok_or(ErrorCode::Underflow)?;
+    // Re-check the invariant against POST-state, in the handler:
+    require!(vault.balance >= MIN_RESERVE, ErrorCode::ReserveBreached);
+    Ok(())
+}
+```
+Use constraints for pre-conditions; assert post-conditions explicitly in the handler.
+
+## Detection heuristic
+- `constraint = ...` expressions that reference balances/state the same handler mutates, intended as post-conditions
+- Invariants present only as account constraints but not re-asserted after mutation
+- Handlers that change a value a constraint depends on, with no post-mutation `require!`
+- Comments implying "after" semantics on a constraint (which always runs "before")
+
+## References
+- Anchor docs — constraint evaluation order (https://www.anchor-lang.com/docs/account-constraints)
+- The Anchor Book — constraints (https://book.anchor-lang.com/anchor_in_depth/the_accounts_struct.html)
+- Sec3 — Anchor constraint pitfalls (https://www.sec3.dev/blog)
+
+## Real-world exploits (if any)
+No single attributed public exploit; pre/post-state confusion is a subtle logic finding that appears in audits of programs with reserve/ratio invariants.

package/rules/040-realloc-zero-init.md

@@ -0,0 +1,53 @@
+# Rule 040: `realloc` Without Zero-Init
+
+**Severity:** Medium
+**Category:** Constraints
+
+## Description
+When an account is grown with `realloc`, the newly added bytes are not automatically zeroed unless zero-init is requested. If `realloc(..., zero_init = false)` is used to *increase* size, the new region may contain leftover data from a previous, larger allocation of that memory, which then deserializes into account fields as garbage or attacker-influenced values.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Grow<'info> {
+    #[account(
+        mut,
+        realloc = 8 + NewLayout::INIT_SPACE, // larger than before
+        realloc::payer = payer,
+        realloc::zero = false, // new bytes NOT zeroed
+    )]
+    pub state: Account<'info, NewLayout>,
+    #[account(mut)]
+    pub payer: Signer<'info>,
+    pub system_program: Program<'info, System>,
+}
+```
+
+## Why this is dangerous
+The new tail bytes can hold stale contents (from prior data at that memory, or non-deterministic leftovers), so newly-added fields deserialize to nonzero, unexpected values instead of clean defaults. Logic that assumes appended fields start at zero (counters, flags, balances) is then wrong from the first read, which an attacker may be able to steer.
+
+## Fix pattern
+```rust
+#[account(
+    mut,
+    realloc = 8 + NewLayout::INIT_SPACE,
+    realloc::payer = payer,
+    realloc::zero = true, // zero the newly-added bytes when growing
+)]
+pub state: Account<'info, NewLayout>,
+```
+Use `realloc::zero = true` whenever increasing size; `false` is only safe when shrinking or immediately overwriting the entire new region.
+
+## Detection heuristic
+- `realloc::zero = false` (or the raw `AccountInfo::realloc(new_len, false)`) on size *increases*
+- New fields appended via realloc that are read before being explicitly written
+- Manual `realloc` calls that don't memset the grown region to zero
+- Growth paths assuming default (zero) values for newly-added fields
+
+## References
+- Anchor docs — realloc constraint (https://www.anchor-lang.com/docs/account-constraints)
+- Solana docs — AccountInfo::realloc semantics (https://docs.rs/solana-program/latest/solana_program/account_info/struct.AccountInfo.html#method.realloc)
+- Sec3 — realloc safety (https://www.sec3.dev/blog)
+
+## Real-world exploits (if any)
+No single attributed public exploit; non-zeroed realloc is a documented medium audit finding for programs that grow accounts over time.

package/rules/041-missing-payer-on-init.md

@@ -0,0 +1,59 @@
+# Rule 041: `init` Without `payer` (or Wrong Payer)
+
+**Severity:** Low
+**Category:** Constraints
+
+## Description
+The `init` constraint requires a `payer` to fund the new account's rent-exemption. Beyond the compile/runtime requirement, the *choice* of payer matters: using a program-controlled or shared account as payer, or letting a payer fund accounts without their explicit signature, can drain the wrong party. The related defect is initializing accounts at someone else's expense or griefing a shared funding source.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct CreateEntry<'info> {
+    #[account(
+        init,
+        space = 8 + Entry::INIT_SPACE,
+        payer = treasury, // shared protocol account pays for anyone's account
+    )]
+    pub entry: Account<'info, Entry>,
+    #[account(mut)]
+    pub treasury: Account<'info, TokenAccount>, // not the caller
+    pub user: Signer<'info>,
+    pub system_program: Program<'info, System>,
+}
+```
+
+## Why this is dangerous
+If a shared/treasury account funds arbitrary user-created accounts, an attacker creates many accounts to drain the treasury's lamports (griefing / denial of funds). Conversely, a missing/incorrect payer makes legitimate initialization fail. The payer should normally be the caller who benefits, and must sign.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct CreateEntry<'info> {
+    #[account(
+        init,
+        space = 8 + Entry::INIT_SPACE,
+        payer = user, // the caller funds their own account
+        seeds = [b"entry", user.key().as_ref()],
+        bump,
+    )]
+    pub entry: Account<'info, Entry>,
+    #[account(mut)]
+    pub user: Signer<'info>,
+    pub system_program: Program<'info, System>,
+}
+```
+
+## Detection heuristic
+- `init` with `payer = <shared/treasury/PDA>` rather than the calling principal
+- `init` where the payer is not a `Signer` (mut) in the same context
+- Permissionless instructions that initialize accounts funded by a protocol-owned account
+- Account creation with no per-caller rate limiting funded from a common source
+
+## References
+- Anchor docs — init and payer (https://www.anchor-lang.com/docs/account-constraints)
+- The Anchor Book — init constraint (https://book.anchor-lang.com/anchor_in_depth/the_accounts_struct.html)
+- Solana docs — rent and account creation (https://solana.com/docs/core/fees#rent)
+
+## Real-world exploits (if any)
+No single attributed public exploit; treasury-funded-init griefing and payer misconfiguration are low/medium audit and robustness findings.

package/rules/042-incorrect-space-allocation.md

@@ -0,0 +1,53 @@
+# Rule 042: Incorrect `space` Allocation
+
+**Severity:** Medium
+**Category:** Constraints
+
+## Description
+The `space` value in an `init` constraint must exactly accommodate the 8-byte discriminator plus the serialized size of every field, including the worst-case length of variable-length fields (`String`, `Vec<T>`). Too small and writes either fail or, for fixed layouts computed by hand, corrupt adjacent data; mis-estimating variable-length capacity strands the account at a size that can't hold its intended contents.
+
+## Vulnerable pattern
+```rust
+#[account]
+pub struct Profile {
+    pub authority: Pubkey, // 32
+    pub name: String,      // 4 (len prefix) + N bytes
+    pub friends: Vec<Pubkey>, // 4 + 32 * count
+}
+
+#[account(init, payer = user, space = 8 + 32)] // forgot name + friends
+pub profile: Account<'info, Profile>,
+```
+
+## Why this is dangerous
+Under-allocating means later writes that grow the `String`/`Vec` fail (bricking updates) or require a separate realloc the program never performs. Hand-computed sizes that are wrong can also misalign serialization. Over-allocating wastes rent but is safe; under-allocating is the security/robustness problem, sometimes blocking critical paths like updating a record needed for withdrawal.
+
+## Fix pattern
+```rust
+#[account]
+#[derive(InitSpace)] // Anchor computes fixed-size contribution automatically
+pub struct Profile {
+    pub authority: Pubkey,
+    #[max_len(32)]            // cap variable-length fields explicitly
+    pub name: String,
+    #[max_len(50)]
+    pub friends: Vec<Pubkey>,
+}
+
+#[account(init, payer = user, space = 8 + Profile::INIT_SPACE)]
+pub profile: Account<'info, Profile>,
+```
+
+## Detection heuristic
+- Hand-written `space = 8 + <number>` literals not derived from `INIT_SPACE` / a documented size calc
+- Variable-length fields (`String`, `Vec`) with no `#[max_len]` and no accounting in `space`
+- `space` smaller than the sum of field sizes (32 per Pubkey, 8 per u64, 1 per bool/u8, 4 + content for collections)
+- Structs that gained fields without a corresponding `space` update
+
+## References
+- Anchor docs — space and InitSpace (https://www.anchor-lang.com/docs/space)
+- The Anchor Book — account size (https://book.anchor-lang.com/anchor_in_depth/the_accounts_struct.html)
+- Sec3 — account sizing pitfalls (https://www.sec3.dev/blog)
+
+## Real-world exploits (if any)
+No single attributed public exploit; incorrect space is a common correctness/availability finding, occasionally bricking update or close paths.