AWS KMS vs Fireblocks vs ZeroCopy: Signing Latency Benchmark

Executive Summary

Why This Matters

Every signing operation sits on the critical path of trade execution. The latency variance (jitter) between P50 and P99 directly determines how much alpha bleeds per trade.

The Jitter Tax formula:

Annual Loss = Daily Volume × Slippage × (P99 − P50) / P50 × 252

For a fund trading $50M/day:

Methodology

Test Configuration

provider_configs:
  aws_kms:
    key_id: "alias/benchmark-ed25519"
    region: "us-east-1"
    sdk: "aws-sdk-kms 1.x (Rust)"
    connection: "HTTPS (TLS 1.3)"

  fireblocks:
    vault_id: "benchmark-vault-01"
    api_version: "v1"
    sdk: "fireblocks-sdk 2.x (REST)"
    connection: "HTTPS"

  zerocopy:
    enclave_type: "AWS Nitro (c5.2xlarge)"
    channel: "vsock (AF_VSOCK)"
    key_gen: "In-enclave Ed25519"
    attestation: "PCR0 verified"

benchmark:
  iterations: 10000
  warmup: 100
  payload: 32 bytes (random)
  curve: Ed25519
  clock: rdtsc (CPU cycle counter)
  cooldown_between_runs: 0 (back-to-back)

What We Measure

1. Wall-clock latency: Time from "sign request sent" to "signature bytes received"
2. For KMS: Includes TLS handshake (connection pooled), API call, response parsing
3. For Fireblocks: Includes REST API call, MPC coordination, callback
4. For ZeroCopy: Includes vsock write, in-enclave Ed25519 sign, vsock read

Statistical Rigor

• 100 warmup iterations discarded
• P50/P95/P99 computed from sorted latency array (no interpolation)
• Standard deviation computed on full 10,000 samples
• All tests run sequentially (no concurrency) to eliminate scheduling noise
• Results are reproducible — see the test harness below

Latency Distribution

AWS KMS (10K samples):
  ████████████████████████████████████████ 147ms (P50)
  ████████████████████████████████████████████████ 189ms (P95)
  ██████████████████████████████████████████████████████ 210ms (P99)

Fireblocks MPC (10K samples):
  ████████████████████████████████████████ 580ms (P50)
  █████████████████████████████████████████████████████████████████████████ 1240ms (P95)
  ██████████████████████████████████████████████████████████████████████████████████████████████████ 2100ms (P99)

ZeroCopy Enclave (10K samples):
  █ 42µs (P50)
  █ 47µs (P95)
  █ 49µs (P99)

Reproduction

git clone https://github.com/zerocopy-systems/signing-benchmark.git
cd signing-benchmark

# Run ZeroCopy-only benchmark (no cloud credentials needed)
cargo run --release -- --provider zerocopy --iterations 10000

# Run all providers (requires AWS + Fireblocks credentials)
export AWS_KMS_KEY_ID="alias/your-key"
export FIREBLOCKS_API_KEY="your-key"
cargo run --release -- --provider all --iterations 10000

Full harness: github.com/zerocopy-systems/signing-benchmark

Caveats & Limitations

1. Network: KMS and Fireblocks latencies include network RTT. ZeroCopy uses local vsock. This is intentional — it reflects the architectural advantage of co-located signing.
2. MPC: Fireblocks MPC latency depends on the number of signers and threshold configuration. We used the default 2-of-3.
3. Cold Start: KMS has a ~200ms cold-start penalty on first invocation. We discard warmup runs.
4. Payload Size: Ed25519 signing time is constant regardless of payload size (always signs a 64-byte hash). The 32-byte payload is arbitrary.

Conclusion

The latency gap is not incremental — it's structural. KMS and Fireblocks are network-bound by design. ZeroCopy eliminates the network hop entirely by running the signing operation inside a co-located Nitro Enclave, communicating over a hardware vsock channel.

For any fund where signing latency sits on the critical path, this isn't optimization — it's architecture.

Run the benchmark yourself. Challenge our numbers. That's the point.

zcp audit --volume YOUR_DAILY_VOLUME