Reducing trading latency on Privy
How Privy cut signing and swap latency while maintaining the security guarantees of TEE-based wallets
Adam Egyed
|May 27, 2026
We’ve been working on reducing signing and transaction latency across Privy.
Starting today, all wallet operations on Privy are 30–45ms faster across chains and use cases, with improvements to our signing infrastructure and networking stack.
For developers building trading applications on Solana, we’re also introducing a new low-latency swap API that combines quote fetching, signing, and transaction submission into a single authenticated request.
The result is one API call, one external network round-trip, and end-to-end latency of under 200ms, while maintaining the policy enforcement, key quorums, and secure isolation provided by TEE-based wallets.
Today, we're shipping two improvements:
Baseline signing improvements that reduce end-to-end latency by 30-45ms across all wallet operations and chains; and
A dedicated Solana swap API built for latency-sensitive trading applications where execution speed directly impacts fill quality.
Removing the tradeoff between speed and security
Historically, many trading applications optimized for lower latency by moving signing on-device. While this reduced network round-trips, it often meant giving up the policy enforcement, key quorums, and hardware isolation provided by TEE-based wallets.
Our goal was to remove the need for that compromise. Through enclave prewarming, parallel data loading, and infrastructure co-location, Privy's TEE signing infrastructure now delivers latency faster than on-device swap flows, while keeping keys isolated inside hardware-protected enclaves that even Privy cannot access.
How the swap API works
In a typical token swap, an application makes three separate external network calls:
Fetch a quote from a swap aggregator
Sign the transaction through a wallet provider
Submit the transaction to the blockchain network
Each step introduces additional latency. Some trading applications have reduced this overhead through on-device signing, bringing the flow down to two network round-trips. This however comes at the expense of policy enforcement, key quorums, and hardware isolation provided by TEE-based wallets.
Privy's swap API reduces this to a single round-trip.
Your application sends one authenticated request. Privy handles quote fetching, signing, and transaction submission within the same infrastructure boundary. This also allows parts of the flow to execute in parallel.
While the swap aggregator returns quote data, Privy’s enclaves can simultaneously prepare wallet data, decrypt shares, and load policies for evaluation. Once the quote arrives, the transaction is ready to be signed and submitted immediately.
The result is end-to-end swap latency of about 190ms, improving execution speed and reducing delay for latency for latency-sensitive trading applications.
For teams already using their own swap aggregator, the existing signAndSendTransaction API can still benefit from many of the same latency improvements. Developers can pass prepared transaction data directly to Privy for faster signing and direct-to-network submission.
To get the maximum benefit from this API, we also recommend enabling the optimistic_broadcast option. This will skip preflight checks and submit directly to the network, and return the signed transaction object for you to be able to re-broadcast on all transaction landing services
Under the hood: what we changed
Reducing transaction latency required changes across signing, infrastructure, and networking.
Parallelizing transaction execution
We recently introduced wallet actions, high-level APIs for preparing, signing, and submitting transactions within a single request. These APIs support common operations like transfers, swaps, and vault deposits or withdrawals.
Because these steps now execute within the same infrastructure boundary, parts of the transaction lifecycle can run concurrently instead of sequentially. This reduces idle time throughout the signing flow and improves end-to-end execution latency.
Enclave prewarming
Privy TEE wallets split key material into separate shares with different decryption requirements. One share is accessible only through valid user authentication, while the other can only be decrypted within the enclave itself.
To reduce signing latency, Privy begins preparing enclave state while authentication and developer configuration checks are still in progress. By the time authentication completes, the enclave is already prepared to evaluate policies and sign the transaction.
The full signing key is only ever reconstructed transiently inside the enclave, and is immediately cleared after signing completes.
Networking improvements
Latency is also affected by infrastructure routing, edge proxies, and physical distance between systems.
To reduce unnecessary network overhead, Privy optimized several parts of the networking stack, including direct node connectivity and co-located infrastructure.
With the network proxy bypass, we see a latency reduction of about 20ms. From re-running SLATE with 1000 runs, we see latencies of:
EVM Median: 83.62ms
Solana Median: 72.42ms
If you'd like to enable the proxy bypass, contact us.
Start building
The signing infrastructure improvements described above are already live across Privy, reducing end-to-end latency by 30-45ms on signing across wallet operations and chains.
The fast-RPC signAndSendTransaction improvements are live now, and the advanced swap API is available for enterprise customers.
For teams building latency-sensitive trading or financial applications, learn more in our docs or get in touch.
