Overview
How V3 Custody is built and how its parts (Vaults, addresses, the ledger, the Policy Engine, approvals, counterparties, and Gas Station) work together.
This section explains how V3 Custody works under the hood and why it's built this way. The Introduction gives you the big picture in five minutes; here we go deeper, covering each pillar of the platform separately, with the details you'll need for integration.
You don't have to read the pages in order, since each one stands on its own. But if you're just getting started, the order below gives you a coherent path: from how addresses are created to how funds move and are accounted for.
How it all connects
A single short chain runs through the entire product:
- A Vault defines an address tree based on your derivation schema.
- Each address is an account in the ledger; access to it is isolated and granted per address.
- The ledger records every movement of funds with double-entry accounting and computes balances from the entries.
- Before signing, the Policy Engine decides whether funds can move and whose approval is needed.
- Queued transfers go through approvals while the amount is held in reserve.
- Counterparties and categories add business meaning: to whom funds went and why.
- Gas Station pays the fees so an address works from the first second.
What's in this section
Each topic has its own page:
Vaults and derivation
Why you design the address schema yourself and how segments become derivation paths.
Addresses, folders, and access
An address as a ledger account, visibility isolation, sharing, and access auditing.
Ledger (double-entry)
Balanced entries, available/reserved, historical balances, and idempotency.
Policy Engine
Deny-by-default, condition trees, limits, whitelists, and m-of-n approvals.
Approvals
The approval request lifecycle, the approver snapshot, and veto rights.
Counterparties and context
Address matching, categories, and operation links (refund/reversal).
Gas Station
A single gas balance, delegation/relayer, and privacy.