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

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:

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:

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:

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:

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:

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 = amount * fee_rate / MAX, then amount is reduced to leftover (e.g., remaining allocation), the user paid fee on amount but only leftover was processed -- overcharge of fee * (1 - leftover/amount)

5. Emission/Inflation Sustainability

For protocols with emission/inflation/rebase mechanics:

Aptos-specific emission checks:

• Does the module use timestamp::now_seconds() for emission calculations? Verify time-based math is correct.
• Are emissions denominated in the correct decimal scale (1e8 for most Aptos tokens)?
• Can emission rate be set to drain reward pool in a single epoch/transaction?

Instantiation Parameters

{CONTRACTS}              -- Move modules to analyze
{MONETARY_PARAMS}        -- Admin-settable economic parameters
{FEE_FUNCTIONS}          -- Functions containing fee calculations
{INVARIANTS}             -- Expected economic invariants
{EMISSION_MECHANICS}     -- Emission/inflation/rebase mechanics (if any)

Finding Template

**ID**: [ED-N]
**Severity**: [based on fund impact at boundary/extreme values]
**Step Execution**: checkmark1,2,3,4,5 | x(reasons) | ?(uncertain)
**Rules Applied**: [R10:Y, R14:Y]
**Location**: module::function:LineN
**Title**: [Parameter/invariant/fee] issue in [function] enables [attack/failure]
**Description**: [Specific economic design issue with concrete boundary values]
**Impact**: [Quantified impact at boundary conditions]

Output Schema

Step Execution Checklist (MANDATORY)