Frequently asked questions.

Multi-party computation splits a private key into shares held separately, so the full key is never assembled and there's no single point of failure. Unlike on-chain multisig, it's chain-agnostic and invisible to the blockchain; unlike cold storage, it stays fast and programmable.

Yes. Key generation, signing, the policy engine, and approvals all run in your own cloud, VPC, or data center. Your keys and data never leave your environment, and there's no external signer in the transaction path.

You define rules in the policy engine—spend limits, allowlists, time locks—and approval quorums (m-of-n). Every transaction is checked against your policies and must collect the required approvals before any key share signs. Every step is logged.

V3 Custody supports [XX]+ chains and thousands of tokens across major L1s, L2s, and EVM / non-EVM networks, with new networks added regularly. (replace with your actual coverage)

Institutions can deploy the full stack as a turnkey custody solution; teams can integrate the same infrastructure into their own product through APIs and SDKs. Same security model, two ways to adopt.

No. The crypto assets sit on controlled blockchain addresses. The ledger reflects the ownership, state and movement of those assets inside V3 Custody's operational model.

An explorer shows on-chain transactions. The ledger adds owners, balance states, reserves, counterparties, policies, approvals and business links.

No. Reserved funds still belong to the owner — they're just temporarily unavailable for creating another operation.

The reserved amount returns to Available, and the unsuccessful operation stays in the history.

Yes. A position is calculated from the ledger postings committed before the chosen moment.

Financial history shouldn't be deleted. Refunds and fixes use linked operations instead — refund, reversal, correction or replacement.

The ledger is an operational registry of digital assets and a source of data for reconciliation and reporting. It can integrate with accounting and ERP systems, but it isn't positioned as a statutory accounting system.

Yes. The system aggregates operations across all addresses associated with the selected counterparty and simultaneously saves details for each address.

Yes. Reports can be filtered by specific token ID, network, and contract. This prevents mixing different assets with the same ticker.

Yes. You can select individual addresses or use address folders, such as Treasury, Operations, or Settlement.

Internal transfers are classified separately and, by default, do not increase external turnover.

Yes. Any aggregated metric is expanded to include a list of transactions, ledger entries, and blockchain transactions.

Live analytics can use the updated classification. Saved snapshots remain unchanged.

Yes. Balance Position and Account Statement allow you to calculate the status of assets at a selected point in time.

PDF, XLSX, CSV, and JSON.

Yes. Reports can be saved as templates and run daily, weekly, or monthly.

The reporting module uses Vault and user permissions. Data is filtered by permission scope before any calculations are performed.

Multisig only answers "how many keys are needed." It knows nothing about the amount, the recipient, the time of day or an employee's role. A rule like "under 1,000 on your own, above that with the CFO, and this counterparty never" can't be expressed at the key level.

You don't have to. We don't store or see private keys — we connect to your wallet service. Our layer handles the rules, the approvals and the record.

A minimal working setup is two employee groups, a limit that escalates to signature, and a daily cap. That's an hour to configure and covers most scenarios; the rest is added later without rework.

That's the default case. A member with no roles sees what's been opened to them and can't run a single operation — the engine declines it for lack of a permitting rule. No separate "read-only mode" to set up.

Member visibility is its own setting, closed by default. A contractor sees only the people you've shown them, and can share access only with those same people.

The pre-send check shows the engine's decision on a specific operation without running it. A mistake is visible before it costs money.

No. Gas Station isn't your wallet — it's a shared infrastructure layer that covers transaction fees. You fund one balance to pay for gas; your addresses and the assets you send stay yours. It works like an exchange's hot wallet, sponsoring fees for millions of addresses across the network at once.

No. Because the same sponsor pays fees for millions of unrelated addresses, there's no self-funding pattern to follow — no parent wallet, no ownership graph. There's no native-token trail from a funded address back to your treasury, so the fee mechanics reveal nothing about which addresses are yours.

No. An address is ready the moment it's created — no activation fee, no minimum balance, no pre-funding. It can send from its very first second, because the fee is covered at send time rather than held on the address.

TRON, Ethereum, BNB Chain and [more EVM chains] — all from a single balance and one integration. On TRON, energy and bandwidth are delegated to the address on the fly; on EVM chains, the transaction is sponsored through a relayer, so the address never holds ETH or BNB.

Fund Gas Station with a network's native coin or plain USDT. Fees are drawn from that balance in the asset you funded — top up in USDT, pay fees in USDT. Every sponsored transaction carries an exact cost you can break down by client, wallet and chain.

You get signed low-balance webhooks ahead of time, plus auto-top-up rules — so no transaction fails by surprise. Full top-up history and gas balance are available over REST, or straight into your AI agents via MCP.