Eric Semeniuc

Builder + explorer. Shipping at Jito Labs. Opinions are my own, and do not reflect views of any past or present employer.

[Alessandro Decina @alessandrod]

working on making transaction execution never pagefault in agave 4.2

in this branch oracle updates are basically free, fastest in this profiled block was 9us but it aborted. fastest successful 17us (humidifi)

on avg all the top propAMMs are below 30us

we're getting pretty good at this

[Sam Schubert @minnus]

Early signs @jito_sol's BAM is changing oracle-update scheduling.

Not a perfect measure, but we bucket each oracle update by where it lands in the block, then measure how far each builder is from a perfectly even distribution. BAM’s May slots show the lowest “uniformity gap” in this data set.

If makers can refresh quotes more predictably, they should face less stale-quote/adverse-selection risk. For SOL-USDC that could mean deeper liquidity at larger clip sizes; for thinner pairs, it could lower the spread cushion makers need before supporting the market on @solana.

[Eric Semeniuc @seminuked]

@mert svb

[Jarry Xiao @jarxiao]

I’m very happy with our architecture for cross chain deposits.

We abstracted away the deposit problem by building a single-purpose smart contract wallet (PDA).

This unlocks general onboarding by hijacking a well-established existing interface.

And it is 100% noncustodial!

[Alessandro Decina @alessandrod]

24/5...ish

[dhruvsol @dhruvsol]

Most Solana teams optimize RPC.

We decided to remove it.

At @brewlabshq_ , our latency requirements pushed us beyond Yellowstone and toward consuming validator data directly from the source.

Today we're open-sourcing part of that work:

Qlaster — Shared-Memory Data Streaming for Colocated Solana Services.🧵

[blueshift @blueshift]

For half a decade, solana/web3.js has been how developers, apps and users interact with Solana.

Today, we're giving it the upgrade it always deserved: Web3.js 3.0.

A package with the API you already know, rebuilt from the ground up on Kit.

[Eric Semeniuc @seminuked]

@cavemanloverboy ansible is so verbose, a 3 liner in bash becomes 3 paragraphs sadly

[shek @shek_dev]

qedsvm is now open sourced, you can prove what the machine runs directly

full SVM ISA is implemented/specified in lean, this means you can take an .so and prove that it implements your spec

p-token's transfer path is proven spec to binary

[Eric Semeniuc @seminuked]

@thsottiaux for 24/7 running agents, yes

[Jacob Creech @jacobvcreech]

@trentdotsol Drop in avg CU, no dramatic uptick is tx rate at this time

[Brian @brian_smith_0]

Of 21 SOL/USDC trades on SOL, 1 had a worse fill compared to Binance (-0.20 bps)

Solana is the best place to trade spot in crypto. Soon JTX will prove that

[Eric Semeniuc @seminuked]

@buffalu__ andy grove: only the paranoid survive

[hersh @harsh_patel]

@doublezero @Austin_Federa contains:
- an aya ebpf program that conditionally redirects doublezero packets on GRE payload classification.
- a userspace zero-syscall userspace loop to process packets and pass to any downstream process.

PRs are welcome.
https://t.co/EVfpDSe9vQ

[hersh @harsh_patel]

open sourcing my AF_XDP receiver for doublezero edge!

supercharge your trading backend by shaving off microseconds of latency.

measurements from my prev run.

link below 👇

[The Block @TheBlockCo]

Solana Is Winning the Trading War

@jito_labs co-founder & CEO @buffalu__ joins @gazza_jenks at Consensus to explain why Jito is expanding from @solana infrastructure into consumer trading products with the launch of @jtx_trade.

"Most new people coming into crypto are using Solana because it’s fast and cheap."

OUTLINE
00:00 - Introduction
00:31 - Why Build on Solana
02:15 - Solana vs Ethereum
03:32 - Builder Challenges
05:38 - Launching JTX
08:12 - The Future of Trading
09:05 - Meme Coins and RWAs
11:27 - FTX and Solana
13:33 - Builder Culture
15:00 - JTX and AI Tools

[Jarry Xiao @jarxiao]

In the past month, @PhoenixTrade has shipped:
- Rise: our public TS and Rust SDK 📈
- 24/7 commodities trading 🥇🛢️🥈
- 17 new pairs 💱
- Flight Codes: a simple API for integrators ✈️
- Vulcan: a CLI tool for agents 🤖

Soon:
- Mobile 📱
- Cross chain deposits 💸
- [redacted] 👀

[buffalu @buffalu__]

a few months ago, debugging BAM meant wrangling grafana, influx, and one-off clickhouse queries.

this is what debugging BAM looks like now.

99% vibe coded internal explorer, every block and batch inspectable down to the microsecond.

team is unreal.

[Joel John @joeljohn]

My $0.02 - as someone who's been equally involved with Hyperliquid and Solana and admires both ecosystems.

If I were working at foundation, this is what I'd want to see to tweak things in Solana's favor.

1. Phoenix needs to get rid of that invite code nonsense asap because brother its 2026..

2. For perpetual exchanges, there are two core aspects that have nothing to do with settlement chain. You need a group of MMs and you need a risk engine. Hyperliquid could bootstrap this fairly well, and the airdrop incentivised MMs. Many of them ended up millionaires and that liquidity went towards HIP-3/HIP4.

Solana folks need to stop looking at this as a liquidity constraint and think who are the best MMs and what are the best assets. And no, thinking you don't need to incentivise those MMs doesn't work because the MMs are booking sufficient margins arbing tradfi stocks and currency pairs on Hyperliquid.

Hyperliquid launched in a zero competition market.
Solana's perp ecosystem is not launching in a blank market.

3. Hyperliquid was consistently early to listing new assets. Often times - that move hurt it because risk assessment is hard (jellyjelly). But it was one of the best places to go long on perps before Binance listed it. Speed of listing new assets was the pitch. It still is - you can trade spacex there before you can trade it on NASDAQ. Phoenix lags (from what I see).

compare this with number of assets on solana native perps.

4. Hyperliquid's core culture is built around a full-fledged product that is aesthetic. The attention to detail on Hyperliquid is often absent on many Solana native perps. You need to get off the feeds and open these products on two large monitors and spend a whole sixty minutes on these things and you will see the stark difference.

5. Solana's core value prop is actually in its RWA ecosystem. Instead of battling on crypto-native perps, or going after what Hyperliquid owns today, Solana should probably look towards the 350 assets Ondo supports and enable perps for them.

Why? You have a base market where MM's can go back to USDC on, MMs will want to hedge on a perp exchange and Solana has a strong lead here (compared to ETH/L2 ecosystem). You have an ecosystem of wallets that will embed these instruments.

You want to bring nasdaq on chain? Brother focus on those assets!! Tokenised compute, commodities, emerging market indices - are all blank spaces. And Hyperliquid does not own those markets today.

6. Hyperliquid dominates user mind-share now because it has done the three things necessary to build a cult in crypto. It built a product that speaks to tradfi (pre-ipo/hip3), it made an incredibly powerful stack (hip3/usdh) and it enriched people in the process.

Solana did the same with USDC and fwiw, to a certain extent with meme coins. Trying to battle it out on Hyperliquid's turf is trying to convert a cult. I belong to that cult - unless you have a superior product that has as much - people wont convert over

Hyperliquid has an incredibly powerful flywheel going on for it right now in that when tradfi stocks list, it has become the pricing avenue. The last time this happened with a primitive in crypto was with prediction markets - when they were more effective than traditional outlets at pricing election odds.

Crypto native approaches to competing with a behemoth whose moat is on risk engine, liquidity, a cult-like userbase and tradfi relevance is fairly weak. Teams on solana should frankly be looking a bit more deeper than the surface.

DMs open if you're building on either networks. I think the pie is a lot bigger than what we presume it is on X. We are talking about bringing the world's finances on-chain.

Cumulatively these ecosystems are at $80 billion. I think they will be worth $10 trillion in ten years. Too early to be bickering over size of the slice. Focus on the pie.

[Jarry Xiao @jarxiao]

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.