Technology · FHE

Computing on ciphertext.

CKKS fully-homomorphic encryption lets our matching engine, risk engine, and compliance engine operate directly on encrypted trades. The platform never sees plaintext prices, sizes, or positions — the math runs on the ciphertexts.

Why CKKS, not BFV / TFHE.

Matching orders is arithmetic over prices — not boolean gates. CKKS (Cheon–Kim–Kim–Song) natively supports approximate real-number arithmetic with SIMD-style packing, making it the right tool for the financial workload. BFV/BGV make exact integer math more expensive; TFHE optimizes for boolean circuits.

SIMD packing — 8,192 order prices in one ciphertext
Multiply + add in a single scheme, no branch conversion
Rescaling after each mult keeps noise growth bounded
Bootstrappable — depths beyond 8 supported with refreshing

Parameters.

SchemeCKKS (approximate arithmetic, real/complex)
Ring dimension (N)2^14 = 16,384
Multiplicative depth8 levels after bootstrap
Ciphertext size~128 KB per packed ciphertext
Security level128-bit (LWE hardness)
AccelerationGPU (CUDA) + CPU AVX-512 paths

What we actually do with it

Six live workloads. All ship today, all benchmarked in production.

Confidential matching

Price and size ciphertexts cross in a CLOB without either counterparty seeing the other. Fills decrypt only for trade parties.

Dark-pool orders

Institutional orders posted as FHE ciphertexts. Market makers quote against encrypted depth; no pre-trade leakage.

Encrypted portfolio analytics

Risk, P&L, and exposure reports computed on encrypted positions. The analytics service never sees plaintext holdings.

Blind credit scoring

Lenders evaluate encrypted balance, income, and on-chain history. Only the yes/no decision — and the applicant — see the underlying data.

Private order book depth

Level-2 depth available to subscribers as ciphertexts; aggregated totals decrypt publicly, but individual orders stay hidden.

MPC + FHE compliance

Sanctions screen and Travel Rule evaluate encrypted counterparty data. "Is this address on the SDN list?" answered without revealing the address.

Architecture

FHE is a coprocessor. Most hot-path actions remain plaintext; only the confidential lanes traverse the CKKS engine.

Client-side encryption

Orders encrypted in the browser / mobile SDK with the tenant's CKKS public key. Plaintext never leaves the user device.

FHE coprocessor

GPU-accelerated CKKS evaluator runs matching, aggregation, and risk circuits. The coprocessor sees ciphertexts only — no key material.

Threshold decryption

Only results addressed to counterparties are decrypted, via an MPC threshold of the decryption key. The platform can never unilaterally decrypt.

Performance, honestly.

FHE is not free. A single ciphertext multiplication at ring-14 costs ~10ms on CPU, ~0.5ms on GPU. We use FHE where confidentiality matters more than microseconds — dark-pool books, encrypted analytics, private scoring — and plaintext CLOBs for commodity order flow.

Encrypted CLOB: ~50ms p99 match latency (vs ~5μs plaintext)
Encrypted portfolio: ~120ms for 10k positions, continuously
Batch aggregation amortizes cost across thousands of users

Paired with ZAP.

FHE keeps the computation private; ZAP publishes succinct proofs that the computation was correct. Together they give the best of both worlds: nothing is revealed, but everything is verifiable.

Trade fills: ZK proof that match was valid & within policy
Portfolio analytics: ZK proof of computation, regulator-auditable
Compliance checks: ZK attestation without revealing counterparty

Compute on the cipher.

Integrate FHE order types via our SDK. Your clients' orders stay encrypted end-to-end.