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?

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}:

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.