/zero-state-return

name: "zero-state-return"
description: "Trigger Pattern Vault/pool/first-depositor pattern detected - Inject Into Depth-edge-case"

ZERO_STATE_RETURN Skill

> **Trigger Pattern**: Vault/pool/first-depositor pattern detected > **Inject Into**: Depth-edge-case > **Purpose**: Analyze zero-state transitions in Aptos Move protocols -- initial zero state, return to zero after operations, residual assets, and re-entry vulnerabilities

Overview

This skill covers BOTH initial zero state AND return-to-zero-state analysis:

• Protocol initialization and first deposit conditions
• Protocol returning to zero after normal operations
• Residual assets when supply returns to zero
• Re-entry vulnerabilities after full exit

1. Identify Zero-State Transitions

Find all vault/pool/staking mechanisms and their zero-state boundaries:

| State | Resource / Variable | Zero Condition | Trigger | Code Location | |-------|-------------------|----------------|---------|---------------| | Total shares | {resource.total_supply} | `== 0` | All users withdrew/burned | {module:line} | | Total assets | {resource.total_assets} | `== 0` | No funds deposited | {module:line} | | Pool liquidity | {resource.reserves} | Both reserves `== 0` | All LP withdrawn | {module:line} | | Staking pool | {resource.total_staked} | `== 0` | All unstaked | {module:line} |

For each state: what is the protocol behavior when this condition is true?

2. First Depositor Analysis

Can the first depositor manipulate share price?

2a. Share Minting Formula at Zero State

| Protocol | Formula | When totalShares == 0 | First Deposit Behavior | |----------|---------|----------------------|----------------------| | {name} | `shares = amount * totalShares / totalAssets` | {special case?} | {describe} |

**Classic first depositor attack on Aptos**: 1. First depositor deposits minimal amount (e.g., 1 unit) 2. Attacker directly deposits tokens to the protocol's FungibleStore (unsolicited -- bypasses accounting) 3. Exchange rate inflates: `totalAssets` increases but `totalShares` stays at 1 4. Next depositor receives 0 shares due to rounding (their deposit amount < inflated share price) 5. First depositor withdraws, capturing the second depositor's funds

**Checks**:

• [ ] Is there a minimum first deposit requirement?
• [ ] Does the protocol use virtual shares/assets (e.g., add 1 to both numerator and denominator)?
• [ ] Is there a dead shares mechanism (burn initial shares to zero address)?
• [ ] Can unsolicited deposits to the protocol's store inflate `totalAssets`?
• [ ] Does the protocol use internal accounting (resistant) or direct balance queries (vulnerable)?

2b. First Deposit Protection Mechanisms

| Protection | Present? | Implementation | Bypass Possible? | |-----------|----------|----------------|-----------------| | Minimum first deposit | YES/NO | {code ref} | {analysis} | | Virtual shares/assets offset | YES/NO | {code ref} | {analysis} | | Dead shares (initial mint to zero) | YES/NO | {code ref} | {analysis} | | Internal accounting (not balance-based) | YES/NO | {code ref} | {analysis} | | Decimal offset in share calculation | YES/NO | {code ref} | {analysis} |

3. Return to Zero Analysis

After normal operations, can the protocol return to zero state?

3a. Return-to-Zero Scenarios

| Scenario | Trigger | Residual State After | Re-entry Safe? | |----------|---------|---------------------|---------------| | All shares redeemed | Last user withdraws | {what remains?} | YES/NO | | Emergency withdraw | Admin drains | {what remains?} | YES/NO | | All stakers unstake | Last unstake | {what remains?} | YES/NO | | Pool fully drained | All LP removed | {what remains?} | YES/NO |

3b. Can Total Shares Reach Exactly Zero?

Trace the withdrawal/burn path:

• Can the last user withdraw ALL their shares? (no minimum balance lock?)
• Does the protocol enforce a minimum share amount that prevents reaching zero?
• If dead shares exist, `totalShares` never reaches 0 -- is this protection consistent?

4. Residual Asset Check

When supply returns to zero, check for stranded value:

4a. Accrued Rewards

| Reward Source | Persists When totalShares = 0? | Claimable By Next Depositor? | Amount Bounded? | |-------------|-------------------------------|-----------------------------:|----------------| | {reward_source} | YES/NO | YES/NO | {max amount or UNBOUNDED} |

If rewards persist AND next depositor can claim -> FINDING (severity based on amount).

4b. Unclaimed Fees

| Fee Type | Persists When totalShares = 0? | Captured By Next Depositor? | Reconciliation Mechanism? | |----------|-------------------------------|----------------------------|--------------------------| | {fee_type} | YES/NO | YES/NO | {mechanism or NONE} |

4c. Dust Balances

• Can dust (sub-unit amounts) remain in FungibleStore after all withdrawals?
• Does dust affect exchange rate calculations on re-entry? (e.g., `totalAssets = 1 wei, totalShares = 0`)
• Does the protocol handle `totalAssets > 0 AND totalShares == 0` explicitly?

4d. Pending Operations

• Are there pending withdrawals/claims that persist after zero state?
• What happens to in-flight multi-step operations when supply hits zero?
• Are there resources or objects that reference the pool/vault state that become orphaned?

5. Re-Entry Vulnerability Analysis

Does re-entering zero state recreate first-depositor attack conditions?

| Scenario | Initial State | Return-to-Zero State | Same Vulnerability? | |----------|---------------|---------------------|---------------------| | First depositor attack | totalSupply=0, totalAssets=0 | totalSupply=0, totalAssets=X (residual) | **WORSE** if residual > 0 | | Exchange rate manipulation | No shares exist | No shares, but balance exists | YES + amplified | | Donation attack | Clean state | Dirty state | YES + pre-seeded |

**Key question**: Is the first-deposit protection (from Section 2b) applied ONLY on initial deployment, or does