Crypto Custody Solutions for Token Teams: How to Choose
A crypto custody solution is the combination of technology, key management policy and legal structure that decides who can move your project's assets and under what conditions. For a token team, the right choice is rarely a single product. Most projects end up running a mix: a multisig or MPC wallet for the treasury, hot wallets for day-to-day operations, and a qualified custodian for anything that has to sit inside a regulated perimeter. This guide covers how the options actually differ, how to split funds between them, and the questions to ask before you sign with a provider.
The stakes are simple. A treasury that is stolen or frozen is a project that stops shipping. A treasury that is so locked down that nobody can fund a market maker or pay a contractor is a project that stops moving. Custody design is the trade-off between those two failure modes.
The Three Custody Models
Almost every crypto custody solution sits in one of three categories. They are not competitors so much as tools for different jobs.
Self-custody with multisig
Keys are held by your own signers, and moving funds requires a threshold of approvals — commonly 3-of-5 or 4-of-7 across founders, a CFO or ops lead, and sometimes an external advisor. Smart contract wallets on EVM chains are the standard implementation, with hardware wallets holding each signer's key.
Strengths: no counterparty holds your assets, on-chain transparency, low direct cost, and full composability with DeFi and on-chain governance. Weaknesses: you own the entire operational burden. Signer turnover, lost devices, and the discipline of never letting a quorum of keys sit in one physical location are your problems alone. Multisig is also chain-specific — a Solana or Bitcoin treasury needs different tooling from an EVM one.
MPC wallets
Multi-party computation splits a single private key into shares that never combine. Signing happens collaboratively, so no complete key exists anywhere. Providers layer a policy engine on top: spending limits, whitelisted addresses, role-based approvals, and audit logs.
Strengths: cross-chain coverage from one policy framework, granular controls that map to how a company actually operates, and better operational tooling than raw multisig. Weaknesses: you depend on a vendor's software and infrastructure, transactions are less transparent to your community than an on-chain multisig, and pricing is usually a platform fee plus per-transaction or per-asset charges.
Qualified and regulated custodians
A licensed entity holds the assets on your behalf under a custody agreement, typically with insurance, segregated accounts, and regulatory oversight in a named jurisdiction. This is the model institutional investors, exchanges and funds expect.
Strengths: legal clarity, insurance, audit-friendly reporting, and credibility with counterparties who will not deal with a project holding everything in a founder's hardware wallet. Weaknesses: onboarding takes weeks, withdrawal windows are slower than a self-custody transaction, fees are meaningful, and you inherit the custodian's own solvency and regulatory risk.
Comparing the Options
| Dimension | Multisig | MPC wallet | Qualified custodian |
|---|---|---|---|
| Who holds keys | Your signers | Key shares split between you and provider | The custodian |
| Setup time | Hours | Days | Weeks (KYC, legal, onboarding) |
| Speed of movement | Fast, limited by signer availability | Fast, policy-gated | Slowest, withdrawal windows apply |
| Chain coverage | Per-chain tooling | Broad, one interface | Depends on provider's supported list |
| Direct cost | Lowest | Platform and usage fees | Highest, often basis points on assets |
| Insurance | None by default | Varies, often limited | Usually included, read the limits |
| Counterparty risk | None | Vendor software and infrastructure | Full custodian credit and legal risk |
| Investor perception | Acceptable if disclosed | Good | Strongest |
| Best used for | Community-visible treasury, on-chain governance | Operating funds, multi-chain ops | Locked allocations, fiat rails, institutional mandates |
There is no single winner. The mistake is picking one and forcing every use case through it.
Splitting Funds by Purpose, Not by Provider
Design custody around what each pot of money has to do. A practical split for a post-TGE project looks like this.
Long-term treasury. The bulk of unallocated tokens and stablecoin reserves. Optimise for security over speed. Multisig with a high threshold, geographically distributed signers, and a public address the community can verify. Movements here should be rare and announced. This is also where a disciplined treasury policy does most of its work — custody enforces the policy, it does not replace it.
Vesting and locked allocations. Team and investor tokens under a vesting contract. The contract itself is the custody mechanism; what matters is who controls the admin keys and whether they can be revoked. If your vesting schedule has an upgradeable admin controlled by one wallet, your vesting is theatre. Renounce or multisig the admin.
Operating funds. Payroll, vendors, marketing, gas. Weeks of runway, not years. MPC with spending limits and address whitelists fits well — the finance lead can pay an invoice without pulling three founders out of meetings.
Exchange and market making balances. Funds sitting on venues or allocated to a market maker. Never larger than the mandate requires. This is the pot most teams get wrong, either by over-funding an exchange account or by giving a market maker custody it does not need.
Emergency reserve. A small, separately controlled pot that lets you pay for an audit, a legal opinion or an incident response firm on a day when the main treasury is unreachable.
How Custody Interacts With Market Making
Market making is the most common reason a token team hands assets to a third party, and it is worth being precise about what the arrangement requires.
Under a loan or call-option model, the market maker borrows tokens and holds them in its own accounts. That is real custody transfer and real counterparty risk. Judge the maker on balance sheet, track record and contract terms, size the loan to the liquidity you actually need, and insist on reporting.
Under a retainer model, the project typically funds sub-accounts on the exchanges it lists on and grants the maker trading-only API access. Withdrawal permissions stay off. Assets never leave accounts your project controls, and you can revoke access with an API key deletion. For most teams this is the cleaner structure, and it is how Fibonacci Capital prefers to work — trading permissions, not custody.
Whichever model you use, the controls are the same: API keys scoped to trade only, IP whitelisting where the exchange supports it, withdrawal whitelists set to your own addresses, and a scheduled key rotation. Get this right and the choice between retainer and loan becomes a commercial decision rather than a security one.
Due Diligence Checklist for Custody Providers
Before signing with any crypto custody provider, get written answers to these:
- Legal entity and jurisdiction. Which entity signs the agreement, where is it licensed, and what regulator supervises it? A group brand name is not an answer.
- Segregation. Are your assets held in segregated accounts or commingled with other clients' and the provider's own funds? Get it in the contract.
- Insurance. What is covered — cold storage only, or hot wallets too? What is the policy limit, is it per client or shared across the whole book, and what exclusions apply? Ask for the certificate.
- Key ceremony and recovery. How are keys generated, where are shares held, and what is the documented recovery path if the provider disappears or you lose your own share? A provider with no client-side recovery option is a single point of failure.
- Policy engine. Can you enforce spending limits, whitelists, and multi-approver rules that mirror your internal roles? Can approvals be revoked instantly when someone leaves?
- Audits and attestations. SOC 2 Type II or equivalent, plus recent penetration test summaries. Ask when the last one was, not just whether one exists.
- Chain and asset support. Does it cover your chain today, including your own token contract, or is it on a roadmap?
- Withdrawal SLAs. How fast can you move funds in normal conditions, and what happens during market stress? Ask specifically about weekends and holidays.
- Exit path. How do you get everything out and terminate the relationship? What notice is required, and what does it cost?
- Fees, fully loaded. Platform fee, per-asset fee, per-transaction fee, network fee handling, and minimums. Model it against your actual transaction volume.
If a provider is slow or vague on segregation, insurance limits, or the exit path, treat that as the answer.
Operational Controls That Matter More Than the Product
Most crypto losses at token projects are not cryptographic failures. They are process failures: a single person able to move funds, a signer using a phone as a hardware wallet, a compromised laptop approving a transaction nobody else read.
The controls that consistently pay off:
- Separation of duties. The person who initiates a payment should not be the person who approves it. This holds at any team size above two.
- Address whitelisting with a delay. New destination addresses should require a second approver and a time lock before first use. Most drain attacks depend on a fast, unreviewed first transfer.
- Transaction simulation and blind-signing discipline. Signers should see decoded transaction details, not a hash. Make "I could not read what I was signing" an automatic decline.
- Signer hygiene. Dedicated hardware devices, no shared seeds, no cloud backups of seed phrases, and geographic distribution so no single event reaches a quorum.
- Offboarding as a fire drill. When someone leaves, rotate the multisig, revoke MPC roles, and delete their API keys the same day. Write the runbook before you need it.
- Quarterly rehearsal. Actually practise a recovery. A recovery process that has never been tested is an assumption.
- Disclosure. Publish your treasury addresses and custody model. Projects that go quiet about where funds sit invite exactly the speculation they are trying to avoid, and transparency here supports the broader work of building investor confidence.
Matching Custody to Your Stage
Pre-launch. Multisig for the treasury, hardware wallets for signers, and a documented policy. You do not need a qualified custodian to raise a seed round. You do need to show you have thought about it.
At TGE. Add operating separation, get API-key controls right before exchange accounts are funded, and lock deployer and admin keys behind the multisig. This is the moment when the number of wallets and counterparties jumps, and it is the moment most avoidable mistakes are made. Preparation here sits alongside the rest of your launch readiness work.
Post-launch, institutional traction. When funds, exchanges or regulated partners are diligencing you, a qualified custodian for a portion of the treasury becomes worth the cost. It answers a question their compliance team has to ask.
Scale. Multi-custodian, so that no single provider failure is existential, with formal signing policies and an annual external review.
The Bottom Line
Choosing a crypto custody solution is a design exercise, not a purchase. Split funds by purpose, match each pot to the model whose trade-offs suit it, and put more effort into your operational controls than into vendor selection. The provider matters; the process matters more.
Custody also shapes how well your token trades. Funds locked in the wrong place cannot seed liquidity, and market making arrangements that quietly transfer custody create risks that show up long after the contract is signed. Fibonacci Capital works with token teams on liquidity structures that keep control where it belongs — get in touch if you want to talk through how your custody setup and your market making mandate fit together.