/economic-design-audit

name: "economic-design-audit"
description: "Trigger Pattern MONETARY_PARAMETER flag (required) - Inject Into Breadth agents (merged via M4 hierarchy)"

ECONOMIC_DESIGN_AUDIT Skill

> **Trigger Pattern**: MONETARY_PARAMETER flag (required) > **Inject Into**: Breadth agents (merged via M4 hierarchy) > **Purpose**: Analyze admin-settable economic parameters (fees, rates, thresholds, emission schedules) for boundary violations, invariant breaks, interaction extremes, and fee formula correctness

For every monetary parameter setter (rate, rebase, supply, mint, burn, emission, inflation, peg, price cap/floor, fee, reward rate) in the protocol:

1. Parameter Boundary Analysis

| Parameter | Setter Function | Min Value | Max Value | Enforced? | Impact at Min | Impact at Max | |-----------|----------------|-----------|-----------|-----------|---------------|---------------| | {param} | {set_fn} | {min} | {max} | YES/NO | {impact} | {impact} |

For each parameter: substitute min and max into ALL consuming functions. Tag: [BOUNDARY:param=val -> outcome]

**Aptos-specific checks**:

• Are bounds enforced via `assert!()` in the setter? If not, admin can set any value within the type range (`u64::MAX`, `u128::MAX`)
• Does the protocol use `u64` or `u128` for monetary values? Check for overflow at max values.
• Are there separate bounds for testnet vs mainnet? (Sometimes hardcoded differently)

2. Economic Invariant Identification

List all economic invariants the protocol must maintain:

| Invariant | Parameters Involved | Can Admin Break It? | Functions That Assume It | |-----------|-------------------|--------------------|-----------------------| | total_supply == sum(all_balances) | mint/burn params | YES/NO | {fn list} | | fees < principal | fee_rate | YES/NO | {fn list} | | collateral_ratio >= min_ratio | ratio_param | YES/NO | {fn list} | | rewards_distributed <= rewards_pool | emission_rate | YES/NO | {fn list} |

For each setter: can changing this parameter break an invariant that user-facing functions depend on? If yes -> finding.

**Aptos-specific invariants**:

• `FungibleAsset` total supply tracking via `supply()` must match minted - burned
• Object-based accounting: sum of all store balances == total assets managed
• Resource conservation: tokens entering protocol == tokens accounted internally

3. Rate/Supply Interaction Matrix

For protocols with multiple monetary parameters that interact:

| Parameter A | Parameter B | Interaction | Can A*B Produce Extreme Output? | |-------------|-------------|-------------|-------------------------------| | {param_a} | {param_b} | {relationship} | YES/NO: {at what values} |

Check: can two independently-valid parameter settings combine to create an extreme or invalid economic state? (Rule 14 constraint coherence)

**Examples**:

• Fee rate A = 50% AND fee rate B = 50% -> combined 75% fee (not 100%, because B applies to post-A amount)
• Reward rate = max AND lock period = min -> excessive reward extraction
• Borrow rate = max AND liquidation threshold lowered -> cascade liquidations

4. Fee Formula Verification at Normal Values

For every fee-related computation (fee calculation, fee deduction, fee distribution):

4a. Concrete Example Computation

Pick 3 representative fee rates (e.g., 1% = 100 BPS, 5% = 500 BPS, 10% = 1000 BPS) and trace through the actual code formula:

| Fee Param | Value | Formula | Input Amount | Expected Output | Actual Output | Match? | |-----------|-------|---------|-------------|----------------|---------------|--------| | {fee_bps} | 100 | {code formula} | 1_000_000_00 (1e8) | {expected} | {computed} | YES/NO | | {fee_bps} | 500 | {code formula} | 1_000_000_00 (1e8) | {expected} | {computed} | YES/NO | | {fee_bps} | 1000 | {code formula} | 1_000_000_00 (1e8) | {expected} | {computed} | YES/NO |

Tag: `[BOUNDARY:fee_bps={val} -> effective_rate={computed_rate}]`

**Red flags**:

• Gross-up formulas: `amount * MAX / (MAX - fee)` charges effective rate of `fee/(MAX-fee)`, not `fee/MAX`. At 5% this is 5.26%, not 5%. Document whether this is intentional.
• Fee-on-fee: Does fee A's output feed into fee B's input? If so, the combined effective rate is not simply A + B.
• Rounding direction: In Move integer math, division truncates. `amount * fee / 10000` always rounds DOWN (favoring user). Check if protocol uses `(amount * fee + 9999) / 10000` for ceiling (favoring protocol).
• Precision loss: With `u64` at 1e8 scale (Aptos standard), do intermediate products overflow? `u64::MAX = 18.4e18`, so `amount * fee` overflows if both are large. Check for `u128` intermediate or `math::mul_div` usage.

4b. Fee Interaction Matrix

For protocols with multiple fee types:

| Fee A | Fee B | A Output Feeds B Input? | Combined Effective Rate | Independent Rate Sum | Discrepancy? | |-------|-------|------------------------|------------------------|---------------------|-------------|

4c. Fee Impact on Share Price

If the protocol uses share-based accounting (vaults, LP tokens):

• After fee deduction: does the share price change?
• Does the fee mechanism create a spread between deposit and immediate withdrawal?
• Is the spread documented and within reasonable bounds?

4d. Fee-Base Consistency

For every fee computation, trace the base amount (the value the fee is computed on) through ALL subsequent code paths:

| Fee Site | Base Amount Variable | Modified After Fee? | Modified How | Fee Recomputed? | Overcharge? | |----------|---------------------|--------------------:|-------------|-----------------|-------------|

**Methodology**:

• Identify the variable used as fee base (e.g., `amount`, `deposit_amount`)
• Trace that variable FORWARD from the fee computation to the end of the function
• If the variable is reduced (capped, downscaled, adjusted to remaining capacity, slippage-adjusted) AFTER the fee was computed -> the fee was charged on a larger base than what was actually used
• **Concrete test**: If `fee = amoun