Semi Trusted Roles

Skill: Semi-Trusted Role Analysis (Sui)

Trigger Pattern: SEMI_TRUSTED_ROLE flag (required) Inject Into: Breadth agents, depth-state-trace Purpose: Analyze capability-based privilege model in Sui Move protocols for both role-to-user and user-to-role attack vectors

Trigger Patterns

AdminCap|OwnerCap|TreasuryCap|OperatorCap|KeeperCap|GovernanceCap|
MinterCap|ManagerCap|UpgradeCap|PublisherCap|has_cap|assert_cap|
capability|cap_check|admin_only

Reasoning Template

Step 1: Inventory Role Permissions

Enumerate ALL capability objects in the protocol:

Sui capability model:

• Capabilities are owned objects. Holding the object = having the role.
• key ability: object can exist on-chain. Transferred with transfer::transfer (module-only) or transfer::public_transfer (if also has store).
• key + store: freely transferable by anyone. High risk -- capability can be sent to arbitrary addresses.
• key only: transferable only by the defining module's functions. Lower risk -- controlled transfer.
• Capabilities are checked by reference: fun admin_action(cap: &AdminCap, ...) -- presence of reference proves ownership.

For each capability at {CAPABILITY_OBJECTS}:

• What state does it grant access to modify?
• What external calls does it authorize?
• What parameters does it allow setting?
• Is the capability shared (share_object) or owned? Shared caps are NOT single-holder.

Step 2: Analyze Within-Scope Abuse

For each permitted action, ask:

Timing Abuse:

• Can {ROLE_NAME} execute at harmful times? (front-run users via shared object contention, during rebalance)
• Can {ROLE_NAME} delay execution to harm users? (withhold keeper actions)

Parameter Abuse:

• Can {ROLE_NAME} pass harmful parameters? (max slippage, wrong recipient, extreme fee)
• Are parameters validated against bounds, or trusted implicitly?

Sequence Abuse:

• Can {ROLE_NAME} execute operations out of order?
• Can {ROLE_NAME} skip required operations in a multi-step flow?

Omission Abuse:

• Can {ROLE_NAME} harm users by NOT acting? (skip price update, delay distribution, not calling keeper function)

Step 3: Model Attack Scenarios

Scenario A: Timing Attack
1. {ROLE_NAME} monitors pending transactions on shared objects
2. {ROLE_NAME} submits transaction to modify shared object state
3. Due to Sui's object-based execution, contention determines ordering
4. User's transaction executes with worse conditions
5. Impact: {TIMING_IMPACT}

Scenario B: Parameter Attack
1. {ROLE_NAME} calls {ROLE_FUNCTION} with {MALICIOUS_PARAMS}
2. Parameters are not validated against {EXPECTED_CONSTRAINTS}
3. Impact: {PARAM_IMPACT}

Scenario C: Key Compromise / Capability Theft
1. {ROLE_NAME} capability object is transferred to attacker
2. If cap has `store` ability: attacker can receive it via `transfer::public_transfer`
3. Attacker can call: {ROLE_FUNCTIONS}
4. Maximum extractable value: {MAX_DAMAGE}
5. Recovery options: {RECOVERY_PATH}
   - Can a higher-level cap revoke or re-create the compromised cap?
   - Is there an UpgradeCap that can patch the module?

Scenario C2: Shared Capability Abuse
1. {ROLE_NAME} capability is a shared object (created via `transfer::share_object`)
2. ANY user can include the shared cap in their PTB as `&SharedCap` reference
3. Attacker calls admin functions by passing the shared cap reference
4. Attacker can atomically compose admin operations with exploitation in a single PTB
5. Maximum extractable value: {MAX_DAMAGE}
6. NOTE: Shared caps effectively give EVERYONE the admin role -- this is almost always a critical finding

Step 4: Assess Mitigations

Does a removal/revocation function for {ROLE_NAME} EXIST? If NO -> FINDING: capability is irrevocable without module upgrade. Severity: minimum Medium if cap can modify user-facing state.

Capability transfer control:

• If cap has store: anyone holding it can transfer freely. Is this intended?
• If cap has only key: only module functions can transfer. Are those functions properly access-controlled?
• Is there a destroy function for the capability? If NO and cap has store: it can never be burned.
• Is the capability frozen (immutable via transfer::freeze_object)? Frozen caps can be read (&Cap) but not consumed or mutated -- limits authorized actions to read-only gating.

PTB composition risk: Can the capability holder compose a PTB that atomically: (1) changes parameters via admin function, (2) exploits the changed parameters via user function? If YES and cap is owned by a semi-trusted role -> the role can atomically manipulate + exploit without time for users to react.

Step 5: Model User-Side Exploitation (Reverse Direction)

Predictability Analysis:

• Is the role's behavior predictable? (scheduled tasks, triggered by events, epoch-based)
• Can users observe when the role will act via on-chain state?
• Can users front-run or back-run the role's actions via shared object contention?

Scenario D: User Exploits Keeper Timing

1. User observes that {ROLE_NAME} executes {ROLE_ACTION} at predictable times (e.g., epoch boundaries)
2. User positions themselves before {ROLE_ACTION} (deposit/stake before reward distribution)
3. {ROLE_ACTION} executes, changing state
4. User benefits from known state change
5. Impact: {USER_EXPLOIT_IMPACT}

Scenario E: User Griefs Role Preconditions

1. {ROLE_FUNCTION} has precondition: {PRECONDITION} (stored in shared object)
2. User calls a permissionless function that modifies the shared object to violate {PRECONDITION}
3. {ROLE_NAME} calls {ROLE_FUNCTION}, which aborts
4. System enters degraded state (no keeper actions possible)
5. Impact: {GRIEF_IMPACT}

Scenario F: User Forces Suboptimal Role Action

1. {ROLE_NAME} must choose between options based on shared object state
2. User manipulates shared object state 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} acts (discrete updates)
2. Between role actions, rate is stale -- does not reflect accumulated value
3. User monitors for {ROLE_NAME} pending transaction on shared object
4. User enters at stale rate (favorable), {ROLE_NAME} 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 function callable by {ROLE_NAME}:

Generic Rule: Any admin/keeper function precondition that depends on user-modifiable shared object state is potentially griefable.

Sui-specific griefability: Shared object contention can cause transaction ordering issues. If a keeper transaction and a user transaction both touch the same shared object, Sui's consensus determines ordering -- neither party can guarantee priority.