plamentsv/share-allocation-fairness

Skill: Share Allocation Fairness (Solana)

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

shares|allocation|distribute|pro.rata|proportional|vest|reward.*per.*share|
mint_to|burn_from|reward_index|cumulative

Purpose

Analyze fairness of share/token allocation mechanisms on Solana where users receive SPL Token shares proportional to deposits, contributions, or participation -- checking for late-entry advantages, PDA-based accounting manipulation, queue-position gaming, and time-weighting omissions.

Methodology

STEP 1: Classify Allocation Mechanism

Identify which pattern the protocol uses:

| Type | Solana Pattern | Key Risk | |------|---------------|----------| | Pro-rata snapshot | SPL shares minted at fixed ratio via mint_to at deposit time | Late depositors dilute early depositors' accrued value | | Time-weighted | Per-user PDA tracks reward_per_share_paid and accrued_rewards | Checkpoint manipulation, stale reward index | | Queue-based | Account-based queue (Vec in PDA or linked PDAs) | Queue position gaming, front-running batch processing via MEV bundles | | Epoch-based | Shares valued per epoch boundary, epoch tracked in global PDA | Cross-epoch timing arbitrage at epoch transition slots |

STEP 2: Late Entry Attack Model

For each allocation entry instruction:

1. Identify accrual source: What generates value for existing share holders? (yield from CPI, fees collected in vault PDA, SOL rewards, token emissions via mint authority)
2. Trace timing: When does accrued value become claimable vs when can new shares enter? Is there a checkpoint instruction separate from deposit?
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?

| Entry Instruction | Accrual Source | Time-Weighted? | Late Entry Possible? | Impact | |------------------|----------------|----------------|---------------------|--------|

Solana-specific timing: With 400ms slots, timing attacks are tighter but MEV bundles allow precise instruction ordering within a slot. An attacker can bundle: [deposit_ix] -> [crank_distribute_ix] to enter just before distribution.

STEP 2c: Cross-Address Deposit Model

For each entry instruction accepting a beneficiary: Pubkey parameter or deriving a PDA from a user key that is NOT the signer:

| Entry Instruction | Accepts Beneficiary? | Default State for New PDA | Exploitable? | Impact | |------------------|---------------------|--------------------------|-------------|--------|

Check: When a PDA is initialized for a new beneficiary address:

• What is the DEFAULT state? (reward_per_share_paid = 0? last_deposit_slot = 0?)
• If reward_per_share_paid starts at 0 while the global index is at N, the new PDA holder is entitled to ALL historical rewards on their deposit -- FINDING (late-entry variant)
• Can deposit(beneficiary, amount) where beneficiary != signer be used to create a new PDA that captures historical rewards the beneficiary did not earn?
• Does the instruction check init vs init_if_needed? With init_if_needed, repeated deposits for the same beneficiary reuse the existing PDA, but first deposit creates it with potentially exploitable defaults.

STEP 2d: Pre-Setter Timing Model

For each authority-settable reward/rate parameter:

| Parameter Setter | Staked-Before-Set? | Retroactive Rewards? | Fair? | |-----------------|-------------------|---------------------|-------|

Model the sequence: user deposits (PDA created with current index) -> authority sets reward rate -> rewards accrue.

• Does the user receive retroactive rewards for the period BEFORE the rate was set?
• Does a depositor AFTER rate-setting receive the same, more, or less?
• Is the global reward index updated atomically with the rate change, or can a window exist?

2e. Pre-Configuration State Analysis

For the allocation mechanism identified in Step 1:

| Configuration Step | Account/PDA Initialized | Instructions Available Before Init | Exploitable Default? | |--------------------|------------------------|-----------------------------------|---------------------|

1. What is the deployment/initialization sequence? List all initialize_* instructions in order.
2. For each step: what instructions are invocable BEFORE this initialization completes?
3. Are there reward/share calculations that read uninitialized PDA fields (defaulting to 0)?
4. Can a user call deposit/stake instructions before all PDAs are initialized and receive outsized rewards/shares?
5. Is there an authority check or is_initialized flag that prevents interaction before configuration completes?

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

STEP 3: Queue Position and Batch Processing

For protocols with batch/queue processing:

1. Ordering fairness: Is queue order FIFO (append to Vec), arbitrary (authority-chosen), or manipulable (MEV bundle ordering)?
2. Partial processing: Can the crank process some deposits but not others within a batch? (CU limits may force partial processing -- who gets processed first?)
3. Cross-batch state: Does processing order within a batch affect allocation ratios? (first processed gets better rate if rate changes with each processing)
4. Deposit splitting: Can a user split one large deposit into many small PDA accounts for queue advantage or to bypass per-account limits?

CU-aware batching: If batch processing iterates over a Vec<Pubkey> in a PDA:

• What is the max batch size before exceeding 1.4M CU / 200k CU per instruction?
• Can an attacker bloat the queue with dust deposits to force partial processing?
• Does partial processing create unfair ordering advantages for early entries?

STEP 4: Share Redemption Symmetry

Check that entry and exit use consistent valuation:

1. Mint vs burn ratio: Are SPL shares minted at the same exchange rate they can be burned? (check the share price calculation in both deposit and withdraw instructions)
2. Pending claims: Can unclaimed reward tokens dilute active shares' value? (rewards sitting in vault PDA counted as TVL but already owed to specific users)
3. Withdrawal queue: Does withdrawal ordering create unfair priority? (first to withdraw gets actual tokens, later withdrawers face depleted vault)

SPL Token authority risks:

• Mint authority: Can the mint authority (if held by program PDA) be misused to inflate share supply? Is minting gated by deposit logic only?
• Freeze authority: Can the freeze authority freeze specific user token accounts, preventing them from redeeming shares? (denial of service on targeted users)
• If freeze authority exists: who controls it? Can it be revoked? FINDING if freeze authority is active and can target individual users.

STEP 4b: Aggregate Constraint Coherence (Rule 14)

For independently-settable allocation rates/shares (e.g., per-pool weights, fee splits, distribution percentages stored in separate PDAs):

| Rate/Weight Setter | Aggregate Constraint | Enforced On-Chain? | What if Sum Exceeds/Falls Short? | |-------------------|---------------------|-------------------|--------------------------------|

Solana-specific: If weights are stored in separate PDA accounts (one per pool/vault), the setter instruction may update ONE PDA without checking the sum across ALL PDAs. This requires reading multiple accounts in one instruction -- check if the instruction accounts struct includes ALL weight PDAs for validation.

If aggregate constraint NOT enforced and rates independently settable -> FINDING (Rule 14).

Also check: Can the authority set a weight to 0 for an active pool? What happens to users with deposits in that pool? (Rule 14 setter regression -- setting weight below accumulated state)

Output

For each finding, specify:

• Allocation mechanism type (pro-rata, time-weighted, queue, epoch)
• Whether time-weighting is present or missing
• Concrete attack sequence with numerical example (SOL/token amounts)
• Who benefits and who is harmed
• Whether the attack requires MEV bundle ordering or is achievable with normal transactions

Finding Template

**ID**: [SAF-N]
**Verdict**: CONFIRMED / PARTIAL / REFUTED / CONTESTED
**Step Execution**: (see checklist below)
**Rules Applied**: [S1:___, S4:___, S9:___, R5:___, R10:___, R13:___, R14:___]
**Severity**: Critical/High/Medium/Low/Info
**Location**: programs/{program}/src/instructions/{file}.rs:LineN
**Title**: {fairness violation type}
**Description**: {specific issue with numerical example}
**Impact**: {quantified at worst-state parameters -- who loses how much}

---

Step Execution Checklist (MANDATORY)

| Step | Required | Completed? | Notes | |------|----------|------------|-------| | 1. Classify Allocation Mechanism | YES | | | | 2. Late Entry Attack Model | YES | | | | 2c. Cross-Address Deposit Model | YES | | Check beneficiary != signer patterns | | 2d. Pre-Setter Timing Model | YES | | Model deposit-before-rate-set sequence | | 2e. Pre-Configuration State Analysis | YES | | Deployment window + unconfigured defaults | | 3. Queue Position and Batch Processing | IF queue/batch detected | | Include CU-aware batch analysis | | 4. Share Redemption Symmetry | YES | | Include mint/freeze authority check | | 4b. Aggregate Constraint Coherence | IF multiple settable weights | | Rule 14 enforcement check |

If any step skipped, document valid reason (N/A, no queue, single pool, no settable weights).