Custody and Infrastructure¶
This page states precisely what custody means on Cantex, what depends on infrastructure operated by CaviarNine, and what changes as covalidation rolls out. It describes the system as it exists today; planned changes are explicitly marked as targets. Wherever the rest of these docs say "your keys, your assets", this page is the full statement.
Custody¶
Cantex does not have custody of your assets, but Cantex-hosted accounts currently have an infrastructure dependency on CaviarNine for transaction submission and confirmation. Those two statements are not contradictory, and this page keeps them side by side:
Your keys, your assets. Every Cantex user is an external party on Canton holding their own signing keys. Cantex cannot sign transactions on your behalf, or transfer or spend assets from your party without your authorisation.
Every Cantex account is secured by two things you create together at setup: a passkey and a 24-word passphrase. The passphrase derives the account's master key — the namespace root on Canton topology, with the authority to change anything about the account, including its key mappings. The passkey, through the WebAuthn PRF extension, derives two further keys: an operator key that signs ledger transactions (established by the party-to-key mapping) and a trading key that signs intents. Cantex holds none of these keys and does not store your passphrase. If you lose your passkey, the master key derived from your passphrase can re-establish control of the account; if you lose both, Cantex cannot restore access.
Infrastructure dependency. Cantex currently runs the single validator hosting Cantex parties and the only gateway for submitting Cantex actions to the Canton Network. All actions, including withdrawals, are prepared and submitted through that infrastructure. If it is unavailable, assets remain on-ledger under your keys but cannot be transacted until service resumes. In the event of a prolonged outage, CaviarNine would seek to coordinate with relevant Canton Network participants to restore or migrate hosting for affected Cantex parties where technically possible.
How your transaction reaches the ledger¶
You sign an intent with your own key. Signed intents are sequenced first-in-first-out and submitted to the Canton Network, where they are validated and committed on-ledger. The backend cannot modify a signed intent; equally, signing an intent does not of itself oblige Cantex to submit it to the network.
Two ways of interacting with Cantex¶
The infrastructure dependency above applies differently depending on how you use Cantex:
- Cantex accounts (parties hosted on the Cantex validator — every account created on Cantex is this kind): every action — swaps, liquidity operations, transfers and withdrawals — is prepared and submitted through CaviarNine infrastructure. The custody statement above applies in full.
- External wallets via Cantex Connect (parties hosted on your own or a third-party validator): you submit from your own node, and your assets never depend on Cantex infrastructure. The pools and the Cantex swap party live on the Cantex validator, so executing a swap still requires Cantex infrastructure to be available — if it is not, your transfer remains pending and can be cancelled from your wallet.
Validator hosting and covalidation¶
Today. Cantex parties are hosted on a single validator operated by CaviarNine. Daml package upgrades can currently be vetted by Cantex unilaterally.
Coming next (target: September 2026 — testnet already live). Cantex parties will be multi-hosted across three validators, operated by CaviarNine, Digital Asset and Kiln, with a 2-of-3 confirmation threshold. This provides replicated state, forced consistency across independently operated nodes, and protection against unilateral contract upgrades: all three operators must vet a Daml package before it can take effect.
Covalidation does not, on day one, add an alternative submission gateway: CaviarNine's backend remains the sole path for preparing and submitting actions for Cantex-hosted parties. Enabling covalidators as independent gateways for submitting transactions is on our roadmap.
Risks¶
Alongside the risks inherent to any on-chain trading system, you should specifically weigh:
- Infrastructure availability risk. As described above, transacting from a Cantex-hosted party depends on CaviarNine-operated infrastructure. During an outage, assets remain on-ledger under your keys but cannot be moved until service resumes. Covalidation reduces, but does not on day one eliminate, this dependency.
- Smart contract risk. Cantex's Daml contracts, like any smart contracts, may contain defects. Today Cantex can vet package upgrades unilaterally; under covalidation an upgrade requires all three validator operators to vet the package.
- Market risk. Prices of traded assets are volatile, and liquidity provision carries exposure to pool composition changes. Nothing in these docs is investment advice.
Liquidity providers are additionally subject to the compliance controls described on the Liquidity Partners page. The legal risk disclosure is in the Terms and Conditions.
Material changes to this page are dated in the docs changelog.