Economic Design Audit

ECONOMIC_DESIGN_AUDIT Skill (Soroban)

Trigger Pattern: MONETARY_PARAMETER flag (required) Inject Into: Breadth agents (merged via M4 hierarchy) Finding prefix: [EDA-N] Rules referenced: R2, R10, R13, R14

rate|rebase|supply|burn|emission|inflation|peg|price_cap|price_floor|
fee|reward_rate|basis_points|bps|fee_bps|spread

Soroban arithmetic context: All numeric values use i128 (signed 128-bit). No floating-point. Fee/rate formulas use integer multiply-then-divide. Overflow panics unless checked_* used; unchecked release-mode i128 wraps silently. Division truncates toward zero.

1. Parameter Boundary Analysis

For every monetary parameter setter (rate, fee, reward rate, emission, cap, floor, BPS values):

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

Soroban-specific boundary checks:

• Does MAX cause i128 overflow in multiply-then-divide? (amount * rate_bps overflows before division if both are large; check for checked_mul)
• Does 0 cause division-by-zero? (panic aborts entire transaction — verify .checked_div() or explicit guard)
• Does 10_000 BPS (100%) cause user to receive 0 tokens or go negative with fees-on-fees?
• Does a negative i128 value cause unexpected behavior? (signed type allows negative rates if not bounds-checked)

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.

Soroban-specific invariants:

• i128 conservation: Total tracked must equal sum of individual claims. Verify no rounding loss accumulates across many users.
• No negative balances: i128 allows negative values — if subtraction underflows without checked math, balance can go negative silently.
• TTL-gated invariants: If a key expires and returns None, unwrap() panics; unwrap_or(0) may silently break the invariant.

3. Rate/Supply Interaction Matrix

For protocols with multiple monetary parameters that interact:

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

4. Fee Formula Verification at Normal Values

4a. Concrete Example Computation

Pick 3 representative fee rates and trace through the actual code formula:

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

Note: XLM uses 7 decimal places (1 XLM = 10_000_000 stroops). Verify formulas account for correct denomination.

Red flags:

• Gross-up formulas: amount * MAX / (MAX - fee) charges higher effective rate than fee/MAX
• Fee-on-fee: fee A's output feeds fee B's input — combined rate is not A + B
• Rounding direction: i128 division truncates toward zero — verify intended direction
• Division order: amount * rate / MAX vs amount / MAX * rate — second loses precision for small amounts

4d. Fee-Base Consistency

For every fee computation, trace the base amount through ALL subsequent code paths:

Methodology: Identify fee base variable → trace FORWARD → if variable reduced (capped, slippage-adjusted) AFTER fee computed → fee charged on larger base than processed.

4b. Fee Interaction Matrix

For protocols with multiple fee types: