A Wallet Is Not a Treasury: Designing Stablecoin Operations for Merchants

1. Start with roles, not a wallet count

The word wallet collapses several concepts: an address, signing device, user interface, contract account and sometimes a custody service. Treasury design begins by separating business roles. An intake address receives payments; a settlement account moves balances on an agreed cycle; a refund account funds reversals; a gas account holds each network’s native asset; a reserve protects long-term exposure; and a quarantine address isolates an unexpected asset until it is reviewed. Separation makes clear what each balance is allowed to do.

Not every role requires a separate technology stack on day one. A merchant may use one contract account with internal policy, several smart accounts, or a combination of self-custody and an external custodian. What matters is explicit boundaries: who owns the economic claim, who may propose an action, who may approve it, which destinations are permitted and which business event justifies movement.

The map must include funds in motion. A balance that has been observed but is not yet final is not the same as available cash. An approved refund that has not been broadcast is a liability. A failed transaction is not an expense, but it may leave a nonce blocked or an allowance open. Once those states are defined, the dashboard shows operational truth rather than a momentary explorer snapshot.

• Intake — receive payments without discretionary spending authority.
• Operations — payouts and refunds under transaction and daily limits.
• Reserve — protected balance with a higher threshold and execution delay.
• Gas — network-specific operating inventory with alerts and controlled replenishment.

2. Give every route a risk budget

The useful question is not only how much value the treasury holds, but how much can move before operators have time to stop an error. Define a maximum per action, cumulative hourly and daily caps, destination allowlists, permitted assets and networks, and a waiting period above selected thresholds. Controls need enforcement at the execution layer, not only a warning on the screen.

Not all routes deserve the same policy. A small gas top-up to a known service address may run automatically. A refund to a new address can require a second approval. A recurring sweep from intake to settlement may be scheduled, while a reserve withdrawal requires more signers, a delay and an out-of-band destination check. Automation can therefore grow without granting one process unlimited power.

Measure funds at risk as well: the maximum value movable by a given combination of keys, permissions and systems. The number reveals hidden concentration. Three signers do not provide meaningful separation if they work from the same machine, rely on the same password manager, or can jointly change the allowlist and the amount cap in the same immediate action.

3. A key is an asset with a lifecycle

NIST SP 800‑57 treats cryptographic keying material as something managed across a full lifecycle: generation, distribution, storage, use, backup, recovery, replacement and destruction. For a stablecoin product, selecting a hardware wallet or HSM is therefore not enough. The team needs to know who generated the key, how the environment was verified, which copies exist, who can activate them, when they rotate and how it proves that old authority has ended.

Maintain an inventory for every signer: owner, purpose, permitted environment, activation date, review date and revocation path. Do not store a seed phrase beside its recovery instructions or depend on one person who alone knows where the backup lives. Uncontrolled duplication is not resilience either; it expands the attack surface. The goal is managed redundancy—enough independent paths to survive loss, without enough casual access to bypass policy.

Rotation is more than replacing a key. Owners, roles, modules, relayers, webhook secrets, access lists and support runbooks may all need updates. Each transition requires a rollback plan and an observation period in which the old key is blocked from signing but retained for historical verification. If the system cannot identify every workflow still depending on the old identity, the rotation is not complete.

4. Smart accounts express policy—and add attack surface

ERC‑1271 lets a contract validate a signature through isValidSignature, so authority does not have to belong to a single private key. A smart account can require a signing threshold, verify roles, restrict time or apply additional logic. This is a useful foundation for organisational treasury because policy can be inspected and enforced onchain rather than remaining an informal human agreement outside the system.

A Safe account, for example, uses an owner list and signature threshold and can be extended with modules and guards. Extension enables automation, but Safe’s official documentation warns that a faulty guard can block actions and may lock funds. Treat every new module as a production change: use known and reviewed code, grant minimal authority, test against a fork, roll out with a limited balance and verify the removal path before enabling it.

A two-of-three threshold protects against losing one signer, but it does not answer every authority question. Who may add an owner, lower the threshold, enable a module or replace an approved destination? Meta-administrative actions may need a higher threshold and a longer delay than routine transfers. Control over policy is at least as important as control over the current balance.

5. Least privilege, roles and execution delays

A single owner is simple to understand but gives one identity broad power. Role-based access can separate an operator who prepares an action, an approver who confirms it, a guardian who can stop it and an administrator who maintains policy. OpenZeppelin’s access-control guidance emphasises least privilege and offers role, central management and delay mechanisms. The decisive design question is not only which contract to use, but which powers must never share one role.

A delay creates response time. An allowlist change, contract upgrade or unusual transfer can enter a queue before execution. An independent monitoring path sends an alert, and a guardian can cancel the action. Delay is not a substitute for review; it converts an instant mistake into an event that can be detected and stopped. Emergency paths should remain narrow, low-value and more heavily logged.

The operator interface must show the context being signed: network, asset, token contract, destination, human-readable and base-unit amounts, proposer role, request origin and policy version. Signing an opaque hash is an operational weakness. Simulation helps, but it is not the sole source of truth; the system must compare the simulated effect with the approved business intent.

6. Gas is operating inventory, not accidental residue

A multichain treasury carries two types of inventory: the settlement asset and the network-native asset required to move it. A merchant may hold USDC on Base, Polygon and Ethereum, yet still need ETH or POL to execute. A wallet full of stablecoins but empty of gas is not an operational balance. Define a floor, target, ceiling and expected consumption rate for every active network.

Automated gas replenishment must be limited to known addresses and networks, with a cap and cooldown. Otherwise, a compromised service can drain gas inventory through a stream of small transfers. Monitor the opposite anomaly as well: a rapid increase in consumption may indicate a retry loop, fee change, spam or malicious activity. The meaningful metric is runway—how many expected actions remain before the route stops.

Do not depend on one fast bridge as the only emergency supply route. A bridge adds contract, liquidity and timing risk exactly when certainty matters most. Keep a small controlled buffer on each active network, replenish it through a documented path and rehearse a period when a network is unavailable. If gas is exhausted, the product should stop taking new commitments it cannot complete.

7. Rebalancing is a business process with decision rules

Automatically sweeping every intake address into reserve sounds efficient, but it can move an unrecognised token, remove refund capacity or create hundreds of expensive transactions. A sound policy defines the target balance at each layer, a minimum transfer size, time window, network, maximum gas price and approved destination. The engine proposes an action; policy decides whether to execute, wait or escalate.

Not every visible balance is surplus. Part may cover approved refunds, unsettled merchant claims, platform fees or an operating buffer. Rebalancing must therefore read the ledger, not only balanceOf. The difference between an onchain balance and economically available funds is a liability that must be explained before value moves.

Across networks, the merchant can keep local liquidity, bridge value, or redeem and reacquire it. Each route carries a different cost and risk. Decide using amount, time, finality, liquidity and total cost—not only the gas estimate visible now. Retain the quote, route, approvals and result so alternatives can be compared after execution.

8. Reconciliation and evidence: every movement needs a full story

The chain shows what executed; the ledger explains why. Every action needs a business identifier linking the request, proposer, approver, policy version, simulation, signatures, transaction hash, receipt and accounting entries. If an action is resubmitted, preserve the relationship between attempts. If it is cancelled, the cancellation decision is an event too. The organisation can then reconstruct reasoning without depending on an operator’s memory.

Daily reconciliation should compare balances, transfers, pending transactions, gas expense, refund liabilities and merchant claims. A difference is not fixed by editing a row. It becomes an exception with severity, owner and service level. Common breaks include an unapproved token, a transfer to an old address, a replaced transaction, incorrect decimals or duplicate posting after a repeated webhook.

Evidence should live outside the system that initiates payments. An attacker who compromises an operator workstation should not also be able to erase the audit record. Independent storage of hashes, configuration versions and approval events makes later alteration visible. Privacy still matters: there is no reason to retain seed material, raw signatures or personal information beyond what control and investigation actually require.

9. Rehearse recovery before the incident

An incident plan should name concrete scenarios: a signer is lost, an operator workstation is exposed, an API creates duplicate payouts, a module behaves unexpectedly, a network halts, or an address receives the wrong asset. Each scenario needs a detection condition, accountable role, containment action, communication path and return-to-service criterion. A runbook that has never been exercised is an assumption, not a capability.

A useful drill measures time from alert to route shutdown, time to replace a signer, funds at risk, number of manual steps and the ability to reconcile after the event. There is no need to endanger production funds; teams can use a mirrored environment, testnet or tightly limited value. The important point is to execute the owner change, module stop, secret rotation and report reconstruction rather than merely discuss them.

A practical build sequence is: role and balance map; ledger and segregation; signer inventory; smart account and approval thresholds; allowlists and limits; gas management; rebalancing; evidence log; and a recovery drill before adding another network or asset. Dor Arad’s product principle here is simple: a good treasury is not one that never fails, but one that limits the effect, explains what happened and returns to service under control.