Context
A stablecoin or tokenized-asset issuer needed liquidity behavior designed around assets expected to trade close to a reference value. General-purpose automated market makers can provide an initial venue, but their assumptions often fit volatile pairs better than assets whose useful market is concentrated near parity. The issuer also had a redemption path, which meant secondary-market pricing, inventory, and primary conversion could not be designed independently.
The work was not simply to select a curve. A production liquidity system needed to observe market and redemption conditions, decide when and how to update its behavior, execute safely within Solana's transaction model, and remain understandable to operators when conditions departed from the normal range.
Challenge
Stable pairs create a narrow but demanding control problem. Small deviations can carry important information about inventory imbalance, redemption friction, market confidence, or stale reference data. A curve that concentrates liquidity near parity can use capital efficiently during normal conditions but become fragile if it continues quoting on assumptions that no longer hold.
Inventory connected every part of the system. A trade changed the composition available for subsequent trades and redemptions. Redemption activity changed the value of holding one side of the pair. External venues could move before the engine observed or acted. Reference inputs could disagree or become temporarily unavailable. The design therefore needed to distinguish ordinary rebalancing from conditions that required reduced exposure or operator attention.
Solana added execution constraints that mattered to the market design. Control logic had to fit inside bounded transactions, use accounts predictably, and avoid turning every update into an expensive global recomputation. State transitions needed to remain safe under contention and partial failure. The protocol could not depend on an offchain controller behaving perfectly, but it also could not move all market intelligence onchain without cost and liveness consequences.
Approach
We modeled the liquidity engine as a set of responsibilities rather than a single formula. One layer represented pool state and inventory. Another ingested approved observations about reference value and market conditions. A control layer translated those observations into bounded changes in quoting behavior. The execution layer enforced the permitted state transition onchain. Monitoring linked each transition back to the observation and control state that justified it.
Redemption was included in the model from the start. The design considered how secondary liquidity should behave when redemption demand changes, how inventory can be replenished, and how the engine avoids treating a persistent deviation as temporary noise. It also separated the economic right to redeem from the liquidity venue's ability to intermediate until redemption completes.
Control behavior was constrained. Updates had freshness and validity expectations. Changes that moved the system outside an approved operating region required a different path from routine adjustments. Degraded inputs produced explicit defensive behavior instead of silently carrying forward an old assumption. The design aimed to keep the onchain program deterministic and reviewable while allowing the observation process to respond to real-time conditions.
For Solana, we decomposed operations so common transitions touched a bounded set of accounts and could be reasoned about under concurrency. Authority checks were tied to specific actions. Simulation covered inventory states, input degradation, redemption pressure, and execution failure. Monitoring observed not only market outcomes but also stale observations, rejected updates, unusual control transitions, and unresolved operational states.
Operating the system
The engine was designed for intervention as well as automation. Operators needed to know whether a change came from ordinary inventory movement, a market observation, a defensive control, or a manual action. Each class of action carried different evidence and review expectations. This avoided an opaque controller whose output could only be judged after a loss or dislocation.
The public account intentionally stops at the control architecture. Proprietary equations, curve parameters, oracle rules, private performance evidence, and redemption terms are not necessary to understand the design method and are not disclosed.
Outcome
The architecture connects stable-pair pricing, inventory, redemption, observation quality, bounded controls, and Solana execution. Liquidity is treated as an operating process with explicit degraded states, not a static pool configuration.
The design establishes the relationship between primary redemption and secondary liquidity. Control behavior can be tested and monitored before production. The system specifies where automation is appropriate, where authority is required, and how to respond when market assumptions or data inputs are no longer reliable.
What this demonstrates
Matariki combines market-structure reasoning with protocol and performance engineering. For stable-value assets, that means designing the inventory, redemption, control, and monitoring system together, then fitting it to the execution environment. The same approach applies to low-volatility pairs and tokenized assets whose liquidity depends on a primary conversion path.
Confidentiality
This study excludes the issuer identity, proprietary equations, curve settings, spreads, oracle rules, inventory parameters, redemption terms, counterparties, and private benchmarks. It presents the generalized architecture and control method only.