osec-solana-small

Anchor account validation signer missing

InvariantVault Withdraw.admin declared as AccountInfo instead of Signer — full vault drain

Impact

A privileged account field is declared as `AccountInfo<'info>` instead of `Signer<'info>`. Anchor performs no signature check on AccountInfo, so any caller who knows the privileged pubkey can pass it without holding the private key. Combined with a downstream pubkey-equality guard, this lets anyone impersonate the privileged role and execute the gated instruction — typically a full drain of whatever vault the role controls.

Layer 3 — Symbolic verification (Kani)

✓ Counterexample found (bug confirmed by symbolic execution)

Layer 4 — On-chain BPF reproduction

✓ Reproduced through deployed BPF instructions

SOL34-vault-withdraw-no-signer: exploit tx should have been rejected — admin did not sign but withdraw succeeded because admin is declared as AccountInfo<'info> instead of Signer<'info>. See programs/vault/src/lib.rs (Withdraw struct, admin field).

Recommendation

Change the field to `Signer<'info>` so the Solana runtime verifies the ed25519 signature before the instruction body executes. Pair it with an `#[account(address = ... @ ErrCode)]` constraint to enforce the pubkey match at the framework level. Drop the body-level pubkey-equality branch once the framework-level checks are in place — they become dead code.

Verification gates — post-patch machine checks

Result of running the proposed patch through Jelleo’s 5-gate verifier (unsigned, syntactic well-formedness, single-function scope, no new deps, tests still compile/pass).

Layer 2 — Concrete proof of concept (engine-direct)

#[test]
fn test_sol34_vault_withdraw_no_signer_fires() {
    // Read programs/vault/src/lib.rs line 113:
    //   `pub admin: AccountInfo<'info>,`
    //
    // `AccountInfo<'info>` does NOT carry an Anchor-enforced signer check.
    // `Signer<'info>`      DOES enforce that `AccountInfo::is_signer == true`
    //                      (i.e. the runtime verified the ed25519 signature).
    //
    // Set this to `true` once the field is changed to `Signer<'info>`.
    let admin_field_is_signer: bool = false; // ← AccountInfo, not Signer

    assert!(
        admin_field_is_signer,
        "BUG WITNESS: SOL34-vault-withdraw-no-signer — \
         `admin` in the `Withdraw` accounts struct is declared as \
         `AccountInfo<'info>` (programs/vault/src/lib.rs:113), not \
         `Signer<'info>`. Anchor does not verify a signature for \
         AccountInfo accounts, so any caller who knows the admin pubkey \
         can pass it without signing and satisfy the pubkey-equality check \
         at lines 41-46, bypassing the authorization gate and draining \
         the vault. Fix: change `pub admin: AccountInfo<'info>` to \
         `pub admin: Signer<'info>` in the Withdraw struct."
    );
}

Layer P3 — Proposed structural fix (patch diff)

Anchor's `Signer<'info>` wrapper enforces ed25519 signature verification at the framework level before the instruction body executes. Combining it with `#[account(address = config.admin)]` makes the framework check both the signature AND pubkey equality, rendering the body-level pubkey-equality branch dead code (kept for now to minimise diff surface).

--- a/programs/vault/src/lib.rs
+++ b/programs/vault/src/lib.rs
@@ -109,7 +109,12 @@ pub struct Deposit<'info> {

 #[derive(Accounts)]
 pub struct Withdraw<'info> {
-    /// CHECK: admin authority pubkey only checked against config.admin.
-    pub admin: AccountInfo<'info>,
+    /// Admin must sign the withdrawal AND match config.admin. Declaring
+    /// the field as `Signer<'info>` forces the Solana runtime to verify
+    /// the ed25519 signature before this instruction body executes; the
+    /// `address = ...` constraint then enforces that the signer's
+    /// pubkey equals the stored admin.
+    #[account(address = config.admin @ VaultError::Unauthorized)]
+    pub admin: Signer<'info>,
     #[account(mut, seeds = [b"config"], bump = config.bump)]
     pub config: Account<'info, VaultConfig>,
     #[account(mut, seeds = [b"vault"], bump = config.vault_bump)]

Anchor account validation has one missing

InvariantEscrow Cancel.maker not validated — anyone drains any escrow

Impact

An account on a privileged instruction is declared without a `has_one = <field>` constraint binding it to a signer or stored authority. Any caller can pass an arbitrary pubkey in that slot; the instruction body then trusts the unauthenticated value and (typically) transfers funds to it via `invoke_signed`. This is a permissionless drain of whatever vault the instruction controls.

Layer 3 — Symbolic verification (Kani)

✓ Counterexample found (bug confirmed by symbolic execution)

Layer 4 — On-chain BPF reproduction

✓ Reproduced through deployed BPF instructions

SOL35-escrow-cancel-maker-not-validated: exploit tx should have been rejected — admin/maker/owner did not sign / has_one missing / seeds invalid / owner check absent. See programs/escrow/src/lib.rs (Cancel struct: maker is AccountInfo with no has_one or Signer constraint).

Recommendation

Add `has_one = <authority_field> @ ErrCode::Unauthorized` to the account constraint. Make the authority field a `Signer<'info>` so a real signature is required. Anchor will then enforce both the signature and the pubkey-equality with the stored authority at the framework level, before the instruction body runs.

Verification gates — post-patch machine checks

Result of running the proposed patch through Jelleo’s 5-gate verifier (unsigned, syntactic well-formedness, single-function scope, no new deps, tests still compile/pass).

Layer 2 — Concrete proof of concept (engine-direct)

//! Layer-2 PoC for SOL35-escrow-cancel-maker-not-validated: Cancel struct declares
//! `maker: AccountInfo<'info>` with no signature check or `has_one` constraint,
//! allowing any caller to pass an arbitrary pubkey as `maker` and drain the vault.
//! Strategy: structural-assertion.

// SOURCE CITATION (verbatim from engine):
// programs/escrow/src/lib.rs:152-155
//
//     #[derive(Accounts)]
//     pub struct Cancel<'info> {
//         /// CHECK: maker is not validated against escrow.maker.
//         #[account(mut)]
//         pub maker: AccountInfo<'info>,   // ← BUG: should be Signer<'info> with has_one = maker
//
// BUG WITNESS:
//   1. `maker` is `AccountInfo<'info>`, not `Signer<'info>` — no signature is required
        // …setup truncated for brevity…

        assert!(
            cancel_maker_is_validated,
            "BUG WITNESS: SOL35-escrow-cancel-maker-not-validated — \
             the `maker` field in `Cancel` (programs/escrow/src/lib.rs:155) is \
             `AccountInfo<'info>` (not `Signer<'info>`) and the escrow account \
             constraint (lines 156-162) has no `has_one = maker`. \
             Any caller can pass an arbitrary pubkey as `maker`, causing \
             `invoke_signed` to transfer the full vault balance to that address \
             without the real maker's authorisation."
        );
    }

Layer P3 — Proposed structural fix (patch diff)

Two-pronged fix: (1) `maker: Signer<'info>` forces a real signature; (2) `has_one = maker` on the escrow account ties the signer's pubkey to `escrow.maker` stored at creation time. Anchor rejects any caller whose pubkey doesn't match the stored maker BEFORE the body executes.

--- a/programs/escrow/src/lib.rs
+++ b/programs/escrow/src/lib.rs
@@ -151,10 +151,11 @@ pub struct Take<'info> {

 #[derive(Accounts)]
 pub struct Cancel<'info> {
-    /// CHECK: maker is not validated against escrow.maker.
+    /// Maker must sign cancellation and match the escrow's stored maker.
     #[account(mut)]
-    pub maker: AccountInfo<'info>,
+    pub maker: Signer<'info>,
     #[account(
         mut,
+        has_one = maker @ EscrowError::Unauthorized,
         seeds = [b"escrow", escrow.maker.as_ref(), &escrow.escrow_id.to_le_bytes()],
         bump = escrow.bump,
     )]

Anchor account validation seeds missing

InvariantStaking Claim.stake not bound to signer — steal arbitrary users' rewards

Impact

A program-owned account on a privileged instruction is declared without `seeds = [...]` + `bump = ...` constraints. Anchor does not derive or check the account's PDA; the caller can pass any `Account<'info, T>` with the right discriminator, including one belonging to a different user. The instruction then reads/writes the wrong user's state. For reward-claim flows this means an attacker claims arbitrary users' accrued rewards into the attacker's wallet.

Layer 3 — Symbolic verification (Kani)

✓ Counterexample found (bug confirmed by symbolic execution)

Layer 4 — On-chain BPF reproduction

✓ Reproduced through deployed BPF instructions

SOL36-staking-claim-stake-not-bound: exploit tx should have been rejected — Claim context has no has_one = user or seeds binding on `stake`, allowing attacker to pass victim's stake account and drain rewards into their own wallet. See programs/staking/src/lib.rs (Claim struct, stake field missing constraint).

Recommendation

Add `seeds = [b"<tag>", <signer>.key().as_ref()]` and `bump = <account>.bump` to the account constraint so Anchor derives the canonical PDA from the signer's key. Optionally also add `has_one = <signer>` for defense in depth. The framework rejects any account whose address doesn't match the derived PDA.

Verification gates — post-patch machine checks

Result of running the proposed patch through Jelleo’s 5-gate verifier (unsigned, syntactic well-formedness, single-function scope, no new deps, tests still compile/pass).

Layer 2 — Concrete proof of concept (engine-direct)

//! Layer-2 PoC for SOL36-staking-claim-stake-not-bound: missing account binding
//! between `stake: Account<'info, StakeAccount>` and the signing `user` in the
//! `Claim` accounts struct.
//! Strategy: structural-assertion.
//!
//! SOURCE CITATION (verbatim from engine):
//! programs/staking/src/lib.rs:159-167
//!
//!     #[derive(Accounts)]
//!     pub struct Claim<'info> {
//!         #[account(mut)]
//!         pub user: Signer<'info>,
//!         #[account(mut)]                          // ← BUG: no seeds, no has_one
//!         pub stake: Account<'info, StakeAccount>,
//!         #[account(seeds = [b"pool"], bump = pool.bump)]
//!         pub pool: Account<'info, Pool>,
        // …setup truncated for brevity…
        assert!(
            constraints.stake_is_bound_to_user(),
            "BUG WITNESS: SOL36-staking-claim-stake-not-bound — \
             `stake: Account<'info, StakeAccount>` in the `Claim` accounts struct \
             (programs/staking/src/lib.rs:163-164) carries only `#[account(mut)]`. \
             It has neither `seeds = [b\"stake\", user.key().as_ref()]` nor \
             `has_one = user`. An attacker can pass any victim's StakeAccount and \
             claim their accrued rewards into the attacker's own `user` wallet. \
             Fix: add `has_one = user` OR derive the account as a PDA with \
             seeds that include the signer's key."
        );
    }

Layer P3 — Proposed structural fix (patch diff)

Three constraints together: `seeds = [b"stake", user.key().as_ref()]` anchors the account to the signer's PDA; `bump = stake.bump` lets Anchor verify the canonical bump; `has_one = user` is defense-in-depth in case the deserialised `stake.user` is ever trusted by callers outside this Accounts struct. Three checks pass for legitimate callers, fail for arbitrary stake accounts.

--- a/programs/staking/src/lib.rs
+++ b/programs/staking/src/lib.rs
@@ -162,7 +162,12 @@ pub struct Deposit<'info> {
 pub struct Claim<'info> {
     #[account(mut)]
     pub user: Signer<'info>,
-    #[account(mut)]
+    #[account(
+        mut,
+        seeds = [b"stake", user.key().as_ref()],
+        bump = stake.bump,
+        has_one = user @ StakingError::Unauthorized,
+    )]
     pub stake: Account<'info, StakeAccount>,
     #[account(seeds = [b"pool"], bump = pool.bump)]
     pub pool: Account<'info, Pool>,
@@ -202,5 +207,7 @@ impl StakeAccount {
 
 #[error_code]
 pub enum StakingError {
+    #[msg("unauthorized stake account does not belong to caller")]
+    Unauthorized,
     #[msg("arithmetic overflow")]
     Overflow,
 }

State machine clock monotonicity

InvariantStaking claim accepts past clock values, allowing inflated rewards

Impact

A state-machine update reads `Clock::get()?.unix_timestamp` and writes the value back into a stored timestamp field without checking that the new value is monotonically greater than the prior one. A `saturating_sub`-based elapsed-time calculation silently clamps to zero on regression but the program still overwrites the checkpoint, permanently lowering it. A subsequent legitimate update then computes elapsed-time across the regression window, paying out inflated rewards.

Layer 3 — Symbolic verification (Kani)

Proved safe under small-model bounds (no counterexample within those constraints)

Layer 4 — On-chain BPF reproduction

Inconclusive

Recommendation

Reject any call where `current_time < stored_timestamp` via `require!(current_time >= stored_timestamp, ErrCode::ClockRegression)` BEFORE computing elapsed-time and BEFORE writing the new checkpoint. Add `ClockRegression` to the error enum. On mainnet validator clocks are practically monotonic; the guard is defense-in-depth against test/dev environments and any future runtime change that loosens monotonicity.

Verification gates — post-patch machine checks

Result of running the proposed patch through Jelleo’s 5-gate verifier (unsigned, syntactic well-formedness, single-function scope, no new deps, tests still compile/pass).

Layer 2 — Concrete proof of concept (engine-direct)

#[test]
fn test_sol28_clock_not_monotonic_fires() {
    // -----------------------------------------------------------------------
    // Reproduce the exact logic from programs/staking/src/lib.rs lines 57-67
    // -----------------------------------------------------------------------

    // Simulate a stake record whose last_claim_ts was recorded at T=1_000.
    let last_claim_ts: i64 = 1_000;

    // Simulate clock drift / sysvar replay: the "current" clock is LESS
    // than the stored timestamp.
    let current_time: i64 = 900; // 100 seconds BEFORE last_claim_ts

    // --- Engine logic (verbatim reconstruction) ---
    // programs/staking/src/lib.rs:60
    let elapsed_seconds = (current_time.saturating_sub(last_claim_ts)) as u64;
        // …setup truncated for brevity…
        timestamp_is_monotonic,
        "BUG WITNESS: SOL28-clock-not-monotonic — \
         when current_time ({}) < last_claim_ts ({}), \
         `saturating_sub` silently returns elapsed=0 (programs/staking/src/lib.rs:60) \
         and then `stake_record.last_claim_ts = current_time` (line 67) \
         writes a SMALLER timestamp back into the account, \
         corrupting time-accounting. \
         The program must detect backwards-clock and return an error instead.",
        current_time,
        last_claim_ts,
    );
}

Layer P3 — Proposed structural fix (patch diff)

`require!(current_time >= stake_record.last_claim_ts, ClockRegression)` guards the existing `saturating_sub` AND the unconditional checkpoint write. The macro produces a typed Anchor error on violation so callers can distinguish this from arithmetic overflow.

--- a/programs/staking/src/lib.rs
+++ b/programs/staking/src/lib.rs
@@ -57,6 +57,15 @@ pub mod staking {
         let current_time = Clock::get()?.unix_timestamp;
         let stake_record = &mut ctx.accounts.stake;
         let pool_state = &ctx.accounts.pool;
+        // Reject any claim where the on-chain clock has regressed below
+        // the stake's last-claim checkpoint. Without this guard, the
+        // program would silently lower `last_claim_ts`, allowing the
+        // next claim's `elapsed_seconds` window to span the regression
+        // and pay out inflated rewards.
+        require!(
+            current_time >= stake_record.last_claim_ts,
+            StakingError::ClockRegression
+        );
         let elapsed_seconds = (current_time.saturating_sub(stake_record.last_claim_ts)) as u64;
         let payout_amount = pool_state
             .reward_rate
@@ -207,3 +216,5 @@
     #[msg("arithmetic overflow")]
     Overflow,
+    #[msg("on-chain clock regressed below last claim checkpoint")]
+    ClockRegression,
 }

Anchor close constraint missing

InvariantEscrow Cancel leaves the escrow account on-chain (rent locked, ID burned)

Impact

An instruction marks an account as completed/finalised but does not use Anchor's `close = <receiver>` constraint. The account stays on-chain forever with its discriminator intact: rent reserves are permanently locked, the `(maker, id)` tuple can never be reused because Anchor's `init` refuses to recreate an existing PDA, and the stale state is readable by any future instruction that references the PDA.

Layer 3 — Symbolic verification (Kani)

Proved safe under small-model bounds (no counterexample within those constraints)

Layer 4 — On-chain BPF reproduction

✓ Reproduced through deployed BPF instructions

SOL29-close-without-zeroing: state diverged — escrow account data[0..8] is [31, 213, 123, 187, 186, 22, 218, 155], expected CLOSED_ACCOUNT_DISCRIMINATOR [255,255,255,255,255,255,255,255] or account deleted. The cancel instruction does not zero the escrow account data before or after draining vault funds, allowing revival-via-realloc attack. See programs/escrow/src/lib.rs cancel handler (no close constraint).

Recommendation

Add `close = <receiver>` to the account constraint in the instruction that finalises the lifecycle. Anchor will return the rent to `<receiver>` and set the discriminator to `CLOSED_ACCOUNT_DISCRIMINATOR` (eight 0xFF bytes) atomically, freeing the address for future reuse and preventing revival-via-realloc attacks.

Verification gates — post-patch machine checks

Result of running the proposed patch through Jelleo’s 5-gate verifier (unsigned, syntactic well-formedness, single-function scope, no new deps, tests still compile/pass).

Layer 2 — Concrete proof of concept (engine-direct)

#[test]
fn test_sol29_close_without_zeroing_fires() {
    // ------------------------------------------------------------------
    // 1. Set up an escrow as it would exist on-chain after `create`.
    // ------------------------------------------------------------------
    let escrow = Escrow {
        maker: [1u8; 32],
        taker: [2u8; 32],
        amount: 1_000_000_000, // 1 SOL
        escrow_id: 42,
        bump: 254,
        vault_bump: 253,
        completed: false,
    };
    let initial_data = serialise_escrow(&escrow);

        // …setup truncated for brevity…
        !revival_possible,
        "BUG WITNESS (SOL29-close-without-zeroing — revival step): \
         An attacker who re-funds the escrow PDA ({} lamports) can revive \
         the account because discriminator bytes were not zeroed. \
         Anchor will deserialise the stale Escrow data (maker={:?}, amount={}) \
         on any subsequent instruction that references this PDA. \
         Source: programs/escrow/src/lib.rs — missing `close = maker` / \
         `close = taker` constraint in Cancel / Take account structs.",
        rent_exempt_lamports,
        &escrow.maker[..4],
        escrow.amount,
    );

Layer P3 — Proposed structural fix (patch diff)

Anchor's `close = maker` constraint atomically: (a) transfers the account's lamports back to `maker`, (b) sets the account's discriminator bytes to `CLOSED_ACCOUNT_DISCRIMINATOR` (0xFFFFFFFFFFFFFFFF), (c) zeroes the data. The address becomes available for a new escrow with the same `(maker, escrow_id)` tuple after the close.

--- a/programs/escrow/src/lib.rs
+++ b/programs/escrow/src/lib.rs
@@ -158,5 +158,6 @@
         has_one = maker @ EscrowError::Unauthorized,
         seeds = [b"escrow", escrow.maker.as_ref(), &escrow.escrow_id.to_le_bytes()],
         bump = escrow.bump,
+        close = maker,
     )]
     pub escrow: Account<'info, Escrow>,

Arithmetic saturating sub silent clamp

InvariantVault withdraw uses saturating_sub on total_deposits counter — silent desync

Impact

A balance-or-counter update uses `saturating_sub` instead of `checked_sub`. On underflow the value silently clamps to zero with no error, allowing the on-chain counter to drift out of sync with the actual lamports balance. Direct exploitability requires another path to the over-withdrawal (e.g. an admin-auth bypass), but the silent counter desync also breaks integrators who treat the counter as authoritative for off-chain accounting.

Layer 3 — Symbolic verification (Kani)

✓ Counterexample found (bug confirmed by symbolic execution)

Layer 4 — On-chain BPF reproduction

✓ Reproduced through deployed BPF instructions

SOL13-saturating-sub-on-security: saturating_sub silently capped total_deposits at 0 instead of rejecting the underflow (withdrew 1500000 but only 1000000 was deposited). The withdraw instruction must use checked_sub to fail loudly. See programs/vault/src/lib.rs: state.total_deposits = state.total_deposits.saturating_sub(amount);

Recommendation

Replace `saturating_sub` with `.checked_sub(amount).ok_or(ErrCode::Underflow)?` and add `Underflow` to the error enum so any inconsistency aborts loudly. Alternatively, remove the counter entirely if it duplicates information already trackable via the vault's lamports balance.

Verification gates — post-patch machine checks

Result of running the proposed patch through Jelleo’s 5-gate verifier (unsigned, syntactic well-formedness, single-function scope, no new deps, tests still compile/pass).

Layer 2 — Concrete proof of concept (engine-direct)

#[test]
fn test_sol13_saturating_sub_on_security_fires() {
    // --- Reproduce the vault's accounting state ---------------------------------
    // Simulate: vault was initialized, one user deposited 500 lamports.
    let mut total_deposits: u64 = 500;

    // An attacker (or a buggy code path) requests a withdrawal of 1_000,
    // which is MORE than the recorded total_deposits.
    let withdrawal_amount: u64 = 1_000;

    // --- Buggy path (what the program currently does) ---------------------------
    // programs/vault/src/lib.rs:
    //     state.total_deposits = state.total_deposits.saturating_sub(amount);
    let buggy_result = total_deposits.saturating_sub(withdrawal_amount);
    // saturating_sub clamps to 0 — no error is raised; the invariant is broken.

        // …setup truncated for brevity…
    assert!(
        !saturating_sub_gave_silent_zero,
        "BUG WITNESS: SOL13-saturating-sub-on-security — \
         programs/vault/src/lib.rs `withdraw`: \
         `state.total_deposits = state.total_deposits.saturating_sub(amount)` \
         silently set total_deposits to 0 when withdrawal_amount ({}) > \
         prior total_deposits (500). \
         A correct implementation must use `checked_sub` and return an error \
         on underflow to prevent silent accounting corruption.",
        withdrawal_amount
    );
}

Layer P3 — Proposed structural fix (patch diff)

`checked_sub` returns `None` on underflow; `.ok_or(VaultError::Underflow)?` converts to a typed Anchor error. The instruction now aborts with `Underflow` instead of silently storing zero, so any on-chain monitoring that watches `total_deposits` sees the abort instead of a corrupted counter.

--- a/programs/vault/src/lib.rs
+++ b/programs/vault/src/lib.rs
@@ -63,7 +63,15 @@
             authority_seeds,
         )?;
         let state = &mut ctx.accounts.config;
-        state.total_deposits = state.total_deposits.saturating_sub(amount);
+        // checked_sub fails loudly if a caller (only the admin via the
+        // signer gate above) somehow withdraws more than total_deposits
+        // tracks. Previously used saturating_sub which silently clamped
+        // to zero, desynchronising the counter from the actual vault
+        // lamports balance.
+        state.total_deposits = state
+            .total_deposits
+            .checked_sub(amount)
+            .ok_or(VaultError::Underflow)?;
         Ok(())
     }
 
@@ -146,4 +154,6 @@
     Unauthorized,
     #[msg("arithmetic overflow")]
     Overflow,
+    #[msg("arithmetic underflow")]
+    Underflow,
 }

Build hygiene workspace member missing manifest

InvariantWorkspace Cargo.toml declares a tests crate without shipping its manifest — repo unbuildable

Impact

The root `Cargo.toml` declares a workspace member that has no `Cargo.toml` of its own. `cargo build` and `cargo test` both abort with `error: failed to load manifest for workspace member` on a fresh clone. Downstream auditors, CI pipelines, and integrators cannot build the repo as shipped — a reproducibility / supply-chain hygiene defect rather than a runtime vulnerability.

Layer 3 — Symbolic verification (Kani)

—

Layer 4 — On-chain BPF reproduction

—

Recommendation

Either remove the empty member from `members = [...]` (recommended if the directory contains script-style integration tests with their own invocation), or add a real `Cargo.toml` to the member crate so Cargo can load it as a workspace member. Verify with `cargo build` on a fresh clone before tagging the next release.

Verification gates — post-patch machine checks

Result of running the proposed patch through Jelleo’s 5-gate verifier (unsigned, syntactic well-formedness, single-function scope, no new deps, tests still compile/pass).

Layer 2 — Concrete proof of concept

No PoC source on file

Layer P3 — Proposed structural fix (patch diff)

Removing the `tests` workspace member is preferred over creating a `tests/Cargo.toml` because the existing files in `tests/` (`functional/*.rs`) are integration-test sources without a crate manifest of their own. If a manifest is added later, the member can be reintroduced.

--- a/Cargo.toml
+++ b/Cargo.toml
@@ -1,4 +1,8 @@
 [workspace]
-members = ["programs/*", "tests"]
+# Previously declared `tests` as a workspace member but shipped no
+# `tests/Cargo.toml`, so `cargo build` failed on a fresh clone. The
+# `tests/` directory contains integration test sources without a crate
+# manifest; remove it from members until a manifest is added.
+members = ["programs/*"]
 resolver = "2"

 [profile.release]