docs

maw was engineered by reducing the market to the smallest set of components capable of issuing supply, accepting capital, and supporting redemption without relying on an external venue. The program does not create a token and then search for liquidity around it. The pricing system, reserve system, minting authority, and redemption path are designed as parts of the same machine. Every instruction operates against a shared state in which outstanding supply determines the position of the market and the vault records the capital accumulated while reaching that position. This removes the usual separation between the token, the market in which it trades, and the accounts responsible for holding its liquidity.

The design process began with the requirement that the market remain understandable from its deployed program alone. A participant should not need to inspect an LP position, an incentive schedule, a routing service, or an administrator-controlled treasury to understand how issuance and redemption function. The relevant behavior is contained in the program, its constants, and the accounts derived for its operation. The result is a deliberately narrow architecture. SOL enters through the buy instruction, tokens enter circulation through the mint authority controlled by the program, tokens leave circulation through the sell instruction, and SOL returns from the same vault that received it. No secondary subsystem is expected to repair or complete this lifecycle later.

This reduction was not performed only for simplicity. Every additional market component introduces a separate source of state and a separate assumption about who will continue operating it. An external pool depends on liquidity remaining deposited. A market maker depends on capital continuing to be quoted. An adjustable curve depends on an authority continuing to act correctly. Maw replaces those assumptions with fixed program behavior. Once deployed, the system is expected to continue according to the same arithmetic regardless of participation, market conditions, or the continued involvement of its original deployer.

The protocol is organized around the relationship between three pieces of state: the token supply, the program-owned SOL vault, and the constants defining the two pricing functions. Outstanding supply identifies the current position of the market. The curve constants determine the cost of moving away from that position. The vault holds the cumulative SOL produced by earlier issuance after accounting for any completed redemptions. These values are not independent records describing different markets. Together they describe a single state transition system in which each accepted instruction moves supply and reserves in a corresponding direction.

The program-derived authority is responsible for the privileged token operations required by that system. Mint authority cannot remain in an ordinary wallet because issuance must occur only after the program has evaluated the buy curve and accepted the required SOL. Freeze authority is placed under the same program-controlled structure rather than left with a discretionary signer. This keeps the token’s administrative capabilities inside the execution rules of the protocol. A private key cannot independently mint additional supply, reproduce the token elsewhere, or perform privileged actions outside the instruction paths exposed by the deployed program.

The SOL vault follows the same principle. It is not a treasury wallet controlled by the team and it is not an LP account representing deposits from multiple liquidity providers. It exists as program state and is used for the specific purpose of receiving issuance capital and satisfying valid redemptions. The program determines when SOL may enter or leave it. A transfer from the vault is therefore not an administrative payment or a withdrawal authorized by ownership of a private key. It is the settlement portion of a state transition whose conditions must be satisfied by the sell instruction.

This architecture keeps custody and pricing within the same enforcement boundary. The program that calculates the amount owed is also the program that controls the authority needed to mint, burn, receive, and release the corresponding assets. Maw does not produce a quote and then trust a separate system to honor it. The quote becomes meaningful only as part of an atomic instruction that updates every affected component or updates none of them. A failed instruction cannot leave newly issued supply without the required SOL deposit, and a failed redemption cannot permanently destroy supply without completing the corresponding settlement.

The important characteristics of the market are represented as compile-time constants rather than mutable configuration stored behind an administrative authority. This includes the parameters used by the buy and sell curves and the relationship required between them. Encoding these values into the program makes the deployed binary the final description of the market rather than one temporary configuration among many possible future configurations. A reader examining the verified program can identify the arithmetic being enforced without also needing to ask which wallet may alter it later.

This decision changes the role of deployment. Deployment is not merely the moment at which the first version of the protocol becomes available. It is the point at which the selected market geometry becomes permanent. The slopes cannot be adjusted in response to volume, market sentiment, reserve growth, or the preferences of the deployer. The spread cannot be narrowed to encourage activity or widened to retain additional value. There is no parameter-update instruction because the absence of adjustment is part of the design rather than an omitted feature.

The program includes a compile-time relationship requiring the sell slope not to exceed the buy slope. Expressed in the implementation as SELL_SLOPE <= BUY_SLOPE, the assertion prevents a binary from being produced with a curve relationship that violates the intended reserve model. This check occurs before deployment rather than after the protocol has begun accepting capital. An invalid configuration is rejected as an invalid program build, which means the solvency constraint is treated as part of the implementation itself instead of documentation that a deployer is merely expected to follow.

Compile-time enforcement is important because a warning or interface-level validation would not provide the same guarantee. Frontends can be replaced, scripts can call instructions directly, and human procedures can be ignored. A condition enforced during compilation prevents the incompatible program from becoming the artifact that is deployed. The verified binary therefore provides evidence not only of the curve values but also of the constraint under which those values were accepted.

Maw uses separate linear functions for issuance and redemption. Both functions reference outstanding supply, but each answers a different question. The buy function determines the amount of SOL required to create additional supply from the current state. The sell function determines the amount of SOL returned when existing supply is removed. These functions are evaluated independently because minting and redemption are not treated as reversible presentations of one transaction. They are distinct state transitions with different effects on reserves.

A linear curve was chosen because its behavior remains explicit across the entire supply range. The marginal price changes at a constant rate as supply changes, making the relationship between the current state and the next state directly inspectable. There is no hidden liquidity concentration, reserve ratio, moving coefficient, or piecewise regime that changes after a threshold. The same function used near the origin remains responsible for pricing later supply. Although the values increase as the market advances, the rule producing those values does not change.

A multi-token transaction must account for movement across a range of supply rather than applying one displayed marginal price to every unit. When a purchase expands supply, the transaction moves from the existing supply position to a higher one. The required deposit represents the cost of that complete movement along the buy function. Redemption performs the corresponding operation across the sell function as supply contracts. This distinction prevents larger transactions from receiving every token at the price associated only with the starting state.

The separation between the curves causes the amount deposited during issuance to exceed the amount immediately recoverable through redemption of the same newly created supply. That difference is not calculated as a percentage after the quote has been produced. It results from evaluating two different functions over the same supply interval. The program does not need a fee-recipient account or a separate fee balance because retained SOL remains in the vault as a consequence of settlement itself.

The curves do not receive information from an oracle and do not reference prices established by an external market. Their output depends on program state and constants already present in the deployed artifact. The same state presented to the same instruction produces the same quote. Block conditions, transaction volume, wallet identity, and activity on other venues do not alter the calculation. This makes the pricing model deterministic while also making its limitations explicit: Maw describes its own internal market and makes no claim that its curve will match a price formed elsewhere.

The buy instruction is the only intended path through which new supply enters circulation. A purchase begins with the current outstanding supply and the quantity requested by the participant. The program evaluates the corresponding movement along the buy curve and determines the SOL required to complete it. This calculation occurs against the state visible when the transaction executes, not the state that existed when a frontend first displayed an estimate. Any protection against an unfavorable state change must therefore be expressed as part of the submitted instruction rather than assumed from an earlier interface quote.

Once the transaction has satisfied the required checks, SOL is transferred into the program-owned vault and the corresponding token amount is minted under the program-derived authority. These actions belong to one execution path. The program does not mint an allocation in advance and later attempt to sell it, nor does it depend on an inventory account holding tokens for distribution. Supply is created at the point capital enters. The relationship between minted supply and deposited SOL is therefore preserved at the instruction level.

After execution, the total supply reflects the newly issued amount and the vault reflects the capital accepted for it. The next purchase is evaluated from this updated position. There is no average entry price stored for the market because later pricing does not depend on reconstructing the history of previous buyers. The current supply contains the information needed to identify the market’s position on the curve, while the vault balance records the resulting reserve state.

The instruction does not distinguish between early participants, later participants, deployer-controlled wallets, or contracts interacting through another program. The same calculation applies to every valid caller. No allowlist, private allocation, or privileged issuance route is required by the pricing system. Any exception to the normal curve would create supply whose reserve contribution differed from that assumed by the protocol, so the authority structure is designed to prevent such an exception from being performed outside program control.

The sell instruction performs the opposite state transition without treating the buy instruction as something that can simply be reversed. A seller presents existing tokens for redemption, and the program evaluates the movement from the current supply position to the reduced position along the sell curve. The result determines how much SOL may leave the vault. The calculation depends on the supply being removed and the market state at execution, not on the amount originally paid by the wallet submitting the redemption.

This means tokens do not carry individualized cost bases inside the program. A token purchased earlier and a token purchased later are identical once they exist in circulation. The redemption function does not inspect transfer history or attempt to restore each holder’s original deposit. It prices the destruction of supply according to the present sell curve. Ownership determines who may authorize the token transfer, while the curve determines what the removal of that supply is worth to the protocol.

The redeemed tokens are removed from circulation as part of the same instruction that releases SOL. They are not deposited into an inventory account for resale because the buy path does not distribute previously redeemed tokens. Buying creates supply and selling destroys it. This preserves the direct relationship between the supply variable and the number of tokens that remain economically active. The program does not need to distinguish circulating supply from a reserve inventory held by the market itself.

Before settlement, the instruction must establish that the requested redemption is valid under the current state and that the vault can satisfy the calculated output. If the checks fail, the entire instruction fails rather than partially processing the redemption. Tokens remain with the holder and SOL remains in the vault. This atomicity is essential because burning without payment or paying without burning would break the accounting relationship that the protocol is designed to preserve.

The vault is the accumulated record of the market’s completed state transitions. Every successful buy increases both outstanding supply and the SOL controlled by the program. Every successful sell decreases outstanding supply and releases the amount determined by the redemption curve. The vault balance at any moment is therefore the result of the complete transaction history, even though the program does not need to store that history as a separate ledger in order to price the next transaction.

Because issuance and redemption follow different curves, the vault is expected to retain SOL beyond the amount associated with immediate redemption at the current sell function. That retained balance is not assigned to a fee recipient. It remains within the account governed by the program and contributes to the reserve available for future redemptions. The spread is therefore realized as additional vault depth rather than extracted as revenue during each transaction.

This distinction is central to the accounting model. A conventional fee may leave the trading system and become an asset of a treasury, liquidity provider, or administrator. The structural difference in Maw remains inside the same system that produced it. The program does not need to calculate how much of the vault belongs to separate classes of recipients because there are no LP shares or fee claims represented by the protocol. The vault has one operational purpose: to hold SOL under the conditions enforced by the deployed program.

The solvency argument depends on the relationship between the amount accumulated during issuance and the amount made available through redemption. By constraining the sell curve relative to the buy curve, the program is designed so that valid issuance contributes sufficient capital for the corresponding redemption obligations defined by the protocol. The exact state of the vault still changes with the sequence and size of transactions, but the pricing relationship is selected so that redemption does not promise more than the issuance model was designed to provide.

During development and deployment, an upgrade authority is required to publish and finalize the program. Retaining that authority after launch would leave the protocol’s behavior dependent on whoever controlled it. Even if the visible parameters were stored as constants, an authorized upgrade could replace the program with a new binary containing different constants, additional transfer paths, or altered authority checks. Immutability therefore requires more than describing the parameters as fixed. The mechanism capable of replacing the implementation must also be removed.

Maw burns the upgrade authority after the final program is deployed. Once that operation is complete, no signer can submit a replacement binary through the normal upgrade mechanism. The program executing on-chain becomes the final version rather than the current version. This is the point at which the engineering decisions described in the documentation stop being promises made by the deployer and become limitations imposed on the deployer as well.

The same reasoning applies to the mint and freeze authorities. They are not retained as ordinary administrative keys because those keys would create execution paths that exist outside the documented market. Authority is instead assigned to the program-derived address whose signing capability can only be exercised through the program’s instructions. The program can perform privileged token operations when its conditions are satisfied, but no person possesses the private key of a PDA and no external wallet can independently impersonate it.

Authority removal does not establish that the program is free from implementation errors. It establishes that its rules cannot later be changed to correct those errors or introduce new behavior. Immutability removes administrative risk while increasing the importance of the original implementation, testing process, and public verification. The security model therefore depends on readers being able to inspect the exact program that was finalized rather than trusting that an upgrade authority will respond correctly after deployment.

The program is structured so that invalid state transitions fail before permanent state is committed. A buy cannot succeed if the required SOL is not provided, if the requested movement cannot be represented safely, or if the accounts supplied to the instruction do not match the accounts expected by the protocol. A sell cannot succeed if the caller does not provide the required tokens, if the requested amount exceeds valid supply, or if the calculated settlement cannot be satisfied under the current vault state.

Arithmetic operations require explicit protection because curve calculations operate on integer values and may approach the limits of their representation as supply grows. An overflow or underflow cannot be treated as a harmless approximation. Allowing arithmetic to wrap would produce a valid-looking number unrelated to the intended curve and could break both pricing and reserve accounting. Calculations must therefore fail when they cannot be completed within the permitted numeric range.

Account validation serves a separate purpose. Solana instructions receive accounts from the caller, which means the program must establish that each account is the expected mint, vault, authority, token account, or system account before acting on it. The program cannot rely on a frontend to supply the correct addresses. Derived addresses and ownership checks allow the instruction to reject substituted accounts that might otherwise redirect assets or cause the program to modify unrelated state.

A failed instruction leaves the market in its previous state. Supply does not advance, the vault does not change, and no partial settlement is preserved. This behavior is not an additional recovery system. It follows from executing the pricing calculation, validation, transfers, and state changes as one atomic transaction. The protocol therefore avoids intermediate states that would require an administrator to reconcile balances manually.

A fixed market must define not only ordinary operation but also the points beyond which ordinary operation cannot continue. Supply may approach a configured or arithmetic limit at which additional issuance is no longer representable. A requested purchase may require a value larger than the program can safely calculate or the transaction can provide. Redemption may eventually reduce supply toward its minimum state. These are not exceptional market opinions made by the contract. They are boundaries created by the finite state space in which the program operates.

At the upper boundary, the buy path must reject any instruction that would move supply beyond the supported range. The program does not flatten the curve, reset the price, or begin a new pricing phase to preserve activity. Doing so would introduce behavior not described by the original linear function. Once the next valid state cannot be represented under the deployed rules, issuance has reached its terminal condition.

At the lower boundary, redemption cannot remove more supply than currently exists. As circulation contracts, the sell function continues to evaluate the remaining interval until the minimum valid supply state is reached. The system does not create negative supply, continue paying after all redeemable tokens have been destroyed, or treat vault balance alone as permission to issue withdrawals. SOL may leave only as settlement for a valid reduction in outstanding supply.

Any SOL remaining in the vault after the final possible redemption remains subject to the deployed program. It is not automatically evidence of an undisclosed withdrawal path and it does not become administratively claimable merely because normal activity has ended. The treatment of a terminal balance is determined by the instructions contained in the immutable program. If no instruction authorizes its removal, then the absence of that path is itself part of the final protocol state.

The engineering claims made by Maw are intended to be checked against the deployed artifact rather than accepted from the interface. The program address identifies the executable account responsible for processing instructions. The verified source identifies the implementation expected to correspond to that deployment. The upgrade-authority state establishes whether the binary can still be replaced. The mint authority, freeze authority, and vault addresses show whether control has been assigned according to the architecture described above.

Verification should begin with identity rather than appearance. A frontend can display any program address, curve parameters, or authority status without proving that its transactions use those values. The relevant question is whether the accounts referenced by the interface match the accounts read and modified by the deployed instructions. The mint must be the mint controlled by the documented PDA. The vault must be the vault derived for the deployed program. The executable program invoked by buy and sell transactions must be the same program whose source and authority status are being presented.

The curve constants should be verified in the implementation and, where available, against reproducible build output. This confirms that the slopes described publicly are the values enforced by the binary rather than values displayed only by the website. The compile-time assertion should be visible alongside those constants so that the required relationship between issuance and redemption can be inspected directly.

The final verification step is observing actual state transitions. A completed buy should show SOL entering the documented vault and supply increasing through the documented mint. A completed sell should show supply decreasing and SOL leaving that same vault under the authority of the program. These transactions provide a public record of the system behaving as described. The documentation explains the intended architecture, but the deployed accounts and transaction history provide the evidence that the architecture is the one currently operating.