Failure Modes

1. Execute with mismatched treasury

Scenario

An attacker supplies a treasury PDA derived from another DAO while keeping the proposal valid.

Trigger

`execute_proposal` with a valid-looking but semantically wrong treasury account.

Expected Safe Outcome

The instruction must fail before execution effects occur.

Verified Protection

• treasury account is seed-bound to the supplied DAO
• proposal is `has_one = dao`
• failed path leaves `is_executed = false`

Reference:

• `tests/full-flow-test.ts`

Remaining Risk

No direct protocol gap observed in this path.

2. Finalize using wrong dao context

Scenario

A permissionless finalizer submits a correct proposal with an incorrect DAO account.

Trigger

`finalize_proposal` with mismatched `dao` / `proposal`.

Expected Safe Outcome

The instruction fails on seed or `has_one` validation and proposal fields remain unchanged.

Verified Protection

• proposal PDA is DAO-bound
• failed finalize leaves status and unlock fields unchanged

Reference:

• `tests/full-flow-test.ts`

Remaining Risk

No direct protocol gap observed in this path.

3. Reveal using wrong voter

Scenario

An attacker attempts to reveal another voter’s commit.

Trigger

`reveal_vote` signed by a different signer than the voter or authorized keeper.

Expected Safe Outcome

The reveal is rejected and tallies remain unchanged.

Verified Protection

• `revealer` must equal voter or keeper
• mismatched reveal signer rejected

Reference:

• `tests/private-dao.ts`

Remaining Risk

Metadata timing remains observable even when vote content stays hidden.

4. Commit using stale or cross-proposal delegation

Scenario

A delegatee tries to consume a delegation PDA that belongs to another proposal.

Trigger

`commit_delegated_vote` with a valid delegation account from the wrong proposal.

Expected Safe Outcome

The instruction fails and the delegation remains unused.

Verified Protection

• delegation PDA is proposal-bound
• failed delegated commit does not set `is_used`

Reference:

• `tests/private-dao.ts`

Remaining Risk

Direct/delegated overlap is now rejected on-chain through proposal-bound vote and delegation marker accounts. Product surfaces still mirror that same check for clearer operator feedback.

5. Replay execution attempt

Scenario

An attacker replays execute after a successful treasury transfer.

Trigger

A second `execute_proposal` call with the same proposal.

Expected Safe Outcome

The second call is rejected and no second transfer occurs.

Verified Protection

• `AlreadyExecuted`
• treasury delta asserted to match only one execution

Reference:

• `tests/full-flow-test.ts`

Remaining Risk

No duplicate execution path is currently observed in tests.

6. Malformed but valid-looking token accounts

Scenario

An attacker supplies initialized token accounts with incorrect mint, owner, or source semantics.

Trigger

`SendToken` execution with wrong destination owner, wrong mint, duplicate source/destination, or non-treasury source ownership.

Expected Safe Outcome

Execution fails before any token transfer and proposal remains unexecuted.

Verified Protection

• recipient owner match
• mint match on source and destination
• treasury ownership match
• source/destination non-duplication
• `is_executed` remains false on failed paths

Reference:

• `tests/full-flow-test.ts`

Remaining Risk

No direct protocol gap observed in this path.

7. Partial execution attempt

Scenario

A treasury execute path fails after lifecycle checks but before intended funds transfer.

Trigger

Miswired execute path or invalid treasury account arrangement.

Expected Safe Outcome

No partial treasury movement and no lifecycle advancement.

Verified Protection

• failed execute paths are asserted to preserve `is_executed`
• balances and status remain stable until a successful execute

Reference:

• `tests/full-flow-test.ts`

Remaining Risk

Relies on Solana transaction atomicity as a trust assumption.

8. Cross-proposal voter-record misuse

Scenario

A voter record from Proposal A is supplied to Proposal B.

Trigger

`commit_vote` with a PDA derived from another proposal.

Expected Safe Outcome

Seed validation failure before vote state mutates.

Verified Protection

• vote record PDA includes proposal key

Reference:

• `tests/private-dao.ts`

Remaining Risk

No direct protocol gap observed in this path.

9. Authority substitution attempt

Scenario

A non-authority attempts an authority-only action, or a valid signer attempts permissionless action with wrong authority-related context.

Trigger

`cancel_proposal`, `veto_proposal`, or confused binding around finalize/execute contexts.

Expected Safe Outcome

Authority-only paths reject the signer; permissionless paths still reject wrong account context.

Verified Protection

• `has_one = authority`
• DAO/proposal/treasury binding checks

Reference:

• `programs/private-dao/src/lib.rs`
• `tests/full-flow-test.ts`

Remaining Risk

Authority-only paths are logic-protected, but explicit authority misuse tests are thinner than execute/finalize path tests.

10. Invalid PDA substitution

Scenario

An attacker uses valid initialized accounts that are not the exact PDAs expected by the protocol.

Trigger

Substitution against proposal, voter record, delegation, or treasury.

Expected Safe Outcome

Seed or relationship constraints fail before any state mutation.

Verified Protection

• PDA seeds tie accounts to DAO/proposal/voter/delegator relationships

Reference:

• `tests/private-dao.ts`
• `tests/full-flow-test.ts`

Remaining Risk

No direct protocol gap observed in tested substitution paths.