plamentsv/semi-trusted-roles

Skill: Semi-Trusted Role Analysis (Solana)

Trigger Pattern: Crank/bot/operator signer checks, authority-gated instructions Inject Into: Breadth agents, depth-state-trace Finding prefix: [STR-N] Rules referenced: S1, S3, S9, R2, R6, R10, R13

crank|bot|operator|keeper|authority|admin|has_one\s*=\s*authority|
constraint\s*=\s*.*signer|role|guardian|relayer

Reasoning Template

Step 1: Inventory Role Permissions

• In {CONTRACTS}, find all instructions callable by {ROLE_NAME}
• For each instruction at {ROLE_FUNCTIONS}:
  • What accounts does it modify (mutable accounts)?
  • What CPI calls does it make?
  • What instruction data parameters does it accept?
  • Is the signer validated via has_one, Signer type, or custom constraint?

| Instruction | Signer Check | Mutable Accounts | CPI Calls | Parameters | |-------------|-------------|------------------|-----------|------------|

Step 2: Analyze Within-Scope Abuse

For each permitted action, ask:

Timing Abuse (400ms slots):

• Can {ROLE_NAME} execute at harmful times? (front-run users via MEV bundles or priority fee ordering, during epoch transitions)
• Can {ROLE_NAME} delay execution to harm users? (skip slots, withhold cranking)
• With 400ms slot times, timing windows are ~30x tighter than EVM - but MEV bundles enable precise ordering

Parameter Abuse:

• Can {ROLE_NAME} pass harmful instruction data? (max slippage, wrong recipient pubkey, inflated amounts)
• Are instruction parameters validated via Anchor constraints, or trusted implicitly?
• Can {ROLE_NAME} supply attacker-controlled accounts in remaining_accounts?

Sequence Abuse:

• Can {ROLE_NAME} execute instructions out of order? (claim before distribute, settle before finalize)
• Can {ROLE_NAME} skip required instructions? (skip epoch advancement, skip oracle update)

Omission Abuse:

• Can {ROLE_NAME} harm users by NOT cranking? (skip reward distribution, delay settlement)
• What is the protocol degradation timeline if crank stops? (1 slot? 1 epoch? indefinite?)

Step 3: Model Attack Scenarios

Scenario A: Timing Attack (MEV Bundle)
1. {ROLE_NAME} monitors pending transactions in mempool
2. {ROLE_NAME} creates MEV bundle: [role_instruction, user_instruction]
3. Role instruction executes first within same slot, changing state
4. User instruction executes with worse conditions
5. Impact: {TIMING_IMPACT}

Scenario B: Parameter Attack
1. {ROLE_NAME} calls {ROLE_INSTRUCTION} with {MALICIOUS_PARAMS}
2. Instruction data is not validated against {EXPECTED_CONSTRAINTS}
3. Impact: {PARAM_IMPACT}

Scenario C: Key Compromise
1. {ROLE_NAME} keypair is compromised
2. Attacker can call: {ROLE_FUNCTIONS}
3. Maximum extractable value: {MAX_DAMAGE}
4. Recovery: {RECOVERY_PATH} - can authority be rotated? Timelock?

Step 4: Assess Mitigations

• Is there a timelock on {ROLE_NAME} actions? (multi-instruction sequence with delay)
• Is {ROLE_NAME} a multisig (Squads, Snowflake)?
• Does a removal/rotation function for {ROLE_NAME} EXIST? If NO -> FINDING: authority is irrevocable without program upgrade. Severity: minimum Medium if role can modify user-facing state.
• Can admin rotate {ROLE_NAME} authority quickly?
• Are there rate limits, cooldowns, or per-slot caps?
• Is the program immutable (upgrade authority revoked)? If so, can a compromised role be replaced at all?

Step 5: Model User-Side Exploitation (Direction 2 - MANDATORY)

Predictability Analysis:

• Is the crank's behavior predictable? (epoch boundaries, price movements, queue-processing cadence)
• Can users observe when the crank will act? (monitoring on-chain state, slot timing)
• Can users front-run or back-run the crank via MEV bundles or priority fees?

Scenario D: User Exploits Crank Timing

1. User observes that {ROLE_NAME} executes {ROLE_INSTRUCTION} at predictable times
2. User submits transaction with high priority fee to land BEFORE crank in same slot
3. {ROLE_INSTRUCTION} executes, changing state (e.g., reward distribution, rate update)
4. User benefits from known state change
5. Impact: {USER_EXPLOIT_IMPACT}

Scenario E: User Griefs Crank Preconditions

1. {ROLE_INSTRUCTION} requires account state: {PRECONDITION}
2. User manipulates account state to violate {PRECONDITION}
3. {ROLE_NAME} sends transaction, instruction fails
4. Protocol enters degraded state (no crank actions possible)
5. Impact: {GRIEF_IMPACT}

Scenario F: User Forces Suboptimal Crank Action

1. {ROLE_NAME} must choose between options based on on-chain state
2. User manipulates state (deposits/withdrawals) to make worst option appear best
3. {ROLE_NAME} (following honest behavior) chooses suboptimal path
4. User profits from forced suboptimal execution
5. Impact: {SUBOPTIMAL_IMPACT}

Scenario G: Same-Chain Rate Staleness via Discrete Updates

1. Protocol's exchange rate only updates when {ROLE_NAME} cranks (discrete updates)
2. Between crank calls, rate is stale (does not reflect accumulated value)
3. User monitors for {ROLE_NAME} pending transaction
4. User enters at stale rate (favorable), crank executes, rate updates
5. User exits at updated rate (or holds appreciating position)
6. Impact: {RATE_ARBIT_IMPACT}

Step 6: Precondition Griefability Check

For each instruction callable by {ROLE_NAME}:

| Instruction | Preconditions | User Can Manipulate? | Grief Impact | |-------------|--------------|---------------------|--------------| | {ix} | account balance > 0 | YES - withdraw all | Crank stuck | | {ix} | Clock timestamp > last_crank + interval | NO - time-based | N/A | | {ix} | threshold met | YES - partial withdraw | Delayed execution |

CU budget griefing: Can a user submit CU-heavy transactions to fill the leader's block and delay crank execution? Priority fee escalation can push crank costs above economic viability.

Step 6b: Admin/Privileged Instruction Griefability (EXHAUSTIVE)

Enumerate ALL authority-gated instructions across the program:

| Instruction | Authority Type | Preconditions | User Can Manipulate? | Grief Impact | |-------------|---------------|--------------|---------------------|--------------| | {admin_ix} | {owner/admin/operator} | {preconditions} | YES/NO | {impact} |

Enumeration completeness check:

• [ ] Total authority-gated instructions in program: {N}
• [ ] Instructions analyzed in this table: {M}
• [ ] If M < N -> INCOMPLETE - analyze missing instructions before proceeding

Solana-specific checks:

• Can users create PDA accounts that block admin operations? (unexpected PDA state preventing closure/migration)
• Can users create token accounts owned by the protocol PDA that block operations? (non-zero balances preventing account closure)
• Can users initiate multi-instruction operations (partial unstake, pending withdrawal) whose in-flight state blocks admin actions?
• Can a user create so many accounts that iterating over them exceeds CU limits for admin instructions?

Common False Positives

• View-only / read instructions: If role only reads state, no abuse vector
• Idempotent instructions: If calling twice has same effect as once, timing abuse is limited
• User-initiated dependency: If role action requires user to initiate first, front-running may not apply
• Economic alignment: If crank is economically aligned (staked collateral, tip-funded), malicious action has cost

Finding Template

**ID**: [STR-N]
**Severity**: Critical/High/Medium/Low/Info
**Step Execution**: (see below)
**Rules Applied**: [S1:___, S3:___, S9:___, R2:___, R6:___, R10:___, R13:___]
**Location**: programs/{program}/src/instructions/{file}.rs:LineN
**Title**: {what role can do / what user can exploit}
**Description**: {specific abuse vector with code reference}
**Impact**: {quantified damage at worst-state parameters}

---

Step Execution Checklist (MANDATORY)

| Step | Required | Completed? | Notes | |------|----------|------------|-------| | 1. Inventory Role Permissions | YES | | | | 2. Analyze Within-Scope Abuse | YES | | | | 3. Model Attack Scenarios (A,B,C) | YES | | | | 4. Assess Mitigations | YES | | | | 5. Model User-Side Exploitation (D,E,F,G) | YES | | MANDATORY -- never skip | | 6. Precondition Griefability Check | YES | | MANDATORY -- never skip | | 6b. Admin Instruction Griefability | YES | | MANDATORY -- never skip |

Cross-Reference Markers

After Step 4: DO NOT STOP HERE -- Steps 5-6 analyze the reverse direction. After Step 5: Cross-reference with TOKEN_FLOW_TRACING for token-related griefing vectors. IF crank actions are predictable -> document Jito MEV vectors. After Step 6: IF any precondition is user-griefable -> severity >= MEDIUM. Document protocol degradation timeline if crank is blocked.

Output Format for Step Execution

**Step Execution**: check1,2,3,4,5,6,6b | (no skips for this skill)