Benchmark methodology

The headline numbers

The 2QUIC Marketplace quotes three numbers on the landing page and the docs home. All three come from a single measurement: a May 2026 A/B test on Solana mainnet-beta comparing stake-backed QUIC connections against an unstaked baseline, run in parallel over the same 10-minute window.

Test setup

• When: May 2026.
• Where: Solana mainnet-beta, against live leaders.
• Design: two clients built on the same QUIC stack (staked-quic-tpu-client) ran in parallel for 10 minutes, so both arms saw the same leader rotation and network conditions.
• Staked arm: the TLS client certificate carried a staked validator identity. The TLS 1.3 CertificateVerify was signed by the validator's TEE, exactly as it is for a marketplace lease.
• Unstaked arm: an ad-hoc certificate with a fresh local Ed25519 keypair. The pubkey is absent from the stake table, so leaders served it from the best-effort lane.

The only variable between the two arms is whether the certificate pubkey appears in the stake table. Everything else (client code, target leaders, time window) is identical.

What each number measures

Connection lifetime (4.6x). Once a QUIC connection to a leader's TPU port is open, the leader can close it at any time. Stake-backed connections stayed open 4.6x longer before being dropped. Longer-lived connections matter because only a warm connection can send transactions instantly. Re-establishing one costs a fresh handshake of 30 to 80 ms, often mid leader window.

Evictions (24x). Leaders hold a bounded connection table. Under pressure they evict connections to admit new peers, and the policy is asymmetric by stake. The unstaked arm was evicted 24x more often than the staked arm over the same window.

Handshake failures (19x). A handshake attempt can be refused or time out before a connection ever exists, typically when the leader is saturated with unstaked peers. The unstaked arm failed handshakes 19x more often.

The mechanism: why stake changes leader behavior

None of this is 2QUIC magic. It is upstream Solana leader behavior, implemented in streamer/src/nonblocking/quic.rs of anza-xyz/agave (measured against v2.1):

• Identity from the TLS certificate. The leader extracts the pubkey from the client certificate of the QUIC handshake and looks it up in the stake table.
• Per-stake stream budget. Staked peers get concurrent stream capacity proportional to their stake share. Unstaked peers share a small best-effort pool.
• Asymmetric eviction. Under connection pressure, unstaked connections are pruned first. Staked connections are far more likely to survive.

A 2QUIC lease puts you on the staked side of this policy: the validator's TEE signs your CertificateVerify with the validator identity key, so leaders treat your connection as that staked validator. Because the stream budget scales with stake, the absolute effect depends on the stake of the validator you lease. Each listing shows the validator's stake and stake percentile so you can judge that before booking.

What is NOT claimed

• No landing-rate SLA. Leases do not carry a contractual landing-rate, inclusion, or uptime guarantee. There is no contractual SLA in v1 and no automatic credit for degraded performance.
• Point-in-time numbers. The 4.6x / 24x / 19x figures describe one 10-minute window in May 2026 against Agave v2.1 leader behavior. Cluster load, validator client releases, and SWQoS policy changes can all move them. The marketplace does not re-run the A/B continuously: the 60-second probe verifies each TEE's availability and sign latency, it does not measure landing rates.
• No per-validator performance chart. The structural advantage comes from the SWQoS policy itself, so the marketplace publishes one global methodology (this page) rather than fluctuating per-listing landing-rate numbers.

Reproducing the comparison

The open-source repo nodexpert-labs/staked-quic-connection-provider ships bench-client, a CLI that sends memo transactions over QUIC to a leader with either a TEE-backed staked certificate or a fresh unstaked one, and writes a JSON report.

git clone https://github.com/nodexpert-labs/staked-quic-connection-provider.git
cd staked-quic-connection-provider
cargo build --release -p bench-client

For the staked arm you need an active lease (see Booking): the one-shot credentials reveal gives you the TEE endpoint, your API key, and the TLS CA certificate, and the token endpoint mints the short-lived JWT the TEE verifies:

JWT=$(curl -s -X POST "https://api.swqos.dev/v1/leases/$LEASE_ID/token" \
  -H "Authorization: Bearer $API_KEY" | jq -r '.data.jwt')

Run the staked arm against your leased validator's next leader window:

./target/release/bench-client \
  --mode staked \
  --target our-validator \
  --rpc-url https://api.mainnet-beta.solana.com \
  --tee-endpoint "$TEE_ENDPOINT" \
  --tee-token "$JWT" \
  --tee-tls-ca tee-ca.pem \
  --trader-keypair trader.json \
  --tx-count 100 \
  --report staked.json

Run the unstaked baseline against the same validator's window (the ad-hoc cert pubkey is not the validator, so pass the target explicitly):

./target/release/bench-client \
  --mode unstaked \
  --target our-validator \
  --validator-pubkey <validator-identity-pubkey> \
  --rpc-url https://api.mainnet-beta.solana.com \
  --trader-keypair trader.json \
  --tx-count 100 \
  --report unstaked.json

Each run waits for the leader window (--max-wait-secs, default 600), sends the transactions, and writes a report with the handshake outcome, send_errors, landed, landing_rate, and p50_confirm_ms / p95_confirm_ms. Handshake failures abort the run or are logged per leader, and a connection the leader drops mid-run surfaces as send errors. Repeat both arms across several leader windows before drawing conclusions from a single 4-slot window (about 1.6 seconds of leader time).

Next steps