maw: asymmetric curve engine

appendix

a. linear pricing

maw uses two independent linear pricing functions. one defines the cost of issuance and the other defines the value returned during redemption. both originate from the same initial price but evolve independently as circulating supply changes. the functions are evaluated directly from current supply and do not depend on reserves, external liquidity, or historical execution. because neither function references the other during execution, every quote is deterministic and can be reproduced from protocol state alone.

buy(s)  = p₀ + mᵦ · s

sell(s) = p₀ + mₛ · s

mₛ ≤ mᵦ

b. spread invariant

the protocol permanently enforces that the redemption curve may never become steeper than the issuance curve. this condition is established during compilation and cannot change after deployment. maintaining this relationship guarantees that the protocol never redeems tokens above the corresponding issuance function and prevents the spread from becoming negative under any circulating supply.

SELL_SLOPE ≤ BUY_SLOPE

c. vault accounting

every unit of value entering the protocol is deposited into a single program-owned vault. purchases increase the vault balance while redemptions decrease it according to the redemption function. because no external liquidity providers participate in pricing, vault accounting is reduced to deterministic additions and subtractions governed entirely by executed instructions.

vaultₙ₊₁ = vaultₙ + buys − redemptions

d. solvency

the protocol accepts purchases only when the resulting state remains internally consistent. redemption succeeds only when sufficient balance exists inside the vault to satisfy the calculated payout. execution therefore depends entirely upon current vault state rather than assumptions regarding future participants or external liquidity. solvency is evaluated continuously through execution rather than restored through later intervention.

e. numerical precision

all pricing calculations use deterministic integer arithmetic. floating-point operations are intentionally avoided so that identical inputs always produce identical outputs regardless of validator implementation or execution environment. rounding behavior remains fixed for every instruction and therefore becomes part of the protocol specification itself rather than an implementation detail.

f. terminal conditions

issuance terminates when the configured maximum supply has been reached. redemption terminates only when no circulating supply remains or when the requested redemption exceeds the available vault balance. these conditions are direct consequences of protocol state and require no administrative intervention or governance decision.

g. immutable deployment

the deployed executable represents the complete protocol. pricing parameters, authority relationships, account derivations, and execution logic become fixed once the upgrade authority is removed. every subsequent interaction is performed against the same immutable binary, allowing all documented behavior to remain publicly verifiable throughout the lifetime of the protocol.