Skip to main content

Glossary

TL;DRA quick reference for the terms that recur across these docs. Most link back to the page that explains them in depth.

Attestation

A hardware-signed measurement of the running enclave that a client verifies to confirm it is talking to the genuine, expected engine. See Privacy & Attestation.

Batch auction

The matching model: each tick, crossing orders clear together at a single uniform price rather than continuously, pairwise. See Clearing Price.

Bearer token

The account-layer credential from POST /auth/token, sent as Authorization: Bearer <token>. Gates access to the venue. See Authentication.

Change note

The note minted for the unfilled remainder of a partially-filled order, so the order keeps resting. Recovered via a fill memo. See Fills Channel.

Circuit breaker

The maximum deviation (in basis points) of the clearing price from the oracle reference, enforced by the attested matcher. It is part of the market policy, not a public input to the settlement circuit. See Clearing Price.

Clearing price

The single, oracle-anchored price at which every match in a batch settles. See Clearing Price.

Compose hash

The hash of the confidential-VM deployment composition. A client derives it from the DCAP-verified quote event log, then compares it with an independently obtained release value; it does not trust the self-reported /info field. See Transport & Attestation.

Confidential VM (CVM) / enclave

The hardware-isolated Intel TDX virtual machine the matching engine runs inside. Its memory is encrypted and its keys are bound to its measured image. See Confidential VM Architecture.

Inner hash

A note’s amount-independent value that anchors both its commitment and its note-use tag. Trade and change outputs inherit private input entropy; merge outputs combine private input inners; protocol fee outputs incorporate a governed epoch secret. Clients can recover their own descendants without making those relationships reconstructible from public chain data. See Shielded Pool.

Merkle tree

The on-chain accumulator of note commitments. Its root summarizes every note; inclusion proofs against it back orders and withdrawals. Sharded for settlement throughput. See Merkle Proofs.

MarketConfig

The per-pair on-chain configuration that binds a market’s base/quote mints, decimals, price scale, tick, minimum size, circuit-breaker band, and enabled state. Mint identity and price scale are settlement-proof-bound; tick, minimum, and breaker policy are enforced by the attested matcher. See Get Instruments.

Note

A UTXO-style unit of value committed on-chain as a Poseidon hash that seals the owner, amount, and token. Your balance is the set of notes you own. See Account Model.

Note commitment

The hash that represents a note on-chain. Opaque from the outside; only the owner can recognize and value it.

Note-use tag

The deterministic, circuit-derived public handle used when a note is locked or consumed: Hash(note commitment, private inner hash). It addresses the shared lock/consume PDAs without revealing which Merkle leaf is being used.

Owner commitment

The hidden, wallet-wide note owner derived from the client’s spending key. It is part of each note commitment and lets the proof enforce ownership, but it is not published by deposit, lock, settlement, merge, or withdrawal.

Recovery nonce

A fresh public BN254 field element generated for each deposit. Together with the master seed it deterministically recovers that deposit’s private note secret and inner hash. An exact retry reuses the original nonce; a new deposit generates a new one.

Order id

A client-chosen 16-byte identifier for an order, supplied at placement and used on cancel, modify, and get. Settlement output safety does not depend on its uniqueness.

Settlement

The on-chain process that makes a matched trade final: lock, verify the batch proof, and execute each atomic match. Marker close happens asynchronously after expiry and is not part of trade finality. See Settlement.

Spending key

The secret that determines note ownership and authorizes withdrawals. Never seen by the enclave. Distinct from the trading key. See Account Model.

Trading key

The Ed25519 keypair that signs orders. The cryptographic identity an order is attributed to and settled under. One account may drive many trading keys. See Authentication.

Transparency

The public proof-of-reserves: per-mint outstanding liabilities versus vault balances, plus the engine’s attested identity. See Transparency.

VALID_INPUT proof

The zero-knowledge proof that an order’s collateral note exists in the tree and is spendable for its token mint. Generated by the client; checked at order intake on settlement-enabled venues and verified again on-chain at lock time. It authorizes the note, not a particular order id. See Place Order.

VALID_DEPOSIT proof

The client-generated proof that a public deposit commitment contains the stated mint and positive amount and a valid hidden owner. The vault verifies it before moving custody. See Deposit.

Vault

The on-chain Solana program that holds custody, owns the note tree and shared consume-once set, and verifies settlement proofs. The only layer that can move tokens. See Trade Flow.