PRION starts with a constraint that trading interfaces often hide: a transaction is only as useful as the state used to construct it. A fast endpoint can still produce a poor result if its pool reserves are stale, its account set is incomplete, or its status model ends at “sent.”
I have spent more than 18 months building the Rust execution engine and live Solana indexer beneath PRION. The hackathon work is turning that internal foundation into a developer-facing product another team can integrate.
The system therefore treats indexing, construction, signing, submission and observation as one workflow. The goal is not to move custody into an API. It is to give a client a fresh, inspectable transaction, let the client sign locally and then report what actually happened on-chain.
The short version
PRION consumes Solana account and transaction streams, decodes venue-specific state into typed internal models and maintains the data required to construct trades locally. A request selects fresh state, validates it, creates a transaction message for the client wallet and returns that message for inspection and authorization.
Non-custodial. Transactions are signed locally by the client.
Once signed, the transaction can be submitted through the selected execution path. Submission is not treated as confirmation: status continues through processed, confirmed or finalized outcomes, and failures remain explicit.
- 01ReceiveAccount, transaction and event streams
- 02DecodeProtocol-specific data into typed state
- 03IndexExecution-ready pools, vaults and market history
- 04BuildFresh transaction message for the requested wallet
- 05SignLocally by the client
- 06SubmitThrough the selected landing path
- 07ObserveSubmission, confirmation, failure and recovery
Why the indexer belongs in the execution path
A typical trading integration accumulates several independent services: a market-data feed, an RPC provider, protocol SDKs, a quote source, transaction construction, a sender and a status tracker. Every boundary introduces another cache, another retry policy and another definition of freshness.
PRION’s existing Rust indexer continuously maintains pools, vaults, token metadata and market activity from Solana streams. Protocol adapters translate different account layouts into a consistent internal representation. That representation is useful for a chart, but it is also the execution input.
This changes the critical path. The system does not need to rediscover every account through remote reads for each client request. Thousands of integrations can reuse maintained state while the execution layer still checks the specific inputs it is about to use.
Freshness is a contract, not a feeling
“Real time” is too vague to be an execution guarantee. PRION tracks whether the required state exists, where it came from and whether it is recent enough for the requested operation. Missing or stale state is rejected or sent through an explicit recovery path.
That matters during the unglamorous moments: startup, stream reconnects, partial protocol discovery and account changes that arrive out of order. A result should not look successful merely because the API returned quickly.
The public developer layer is being designed around this same principle. Responses and stream events need to make freshness, retries and terminal failures understandable without exposing every implementation detail of an individual DEX.
Transaction construction without custody
The construction boundary is deliberate. The client supplies the wallet identity and trade intent. PRION selects and validates market state, derives the required accounts and instructions, and returns a wallet-bound transaction message. The client can inspect and sign that transaction locally.
PRION does not need a trader’s private key to construct the message. For an interactive spot trade, client approval remains part of the flow. Automated orders require a narrower authorization model with explicit spending limits, expiry and revocation controls; a price trigger is permission to attempt an action only inside those constraints.
Solana’s transaction model defines the message that signatures authorize. Keeping that message visible at the client boundary makes the security model easier to explain and test. The Solana transaction documentation covers the underlying transaction structure.
Submission is not confirmation
One of the easiest integration mistakes is to collapse several states into a single “success” response. A sender can accept a transaction that never lands. A processed transaction may not yet meet the confirmation level a product requires.
PRION separates at least these concerns:
- The client received a transaction to sign.
- A signed transaction was accepted for submission.
- The network observed it at a defined commitment level.
- The transaction reached a terminal success or failure outcome.
The HTTP request can return promptly while a WebSocket continues the lifecycle. After a disconnect, clients should be able to resume from durable identifiers instead of guessing whether to repeat the trade. Solana’s RPC WebSocket methods provide the underlying network subscriptions; PRION’s developer contract normalizes the trading-specific state around them.
What is already built and what is public next
The underlying Rust execution engine and live Solana indexer already exist. The hackathon build is the reusable product boundary around them: documented REST endpoints, recoverable WebSocket streams, an optional TypeScript SDK and a starter integration that uses the same public interfaces as every other client.
The current engine foundation contains adapters for eleven Solana venues across Raydium, Orca, Meteora, Pump.fun, PumpSwap and LaunchLab. Public coverage will be released incrementally, because naming an internal adapter is not the same as promising a production-supported endpoint.
Solana is the first complete path. EVM support is planned around the same developer workflow—state, construction, local signing, submission and observation—without pretending that account-based and EVM execution are identical beneath the interface.
Measuring the system honestly
Performance must be decomposed before it can be improved. Quote latency, transaction construction, send latency, confirmation and intra-block landing order answer different questions. A single “execution speed” number conceals too much.
In a dated internal measurement, the existing PRION path recorded approximately 34 ms transaction-send latency through tested staked connectivity, compared with 75–100 ms through the standard RPC path. In a separate same-launch observation on 21 March 2026, the PRION transaction landed earlier than a Trojan comparison within the same block while using a lower priority fee and no submission tip.
Those observations are useful evidence, but they are not a universal latency promise. The current benchmark page labels them as a limited internal snapshot. The next benchmark harness will publish provider versions, regions, sample sizes, percentile distributions, failures and raw artifacts so that comparisons can be rerun rather than merely repeated in marketing copy.
The product is the integration boundary
Infrastructure wins only when another builder can use it. The API is therefore organized around jobs a trading product needs to complete: receive market data, request a quote, construct a transaction, submit it, observe status and manage an automated order.
Teams should be able to adopt one capability directly or use the optional SDK and starter for the whole path. The underlying protocols remain modular; the public concepts remain stable enough that a product does not need a new architecture whenever a venue is added.
That is the practical meaning of PRION’s promise: build the trading product, not the trading stack.