Platform · Custody

Custody built so the assets are provably yours.

Every client holds bankruptcy-remote, individually segregated wallets on-chain. No omnibus pools, no borrowed float, no ambiguity about whose assets are whose.

Segregation

One client, one set of wallets. Always.

Your assets never enter an omnibus pool. Each client is provisioned dedicated on-chain addresses at onboarding, held under a bankruptcy-remote custody structure.

Legally, that means assets are held for your benefit, off holdway's balance sheet, and are not available to holdway's creditors in any insolvency scenario. Title stays with you; holdway holds keys, not claims. On-chain, it means every balance we report maps to specific addresses that you, your auditor, or your regulator can inspect on a public block explorer without asking our permission.

  • Dedicated deposit and vault addresses provisioned per client, per asset
  • Bankruptcy-remote structure: client assets are never a holdway liability pool
  • Every address enrolled in continuous on-chain attestation from day one
How keys are generated and held →

Storage tiers

Deep cold by default. Warm by policy.

The overwhelming majority of client assets sit in deep cold storage: keys generated and held offline in hardware-isolated MPC, with shards distributed across geographically separate facilities.

A small operational float can be held warm for clients who settle frequently: online signing infrastructure under the same MPC controls, capped as a percentage of holdings that you set in policy. Moving assets from cold to warm is itself a policy-governed transfer — it requires an approval quorum, respects your allow-lists, and appears in the audit trail like any other movement. Nothing drifts warm because an operator found it convenient.

  • Deep cold: offline key shards, geographically distributed, no standing network path
  • Warm float: policy-capped, same quorum and allow-list controls as cold
  • Cold-to-warm rebalances are quorum-approved transfers, logged end to end
What our insurance covers, tier by tier →

Transfer lifecycle

Every withdrawal passes policy before it passes on-chain.

A transfer at holdway is a five-stage pipeline, and no stage can be skipped — not by a client operator, not by a holdway employee, not by our own systems.

Initiation comes from your dashboard or POST /v1/transfers. Policy evaluation checks the destination against your allow-list, applies velocity limits, and collects the approval quorum you configured — commonly 3-of-5 across named officers. Time-locks, if set, hold the approved transfer for a fixed window in which any approver can cancel. Only then does the MPC signing ceremony run: key shards in separate locations co-compute a signature without any complete key ever existing anywhere. Finally the transaction is broadcast and confirmed, and the confirmation lands in your audit trail and webhooks.

  • Allow-lists, quorums, and time-locks enforced server-side, per policy you own
  • No single person, device, or location can produce a valid signature
  • Every stage timestamped in the immutable audit trail
Transfer API reference →
$20M
assets under custody, attested on-chain
1:1
reserves — full backing, never rehypothecated
SOC 2
Type II audited controls

Proof of reserves

Don't take our word for it. Check the chain.

Because segregation is per-client and on-chain, proof of reserves at holdway is not a quarterly PDF about a pooled balance. It is a per-client attestation you can verify yourself.

Each attestation cycle, holdway signs a message from every client vault address, proving control of the keys, and publishes the signed attestation alongside the address list and balances. Your auditor takes the artifact, checks the signatures, and reads the balances straight from a public block explorer — no reliance on holdway's own reporting. When a new attestation is published, the reserves.attested webhook notifies your systems with the signed payload.

  • Per-client attestation: your addresses, your balances, verifiable by anyone
  • Signed artifacts your auditor verifies independently of holdway
  • Delivered in dashboard, API, and the reserves.attested webhook
Proof-of-reserves reporting in detail →

Asset support

Fewer assets, held properly.

holdway supports BTC, ETH, and USDC across both storage tiers, plus allow-listed ERC-20 tokens on a per-token review basis.

We list deliberately. Before an asset enters custody it passes a listing review: contract audit history and upgrade-key analysis for tokens, legal classification in the jurisdictions we operate in, and operational rehearsal of deposit, withdrawal, and attestation flows in a staging vault. Assets that pass are supported in deep cold and, where clients need it, in the warm tier under the same policy engine. Clients can request a listing review for any ERC-20 through their account team.

  • BTC, ETH, USDC: cold and warm tiers, attestation-enrolled
  • ERC-20 tokens: per-token review covering contract, legal, and operational risk
  • Listing decisions documented and available to clients under NDA
Request an asset review →

Onboarding

Days, not quarters.

Institutional onboarding is usually slow because diligence is improvised. Ours is packaged.

Your team receives the holdway due-diligence pack up front: SOC 2 Type II report, penetration-test summary, insurance certificates, the custody agreement, and our regulatory disclosures — everything your risk and legal committees will ask for, in one drop. In parallel we run KYB on your entity, you define your transfer policy (approvers, quorums, allow-lists, time-locks, warm-float cap), and we provision and attest your segregated addresses. Most clients move from first call to funded vault inside two weeks.

  • Due-diligence pack delivered on day one, not assembled on request
  • Policy workshop: quorums, allow-lists, and time-locks set before funding
  • Named account and operations contacts from the first call, 24/7 thereafter
Our regulatory and compliance posture →

Segregated. Attested. Demonstrably yours.