Wallet security for token teams

One wallet is the whole problem

Nearly every project fund loss in this space traces back to the same structural decision, made early and never revisited: one address doing everything.

It holds the treasury. It receives fees. It funds operations. It connects to sites when somebody needs to check something. It signs approvals. It has been pasted into a tool at some point. Each of those is individually reasonable and the combination is a single point of failure with everything behind it.

The fix is not sophisticated and it is not expensive. It is separation, and it costs an afternoon of setup that most teams never spend because nothing has gone wrong yet.

A structure that works

The treasury rule is the one that matters most and the one most often broken for convenience. A wallet that never connects to anything cannot be drained by an approval, cannot be caught by a malicious site, and is exposed only to its own key handling. That single discipline removes most of the risk surface for most projects.

The disposable tier is underused. When something needs testing, when a site is unfamiliar, when a link came from somewhere uncertain, a wallet holding almost nothing removes the consequences of being wrong. Treat those as consumable and abandon them freely.

What a signature actually authorises

This is where the largest gap between intuition and reality sits, and it is worth being precise.

Connecting a wallet to a site reveals your public address. That is all it does on its own. The risk is in what you sign afterwards, and signatures are not all the same thing.

A transfer moves a specific amount once. An approval grants a program ongoing permission over a token account, and that permission persists until it is revoked rather than expiring after use. A signature request that looks routine can therefore create a standing authority you have forgotten about by the time it is used.

Two habits follow. Read what a request actually does rather than which site it came from, because the site is not what is being authorised. And periodically review outstanding approvals and revoke the ones you no longer need, which takes minutes and closes doors that were left open months ago.

Where keys should never be

• In a message. Chat history is a permanent, searchable, frequently breached archive.
• In a shared document. Access lists grow, and nobody audits who can still open what.
• In a screenshot. Which then syncs to a cloud photo library automatically.
• In source code, including a private repository, because private is a setting rather than a guarantee.
• Pasted into a website for any reason whatsoever, regardless of the explanation offered.
• In an environment variable on a shared machine, where every process running as that user can read it.

The pattern across all six is that a key stops being secret the moment it exists anywhere it can be copied without you noticing. The seed phrase deserves the same treatment and more, because it derives every wallet in the set rather than one.

Two operational habits belong alongside the structure and cost nothing. Label every wallet somewhere the team can see, so that a transfer from an unfamiliar address is immediately recognisable as yours or not. And keep the number of wallets that hold anything meaningful small enough that you could list them from memory. Sprawl is what turns a security question into an archaeology exercise, and the moment you need the answer quickly is the moment sprawl is most expensive.

Handing anything to a service

The rule that resolves nearly every case is to ask what the stated product actually requires.

A service producing trading activity needs wallets it controls and funds itself. It needs your token's mint address, which is public information, and a payment. It does not need signing authority over anything you own, and there is no instruction in that workflow that requires it. The custody guide covers the same question in more detail, and the scam guide covers how the request is usually framed when it comes.

Self-hosted tools raise a different version of the problem. A script generating and holding fleet keys is doing exactly what it should, and the question becomes what else the code does with them. Fund such a fleet from a wallet holding nothing else, read the key handling path specifically rather than skimming the repository, and never let it near anything holding supply or treasury. The self-hosting guide covers the rest of what that choice involves.

A structural upgrade worth considering once a treasury holds anything meaningful is requiring more than one signature to move it. Multi-signature arrangements are more work to set up and more work to use, and both of those are the point: a compromised device on one team member no longer reaches the funds, and no single person can move them alone. The threshold at which this becomes worth the friction is lower than most teams assume, and the moment it becomes obviously worth it is usually the moment it is already too late to arrange.

What to do after a compromise

Speed matters more than tidiness, and the order below is deliberate.

1. Move what remains, immediately, to a wallet created on a device you are confident about. Do not investigate first.
2. Treat the whole seed as compromised. Every wallet derived from it is exposed, not only the one that was drained.
3. Revoke outstanding approvals from the affected addresses, since a standing permission survives an empty balance.
4. Work out how it happened before creating replacements, because recreating the same structure recreates the same exposure.
5. Say something publicly if project funds were involved. Holders will notice the movement, and silence during the gap is read as something worse than the truth.

The last point connects to the broader principle. Wallet structure is a security decision and it is also a communications one, because every transfer you make is public and will be interpreted by somebody. Labelled wallets, separated by function, with unusual movements explained before they are noticed, remove an entire category of situation where nothing wrong happened and everyone assumed it had.