01
Append-only blake3 chain.
Every fill, transfer, and balance change is hashed with the previous event. Tamper with any record and the chain breaks downstream — visibly, by construction.
VERIFIABILITY
Trust by mechanism,
not by claim.
An append-only blake3 hash-chain over every event. Double-entry conservation on every transfer. WAL-durable, deterministic replay from genesis. The chain is exported off-box so it can be verified independently.
THE RECEIPTS
What 'verifiable'
actually means.
Four mechanisms — not adjectives. Each one is a system you can inspect, an export you can verify, a property you can rely on.
02
Double-entry conservation.
Every balance change is a conserved pair of transfers. The conservation gate verifies cache ↔ ledger lockstep on every batch. Mismatch = abort.
03
Least-privilege audit DB.
The audit DB is segregated with the minimum privileges required. The hot path can't rewrite history; history can only be appended-to.
04
Off-box hash-tip export.
The hash-tip of the chain is exported to an external system on a fixed cadence. Anyone with the tip can independently verify chain integrity.
BREAK IT YOURSELF
Tamper a block, watch it break.
The audit chain is not a claim you have to take on faith. Every event is hashed together with the one before it — so click any block below to tamper it, and watch every downstream hash break, visibly, by construction.
↑ Click any block (except genesis) to tamper. Downstream hashes break — visibly.
Block 00 · init
GENESIS
b1165923
55c04291
55c04291
Block 01 · fill
BTC-PERP +0.45
81ae307e
9dc30b18
9dc30b18
Block 02 · fill
ETH-PERP +1.20
8dd2160e
af981868
af981868
Block 03 · fill
BTC-PERP −0.10
f3475c4c
3b4af49a
3b4af49a
Block 04 · tfr
USDC dep +5,000
4cec5030
7b7e09da
7b7e09da
Block 05 · fill
BTC-PERP +0.25
4dcdd8fc
24f722ca
24f722ca
Block 06 · fill
SOL-PERP +12.0
e28cd308
0376f4fe
0376f4fe
Block 07 · fill
ETH-PERP −0.40
511d46f0
78a842be
78a842be
THE PERIMETER
Four layers, each verifiable.
Security here is not one wall but four independent layers — who you are, what a key may do, who can move funds, and whether the record can be trusted. Each has its own deep-dive.
Passkeys + step-up
Your session is not a skeleton key.
Login is phishing-resistant by construction with passkeys, and boundary actions — withdrawals, whitelist changes, key issue — demand fresh proof at the perimeter (RFC 9470). Risk-based sessions shrink the trust window when the signals look anomalous.
Deep-dive: /identity — sessions, step-up, risk.
Scoped API keys
Only the rights you grant.
API keys are scoped — read, trade and withdraw are separate permissions — and requests are signed with Ed25519 rather than carrying a bearer secret, so a leaked key is not a usable token on its own. Withdraw-scoped keys only work against whitelisted addresses.
Deep-dive: /identity — scoped, signed keys.
Threshold custody
No single point of signature.
Funds at rest are held under a t-of-n threshold signature: no single machine holds the whole key or can sign a withdrawal alone. New addresses wait out a time-delay hold, and an external audit gates mainnet.
Deep-dive: /custody — threshold signing.
Deterministic replay
A ledger you can re-run.
Every event is WAL-durable before it is acknowledged, and the whole ledger replays deterministically from genesis to a bit-identical state — the record is trusted because it can be recomputed, not because it is asserted.
Deep-dive: /technology — WAL-before-ack.
Most exchanges ask you to trust them.
The core was rebuilt so it can show you.
DETAILS
Questions, answered straight.
What a leaked session can do, who can move funds, what tamper-evidence means concretely, and whether history can be rewritten.
What if a session token leaks?
A session is not a skeleton key. The high-stakes actions — moving funds, changing a whitelist, issuing a key — sit behind step-up at the perimeter and demand fresh, strong proof at the moment you request them, so a stolen session cannot silently withdraw. Risk-based sessions also shrink the trust window when the signals look anomalous, and API requests are signed rather than relying on a bearer secret.
Who can actually move funds?
No single party. Withdrawals are signed by a t-of-n threshold of independent parties, and the full private key is never assembled on any one machine — compromising one server is not enough to sign a withdrawal. On top of that, a withdrawal must clear step-up confirmation, a whitelisted destination, and a time-delay hold before a threshold ever signs.
What is tamper-evidence, concretely?
Every fill, transfer and balance change is hashed together with the previous event into an append-only blake3 chain. Tamper with any record and every hash downstream breaks — visibly, by construction — because each hash depends on the one before it. The audit database runs with least privilege, so the hot path cannot rewrite history; it can only be appended-to.
Could the exchange rewrite its own history?
Not quietly. The hot path cannot rewrite the audit database — least-privilege roles allow only appends — and the tip of the hash chain is exported off-box on a fixed cadence, so it becomes a commitment someone else already holds. To rewrite history undetectably you would have to break the chain and match a tip that has already left the building.