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.

.@Perps 🤝 Solana. Europe's largest asset manager picks Solana, $1B in Spot ETFs, record-breaking collectibles. Here’s everything else that happened over the week: 📰 Headline News - @Amundi_ENG, Europe's largest asset manager (€2.4T AUM) and @Spiko_finance ($1.7B AUM) announced their UCITS fund on Solana - @anza_xyz shipped P-Token to mainnet and Alpenglow on the community test cluster - @kamino Ethena market crossed $400M in 24h, its fastest market expansion 📰 Launches - @KrwqCash’s Korean won-pegged stablecoin, KRWQ, expanded to Solana - @KrakenInsto rolled out regulated SPL custody, starting with 18 tokens - @JupiterExchange partnered with @Bitwise to curate an institutional-grade Ethena lending market - @reflectmoney integrated @BlockworksAdv for institutional risk analysis and capital allocation - @crymbotech integrated with Solana to bring identity-verified execution to institutional and RWA platforms - @ethena’s ENA went live natively on Solana via @sunrisedefi - @jito_sol introduced FireBAM, a Frankendancer-compatible client pairing Firedancer's performance with BAM’s privacy and deterministic execution - @jup_mobile rolled out a new redesigned app - @PhoenixTrade activated 24/7 onchain crude oil and gold perps trading - @ProofMarkets debuted "consequence markets," a new derivative category for pricing the impact of probable events - @Collector_Crypt teamed with @ComicBook to launch a collectibles Gacha machine for 40M users - @Beezie expanded its tokenized collectibles platform to Solana - @cesto_co launched 3 new baskets, including a product built on @DDDTracker data - @kem_app introduced a USDT-native bank built on Solana - @zerion shipped a CLI giving agents a full trading and data stack - @FlashTrade activated MCP for prompt-to-transaction execution - @Dune launched Solana MCP support for querying Solana activity - @glider__ introduced the Solana Ecosystem Portfolio for auto-rebalancing across major assets - @ScorelyGG debuted Scorely Monitor, an x402-powered terminal for real-time sports betting - @MiloOnChains rolled out v2 of its trading agent platform for autonomous strategies - @TryNoahAI launched Noah 3.0 with a more efficient AI engine - @MeteoraAG launched DLMM Quote Token Fees - @craftsdev debuted Solana’s first sealed-bid auction for demand-based price discovery - @askthehive_ai went live its non-custodial stablecoin yield aggregator on Solana - @agentscoretrust facilitated the first autonomous AI agent wine purchase from @martinestateai with verified age-gating - @GetRektApp launched Rekt, a perps + prediction markets app - @DartExchange opened early access for low-slippage swaps - @StarchildOnX integrated Solana Skills into its marketplace, enabling AI agents to build applications autonomously - Breakpoint 2026 Early Bird tickets are on sale through May 31 - @incubator's Cohort 4 Demo Day lands in NYC on May 20 - @MonkeFoundry opened applications for cohort 2 📰 Milestones - US Solana Spot ETFs crossed $1B AUM - @bitget's preOPAI launch sale on IPO Prime closed with $119M committed across 5K+ participants - @onrefinance’s ONyc surpassed $100M market cap - @RockawayX’s USDC RWA vault on Kamino hit $40M in total supply - @streamflow_fi celebrated five years as a core provider of Solana token vesting and payment infrastructure - @phygitals hit a new ATH of $250M total platform volume - @solflare Private Send crossed $10M+ in volume - @AviciMoney crossed $20M in card spends If you enjoyed this week’s newsletter, please share it with an RT. Artwork by @SCUMSOL 🔥

Is there a reason nobody has tried just implementing a one slot lag to programmatically guarantee transaction ordering on perps on Solana? Protocol level in flight ordering would be nice, but 400ms lag isn’t *that* bad.