Fortkey has always combined high-frequency execution with real security controls. Even so, for the fastest trading use cases our sub-10ms signing was not fast enough. So we set ourselves a target that our existing platform could not reach by tuning: less than one millisecond, end-to-end, with the policy engine still in the path. This is what we measured.
Why the existing platform could not get there
Backend work got us below 10ms, but with a caveat worth stating plainly: that was 10ms of internal latency. It did not include the network delay of reaching the API. For a trading algorithm, internal latency is not the number that matters. The number that matters is the time from having transaction bytes to holding a signature, and the network sits inside that.
Closing a 10x gap meant a different deployment model, not a faster version of the same one.
The High Frequency Trading Vault
The HFT Vault is a locally deployed TEE that sits next to your trading algorithms and both enforces policy and signs locally. No network hop to a remote signer, because there is no remote signer in the hot path.
The trade is flexibility, not security. The HFT Vault carries immutable policies that it enforces on every transaction. You define a policy once, compile it into the vault, and from then on the bot can only produce signatures that policy allows. That constraint suits the use cases it is built for: low-latency strategies typically trade a narrow, stable set of instruments and venues, and rarely need policy changes mid-session. In exchange for giving up live policy updates, you get session monitoring, a kill switch, unified access controls, and transaction logs, all still wired into the Fortkey platform.
What we measured, and how
Every latency figure below is end-to-end for a full signing instruction, from transaction bytes to signature. It includes networking, client-side SDK serialization and deserialization, policy enforcement, and the signing itself. That is the latency a trading algorithm actually experiences, not a synthetic measurement of the crypto primitive.
The benchmark runs on an AWS EC2 c8a.2xlarge instance, powered by 5th generation AMD EPYC processors, with the vault deployed as an AWS Nitro Enclave. The benchmark client is pinned to a dedicated core (taskset -c x) to keep scheduler noise out of the measurement. Different instance types will produce different but comparable results.
We compared the HFT Vault against the two ways trading keys are commonly managed today:
- Plaintext key (AWS Secrets Manager). To meet HFT requirements, traders sometimes store private keys in AWS Secrets Manager. This is the fastest option, and it leaves the private key sitting in plaintext on the trading machine once fetched.
- AWS KMS. For secp256k1 signing, firms sometimes use asymmetric KMS keys directly. This keeps the key in an HSM, away from the trading machine. The KMS key was provisioned in the same region as the instance, so the comparison is not penalised by cross-region routing. Note that KMS provides no transaction-aware controls: it is effectively a blind signer with basic access control.
Five payload types, each run against a representative set of 200 randomly generated transactions:
- EVM EIP-1559, mixing native ETH transfers, ERC-20 transfers, and token swaps. Average payload 162 bytes.
- UniswapX, various EIP-712 Permit2 messages. Average payload 2,410 bytes.
- Polymarket, various EIP-712 CTF Exchange messages. Average payload 1,212 bytes.
- Hyperliquid, a mix of
updateLeverage,cancel, andordertransactions. Average payload 117 bytes. - Solana, Drift trades. Average payload 358 bytes.
To set expectations before the numbers: we expected the HFT Vault to be slower than plaintext key signing and faster than KMS. That is the honest price of protected keys, payload-aware policy, unified logging, unified access controls, and kill switches. The question was how large the gap would be.
How the three signing options compare
The ordering held across every payload: plaintext fastest, HFT Vault second, AWS KMS last by a wide margin.
| SIGNER | PAYLOAD | N | p50 [μs] | p95 [μs] | p99 [μs] | p99.9 [μs] | p99.99 [μs] | > 1ms |
|---|---|---|---|---|---|---|---|---|
| Plaintext key | polymarket | 500,000 | 63 | 63.4 | 65.9 | 69 | 76.3 | 0% |
| Plaintext key | hyperliquid | 500,000 | 52.3 | 53 | 55 | 58.1 | 63.8 | 0% |
| Plaintext key | solana_drift | 500,000 | 12.4 | 12.5 | 12.5 | 16.7 | 18.9 | 0% |
| HFT Vault | polymarket | 5,000,000 | 161.3 | 185.4 | 318.9 | 462 | 2838.4 | 0.016% |
| HFT Vault | hyperliquid | 5,000,000 | 133.2 | 156.6 | 182.5 | 403.1 | 707.9 | 0.009% |
| HFT Vault | solana_drift | 5,000,000 | 130.3 | 146.7 | 162.3 | 374.7 | 6579.8 | 0.018% |
| AWS KMS | polymarket | 20,000 | 6124.6 | 7376.1 | 14830.6 | 20352.6 | 26164.8 | 100% |
| AWS KMS | hyperliquid | 20,000 | 6084.1 | 7130.7 | 13421.3 | 19475.4 | 23306.4 | 100% |
End-to-end latency in microseconds. AWS Nitro Enclave on c8a.2xlarge, KMS key in the same region.
AWS KMS lands where end-to-end measurement puts it: every single signature crossed the millisecond line, with a median above 6ms and a p99 above 13ms. Even with optimised session management, the network round-trip dominates, and it is the reason KMS cannot serve an active on-chain order book no matter how well the rest of your stack is tuned.
The gap to plaintext signing is real and worth stating rather than hiding. Plaintext key signing is roughly 60% faster for ECDSA and roughly 90% faster for ed25519, which says as much about how cheap ed25519 is as it does about the vault. Plaintext signing is also more stable, with fewer outliers and a lower tail.
What matters is that the comparison is on the same axis at all. Most secure signing setups are not in the same order of magnitude as a plaintext key on the local machine. This one is, and the key never leaves the enclave.
Across the five payload types
Looking only at the vault, performance is consistent across use cases. The dominant variable is payload size: smaller payloads are faster, and the effect is most visible in the tail.
| PAYLOAD | AVG BYTES | p50 [μs] | p95 [μs] | p99 [μs] | p99.9 [μs] | p99.99 [μs] | > 1ms |
|---|---|---|---|---|---|---|---|
| evm_eip1559 | 162 | 132 | 150 | 169 | 493.6 | 787 | 0.005% |
| uniswapx_rfq | 2410 | 200 | 231 | 428 | 553.4 | 2432.7 | 0.015% |
| polymarket | 1212 | 161 | 185 | 319 | 462 | 2838.4 | 0.016% |
| hyperliquid | 116 | 133 | 157 | 183 | 403.1 | 707.9 | 0.009% |
| solana_drift | 358 | 130 | 147 | 162 | 374.7 | 6579.8 | 0.018% |
HFT Vault only, sustained load, 5,000,000 signatures per payload. Latency in microseconds.
UniswapX, at 2,410 bytes on average, is the slowest at the median and roughly 50% above the smallest payloads. That points at the real bottleneck: the drag is not the signing, it is the VSOCK transport and the serialization and deserialization of payloads moving between the trading algorithm and the enclave.
The headline holds across all five: median between 130 and 200 µs, and everything through p99.9 stays under one millisecond. Between 0.005% and 0.018% of signatures cross the line, which is roughly one in 5,500 at worst. We are close to the goal of secure signing under a millisecond, and the remaining work is pushing p99.99 under that threshold too.
Under a realistic traffic pattern
The sustained-load runs above pushed between 5,000 and 7,500 requests per second. Impressive, and not how most bots behave. A strategy usually waits for a trading event, then acts. So we re-ran everything at 40 rps to see what happens when the processor is mostly idle between signatures.
Idle time means cold caches, so we expected the performance percentiles to degrade.
| PAYLOAD | LOAD | N | p50 [μs] | p95 [μs] | p99 [μs] | p99.9 [μs] | p99.99 [μs] |
|---|---|---|---|---|---|---|---|
| evm_eip1559 | Sustained | 5,000,000 | 132 | 149.7 | 169.3 | 493.6 | 787 |
| evm_eip1559 | 40 rps | 25,000 | 244.2 | 456.3 | 557.8 | 684.2 | 2654.9 |
| uniswapx_rfq | Sustained | 5,000,000 | 200.2 | 231.4 | 427.7 | 553.4 | 2432.7 |
| uniswapx_rfq | 40 rps | 25,000 | 352.7 | 615.4 | 721.5 | 1088.9 | 4541 |
| polymarket | Sustained | 5,000,000 | 161.3 | 185.4 | 318.9 | 462 | 2838.4 |
| polymarket | 40 rps | 25,000 | 303.5 | 540.6 | 659 | 807.9 | 1453.6 |
| hyperliquid | Sustained | 5,000,000 | 133.2 | 156.6 | 182.5 | 403.1 | 707.9 |
| hyperliquid | 40 rps | 25,000 | 274.5 | 515.7 | 612.3 | 733 | 2564.1 |
| solana_drift | Sustained | 5,000,000 | 130.3 | 146.7 | 162.3 | 374.7 | 6579.8 |
| solana_drift | 40 rps | 25,000 | 243.1 | 423.1 | 545.5 | 656.5 | 836.5 |
HFT Vault, sustained load versus 40 requests per second. Latency in microseconds.
Medians roughly double, from around 130 to 200 µs up to around 240 to 350 µs, and jitter increases, driven by the same processor scheduling and interrupt behaviour. The tail holds: at 40 rps, four of the five payload types still keep p99.9 under a millisecond. UniswapX is the exception at 1,089 µs, again the largest payload. Solana Drift is the best case, staying under a millisecond all the way through p99.99.
Where this actually changes the trade
Signing latency only matters where a decision has a deadline attached. Two cases where it binds today, and one where we think it will:
On-chain CLOB venues. On an order book, your edge is how fast you can pull and replace a quote when the market moves. Every requote waits on a signature. A signer that adds 6ms per operation caps how tightly you can quote, so you widen spreads to cover the staleness you cannot avoid. At 130 to 200 µs the signing path stops being the binding constraint and the venue becomes the limit again.
Proactive AMMs and rebalancing. A propAMM that repositions against an external price only tracks it as closely as its update loop allows. Slow signing rations the number of adjustments you can make, which shows up directly as adverse selection against the stale position, the effect described in our note on self-custody for market makers.
RFQ markets, eventually. This is the one where we should be honest: today the windows are generous. A UniswapX quoter has to respond within 500ms, and signed quote TTLs on RFQ venues are typically measured in seconds, commonly 5 to 30. Against a 500ms budget, the difference between 200 µs and 6ms of signing is real but rarely decisive. If you are timing out of RFQ requests today, your signer is probably not the reason.
The reason to care is where this is heading. Quote windows get shorter as a market matures and quoters compete on speed. FX went through exactly this: response times more than halved in under two years.1 We expect crypto RFQ to follow the same path. If a 500ms window becomes a 20ms one, a 6ms signer goes from a rounding error to a third of your pricing time. That is a forecast, not a measurement, and we would rather label it as one.
Honest caveats and what comes next
The tail is not fully under control on the larger payloads. p99.99 is still above a millisecond on three of the five payload types, and jitter grows with payload size. The cause is the VSOCK transport and the serialization around it rather than the signing itself, which is where the remaining work sits. We are not claiming a clean sweep, and closing that gap is active.
More broadly, signing infrastructure is only one part of the loop. There is still decision making, transaction building, and transaction execution. Execution is where we are focusing next.
Notes
- The foreign exchange comparison is a precedent, not crypto data. After the Global FX Code was introduced in 2017, average last-look hold times across the top ten liquidity providers on EBS Direct fell 61%, from 93ms to 37ms, over roughly 18 months, and reject rates fell 41% (The Trade). Several large market makers pushed further, toward removing the hold window entirely (Euromoney). Two caveats on reading across. The FX compression was driven partly by a code of conduct and disclosure pressure, which crypto RFQ venues do not have an equivalent of, and we are not aware of published data showing crypto RFQ windows have tightened so far. The mechanism we expect to drive it is competition between quoters rather than regulation. Current window figures: UniswapX requires a quoter response within 500ms, and signed quote TTLs across RFQ venues are commonly offered at 5, 10, or 30 seconds. ↩
For informational purposes only; not investment, trading, or legal advice. Product and company names are trademarks of their respective owners; reference does not imply affiliation or endorsement. Latency figures are measurements taken under the specific conditions described above, and results will vary with instance type, payload, and workload.