Token launch treasury: custody, funds, and token allocations

Three goals that pull against each other

Running a treasury for a token project at launch looks simple on paper and breaks in predictable ways. You have two assets to protect at the same time: raised funds you need to spend, and token allocations that define how credible your economy looks to the market. The storage choices you make in the first week decide whether a bad day costs a day of inconvenience or the project itself.

The scale of the problem is not hypothetical. Chainalysis tracked over $3.4 billion in crypto stolen in 2025, with the Bybit breach alone accounting for roughly $1.5 billion of that total. In the first quarter of 2025, attacks on private key and signing infrastructure drove 88% of stolen value. These were not DeFi smart-contract exploits. They were custody and operational failures at centralized operators with professional security teams.

Treasury design at launch is really three goals pulling against each other, and you have to hold all three from day one. The first is security: protecting private keys and signing flows, because that is still the most common way token projects get drained. The second is operational continuity, because the project has to keep functioning when a signer is traveling, loses a device, or leaves the team. The third is accountability, a defensible record of who approved what and why it ties back to the tokenomics you communicated. Accountability is less about auditors and more about preventing the slow drift where an ops wallet quietly becomes the de facto treasury.

Four custody models, and when each one breaks

The custody choice at launch falls into one of four patterns. The right answer depends on how much value you control, how many trusted operators you have, and how fast you need to move.

A single wallet with a single signer is fast, simple, and a single point of failure. One compromised key drains everything. No second approval, no review step, no recovery path. Defensible only for testing balances or genuinely negligible amounts.

A single wallet with multi-signature approvals (M-of-N, typically 2-of-3 or 3-of-5) removes that failure mode and forces a review step, which catches wrong address, wrong chain, wrong decimal. The tradeoff is coordination. If the threshold is too high or signers are poorly distributed, you can lock yourself out when a signer becomes unreachable. A reasonable rule: avoid M=1 (the drain case) and avoid M=N (the lockout case).

Multiple wallets with independent single signers, split by purpose (ops, marketing, reserves), reduces blast radius. One compromise does not mean total loss. But you have multiplied the number of single points of failure, and security becomes "as strong as the weakest signer." Reconciliation also gets harder without disciplined bookkeeping.

Multiple wallets, each with its own multisig, is the strongest pattern and the most operationally complex. You get segmentation and approval controls together. You also need naming conventions, wallet inventories, signer rotation procedures, and documented transaction workflows from day one, not year one.

Here is the part that updated my thinking over the last year: multisig is necessary and not sufficient. The Bybit attack in February 2025 hit a 2-of-3 Safe multisig with hardware wallets on cold storage. Every best-practice box was checked. The attackers compromised the Safe{Wallet} UI upstream through a developer's machine, injected JavaScript that swapped the transaction payload between what signers reviewed on screen and what their Ledgers actually signed, and walked out with $1.5 billion. The operational lesson: if signers cannot verify raw transaction data independently of the wallet UI, multisig protects you against one bad key, not against a compromised interface.

Raised funds: segregate by horizon, cap the ops wallet, plan runway in stables

Raised funds are a cash-management problem first and a crypto problem second. The most common launch mistake is funneling everything through one address and hoping no one mis-signs a transfer. The second most common mistake is using the same wallet for payroll and reserves, so the entire treasury shares the risk profile of day-to-day tooling.

Segregate by time horizon, not by department. At a minimum: an operational wallet holding enough for near-term expenses, and a treasury vault holding the majority with stricter security and slower execution. The ops wallet pays routine expenses. The vault tops up the ops wallet on a schedule, with higher approvals. Limits turn catastrophic loss into bounded loss.

Plan fiat or stablecoin runway before you need it. Launch is when treasury volatility risk usually peaks: the token price is uncertain, markets are reactive, and costs spike (audits, market-making, legal, listings). A project running on volatile assets with no stable reserve is running on market timing. Twelve to eighteen months of stablecoin runway earmarked separately is the floor I would not go below, and that number goes up if you have obligations that do not flex with market conditions.

Separate who initiates, who approves, and who executes. The person who proposes a transfer is not the person who approves it, and neither is the only person who can broadcast it. That separation catches wrong address, wrong chain, wrong token, wrong decimal, and wrong counterparty before signatures are collected. It also forces an audit trail that holds up without requiring anyone to remember what happened in retrospect.

Write a one-paragraph policy for each wallet. If you cannot state what a wallet is allowed to do in a single paragraph, you do not have a treasury policy yet. "Treasury vault is not used for routine payments." "Marketing wallet can distribute tokens within a monthly budget." "Liquidity wallet is used only for market-making under signed terms." The policy is the constraint; the multisig is the enforcement.

Token allocations: separation is a credibility signal

Token allocations create a second treasury. Even if you store raised funds perfectly, poor allocation custody breaks market trust, triggers governance conflict, and creates sell-pressure shocks the tokenomics model never priced in.

Separate by category, mechanically. Treasury allocation, team vesting, advisors and partners, marketing and growth, community and ecosystem rewards all get their own wallet or vesting contract. Mixing categories is a credibility killer because the market cannot verify from on-chain data that team vesting is actually locked or that the treasury is not being drawn down for marketing. If you want holders to believe your schedule, make it legible in the addresses.

Use vesting and lockups as enforceable controls, not promises. The moment insiders can move "locked" tokens between internally controlled wallets, the market treats the lock as discretionary. Smart-contract vesting with independent beneficiaries is the enforceable version. Multi-party custody over the admin keys to that vesting contract is the version that survives a compromise.

A16z's published position, which most serious investors now use as the benchmark, is a four-year lockup with a one-year cliff, applied uniformly to insiders including founders, team, investors, and advisors. The one-year absolute hold after token generation is the part I would not negotiate down. Shorter lockups signal that the counterparty intends to sell at the first opportunity, and the SEC has used the absence of a one-year lockup to block token issuances. Anyone pushing for faster unlocks is not aligned with long-term success.

Protect the minter and admin authority on the token contract itself, not just the treasury wallet. This is the part most launches underweight. In February 2024, an attacker compromised the private key holding mint authority on the PLA token smart contract and minted 1.79 billion additional tokens, then kept minting even after bounty negotiations. The treasury can be perfectly secured and the token still rendered worthless if admin authority sits behind one key with one signer. Mint, pause, and upgrade authority on the token contract belongs behind a multisig with the same care as the treasury vault, or better.

If you are designing allocations and vesting right now and need to sequence them against the rest of the launch, our step-by-step token launch roadmap walks through the order of operations.

Operational controls: where drains and freeze-ups actually come from

Catastrophic treasury failures are almost never cryptography failures. They are process failures. A signer approves without reading. Someone signs on a compromised laptop. The team pays from the vault because ops is empty and no one flagged it. Access expands without documented authority. A signer leaves the team and nobody rotates them out of quorum.

Train signers to verify the actual transaction, not the UI. Signers should confirm chain, recipient address, asset and amount, method (simple transfer vs contract interaction), and match against the approved request, using tools that parse raw transaction data outside the wallet UI. Blind signing on a hardware wallet is the default setting that attackers rely on, and it is the specific behavior that turned a Safe multisig into a $1.5 billion loss.

Maintain a wallet inventory designed to survive turnover. Address, purpose, custody model, signer list, threshold, escalation contact. Store it somewhere finance and leadership can read and only treasury operations can edit. The test is whether a new treasurer can rebuild operational context in a day from the inventory alone.

Rotate signers deliberately. Churn is normal after launch. Without a rotation process you either accumulate dead keys that degrade quorum paths or concentrate control in a way that re-creates the single-signer problem. Write the rotation runbook before you need it, not after a signer has already left.

Have an incident response path that assumes you are stressed and tired. Who declares an incident, who can pause operations, which funds get moved to a backup vault, under what approvals, and what the internal and external communication plan looks like. One page is enough. Not having it written down is how a recoverable incident becomes an unrecoverable one.

Launch day and the first 90 days: a runbook you can actually run

Good custody architecture still fails if you do not operationalize it. The runbook below is designed to be executable by a small team while still meeting the security, continuity, and accountability goals. It assumes you have already worked through the broader token launch preparation.

Launch day (Day 0):

• Create and label all wallets before TGE: treasury vault, ops, allocation wallets.
• Dry-run signing with small test transfers on the actual signer devices.
• Distribute minted tokens to designated wallets immediately after TGE, then verify balances against the allocation table with a second-person cross-check.
• Lock down admin authority on the token contract so ownership goes to the intended governance entity, not the deployer address.
• Enable monitoring on treasury addresses, with alerts for outgoing transfers and unexpected contract interactions.
• Record the canonical internal address list: purposes, addresses, thresholds, signer mapping, initial distribution hashes.
• Put incident response contacts and escalation paths on one shared page.

First 90 days:

• Reconcile on a fixed cadence: daily for the first two weeks, then weekly, with every outflow mapped to an approved purpose.
• Top up the ops wallet on a schedule rather than draining from the vault ad hoc.
• Review signer availability and replace unreachable signers as governed actions.
• Run a key-loss tabletop exercise inside the first month and confirm that quorum and recovery steps actually work.
• Tighten controls as the treasury grows: more segmentation, fewer discretionary paths, more multi-party review.
• Review timelock and role configs any time governance changes, because misconfiguration can turn "delayed execution" into "immediate takeover."

Treasury policy is living documentation. Update the rules when tokenomics priorities shift, archive old rules for auditability, and make the current version the one everyone actually signs against. The gap between having good architecture and having good operations is where most of the money actually goes.

Hristo Piyankov

Lead token economist

Hristo is one of the best-known tokenomics designers in the industry. He is a top Web3 LinkedIn voice and a mentor in several high-profile accelerators such as Brinc and HyperNest. Hristo teaches a university masters degree in Cryptoeconomics and Decentralised Finance (DeFi). Having worked on over 300 tokenomics projects, he knows the ins and outs of token economies, what works and what does not.

Prior to working in crypto, Hristo was an Analytics Director and a Data Scientist for 12+ years in TradFi.