Timeless Relic retweetledi
There are ~5-10 key architecture decisions that make or break every large engineering system.
A misstep in one of these decisions can lead to irrecoverable roadblocks for the product in the long term.
@PhoenixTrade is not a software masterpiece, but it's the first truly viable fully on-chain perps smart contract on @solana because we made reasonable decisions in the most critical areas.
Matching Engine
The Phoenix matching engine handles trades atomically for all counterparties. This means that after a single transaction, the taker and maker positions are all fully updated to reflect the trade result. It also stores limit orders sorted by price and time.
No other perps DEX on Solana in the past has ever supported both single-transaction matching AND price-time priority. We realized that this is not a pure tradeoff and made it the top priority in the matching engine design.
While this may seem like a niche technical detail, price-based priority algorithms protect users by guaranteeing that they always get the best price to trade based on the state of the book. Non-atomic trade settlement also causes UX problems and operational problems. A delay in processing maker trades leads to more gas spent in the backend system and more latency in the UI. Users will remember a clunky trading experience even if they don't understand why.
Efficient Market Maker Updates
Phoenix has a special order type for professional market makers called "spline orders". At a high level, this order type allows market makers to configure the liquidity depth of the book at different offsets from a mid price and provides an entrypoint for efficiently updating the mid price of their orders.
Due to the nature of the current Solana scheduler, the ability to update book orders with low computational overhead enables MMs to cancel and replace quotes with both high scheduler priority and low cost.
This is a critical feature for Phoenix to support the deep liquidity necessary to offer a world-class trading experience.
Risk Engine
The margin system on Phoenix is completely decoupled from the matching engine because they fundamentally serve different purposes. The matching engine is functionally a fancy calculator that facilitates risk transfer between counterparties. The risk engine is a read-only check on the validity of these transactions.
Phoenix's fully on-chain risk engine computes the required margin, liquidation status, total withdrawable balance, and free collateral all under Solana's tight computation constraints. There are even a handful of clever tricks in the margin math that make it impossible to withdraw funds or gain additional margin on positive uPnL on particularly illiquid assets, given the right configuration.
The software separation between risk and matching enabled the team to easily reason about the behavior of both complex systems in isolation and, as a result, made the system easier to reason about and easier to update. These properties ultimately reflect in the end user's trading experience and (ideally) protect the exchange.
Conclusion
Other major technical decisions made Phoenix possible as a pure engineering feat, but these were a handful that I think uniquely demonstrate why system-level decision-making is so important. If we didn't figure out any one of the above designs, the end-user experience of Phoenix would be meaningfully worse, and the team's ability to improve on the product would be meaningfully weakened.
Any system hoping to build serious financial products needs to bring the same level of care and decision-making to all of the core software components. For Phoenix in particular, this meant thoroughly understanding what it took to not only build a functional and efficient exchange but also fitting that design to the constraints imposed by the Solana smart contract environment.
English
