Economic Design Audit

ECONOMIC_DESIGN_AUDIT Skill (Sui)

Trigger Pattern: MONETARY_PARAMETER flag (required) Inject Into: Breadth agents (merged via M4 hierarchy) Purpose: Analyze economic design of monetary parameters in Sui Move protocols for boundary violations, invariant breaks, and fee formula errors

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

1. Parameter Boundary Analysis

Enumerate all admin-settable monetary parameters stored in shared config objects:

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

Sui-specific: Parameters are typically stored in shared objects (e.g., Config, Registry, Pool). Check:

• Are bounds enforced in the setter function? (assert!(value >= MIN && value <= MAX))
• Can the setter bypass bounds? (e.g., separate force_set function)
• Are bounds hardcoded or stored (and themselves admin-settable)?

Move arithmetic model: Move uses unsigned integers only (u8, u64, u128, u256). No native BPS type.

• u64 max: 18,446,744,073,709,551,615 (~1.8e19). SUI has 9 decimals, so max u64 represents ~18.4 billion SUI.
• Overflow: Move aborts on arithmetic overflow/underflow by default (no silent wrapping). An overflow in a fee calculation aborts the entire transaction.
• Division by zero: Move aborts. Check all divisions where divisor is a parameter or derived from state.
• amount * fee_bps where amount is large: e.g., 1e18 * 10000 = 1e22 which OVERFLOWS u64. Check for u128 intermediate casts.

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.

Sui invariant patterns:

• TreasuryCap<T> controls minting -- does unlimited minting break a peg or backing invariant?
• Shared pool balances must satisfy: balance::value(&pool.token_a) * balance::value(&pool.token_b) >= k (AMM invariant)
• Vault invariant: total_shares * price_per_share <= total_assets (no unbacked shares)

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)

Sui-specific interactions:

• TreasuryCap mint + admin fee rate: can mint + fee combine to extract more than pool holds?
• Epoch-based emission + stake/unstake delay: can users game emission timing around epoch boundaries?

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 Sui Move, integer division truncates (rounds toward zero). Does this favor the protocol or the user? For fee deductions, amount * fee / MAX rounds down (user-favorable). Is (amount * fee + MAX - 1) / MAX used for protocol-favorable rounding?
• Precision loss: With u64 math, do intermediate products overflow? Sui Move aborts on overflow -- is u128 used for intermediate calculations? Check for (amount as u128) * (fee as u128) / (MAX as u128) patterns.
• Gas budget constraint: Sui transaction gas budget cap is 50 SUI (~50 billion MIST). If fee computation involves iteration, dynamic field traversal, or complex math, can gas exhaustion prevent fee collection or cause user transactions to fail? Check: are there unbounded loops in fee distribution paths?