Share Allocation Fairness

Skill: Share Allocation Fairness (Sui)

Trigger Pattern: SHARE_ALLOCATION flag detected in pattern scan Inject Into: Breadth agents, depth-edge-case Finding prefix: [SAF-N] Rules referenced: R5, R10, R13, R14

shares|allocation|distribute|pro.rata|proportional|vest|reward.*per.*share|
balance::join|balance::split|coin::mint|reward_index|cumulative|epoch.*reward

Purpose

Analyze fairness of share/token allocation mechanisms on Sui where users receive Coin<T> shares or Balance<T> proportional to deposits, contributions, or participation -- checking for late-entry advantages, PTB-based timing exploitation, queue-position gaming, and time-weighting omissions.

Sui-specific share representations:

• Coin<ShareToken>: Fungible, freely transferable (has key + store). User holds as owned object.
• Balance<ShareToken> inside a position object: Non-transferable accounting. Locked within the protocol's object model.
• u64 field in a shared/owned struct: Simple numerical tracking, no token representation.
• Check which representation is used -- it affects transferability, composability, and gaming vectors.

Methodology

STEP 1: Classify Allocation Mechanism

Identify which pattern the protocol uses:

STEP 2: Late Entry Attack Model

For each allocation entry function:

1. Identify accrual source: What generates value for existing share holders? (yield from external DeFi, fees collected in shared pool, token emissions via TreasuryCap)
2. Trace timing: When does accrued value become claimable vs when can new shares enter? Is there a separate crank/update function?
3. Check for time-weighting: Does allocation account for HOW LONG shares were held, or only THAT shares are held at checkpoint time?
4. Model attack: Can a depositor enter AFTER value accrues but BEFORE distribution, capturing value they did not earn?

Sui timing model:

• clock::timestamp_ms() provides millisecond-precision timestamps (read from the Clock shared object)
• Timestamps advance per checkpoint (~0.5-2s), NOT per transaction
• Multiple transactions within the same checkpoint see the SAME timestamp
• Implication: time-weighted calculations based on clock::timestamp_ms() have ~0.5-2s granularity. An attacker can deposit and withdraw within the same checkpoint and see zero time elapsed, potentially capturing rewards with zero time commitment.

PTB-specific timing: With PTB composability, an attacker can compose multiple function calls in a single atomic transaction: [deposit] -> [trigger_distribution] -> [withdraw] within one PTB. This is more powerful than EVM flash loans for timing attacks because PTBs execute atomically with no inter-step cost.

STEP 2c: Cross-Address Deposit Model

For each entry function accepting a recipient address parameter:

Check: When a new position object or dynamic field is created for a recipient:

• What is the DEFAULT state? (reward_per_share_paid = 0? last_deposit_epoch = 0?)
• If reward_per_share_paid starts at 0 while the global index is at N, the new position holder captures ALL historical rewards on their deposit -- FINDING
• Can deposit(recipient, coin) where recipient != sender create a position that captures historical rewards the recipient did not earn?
• On Sui, this may manifest as a new owned object created for the recipient (clean state -- typically safe) or a new dynamic field added to a shared object keyed by address (check default values).

STEP 2d: Pre-Setter Timing Model

For each admin-settable reward/rate parameter:

Model: user deposits (position created with current index) -> admin sets reward rate -> rewards accrue.

• Does the user receive retroactive rewards for the period BEFORE the rate was set?
• Is the global reward index updated atomically with the rate change in the same function call?

2e. Pre-Configuration State Analysis

For the allocation mechanism identified in Step 1:

1. What is the deployment/initialization sequence? In Sui, init runs once at package publish. What configuration happens in init vs subsequent admin transactions?
2. For each step: what functions are callable BEFORE this configuration completes?
3. Are there reward/share calculations that use unconfigured (zero/default) values in shared objects?
4. Can a user deposit/stake before full configuration and receive outsized rewards/shares?
5. Is there a version flag or is_initialized check that gates user interactions?

Sui-specific: init() runs atomically at publish. If configuration requires MULTIPLE transactions (init -> configure_pool -> set_rates), there are windows between these transactions where the protocol is partially configured.

If users can interact during partial configuration AND default values create unfair advantage -> FINDING (minimum Medium, Rule 13: design gap).