What treasury management means on a crypto stack
A payment stack solves two visible problems — accepting money and sending it — and quietly creates a third. Acceptance is deliberately permissive: you let customers pay in whatever they hold, because the asset they reach for is the asset most likely to convert. The cost of that permissiveness is asset sprawl. Every invoice that settles in a new asset or on a new network is another balance line, and lines accumulate faster than anyone reconciles them.
Treasury management is the set of decisions that keeps that sprawl under control: which asset you actually want to hold, how much exposure to volatile assets you are willing to carry, and which networks need a funded balance so your payouts can go out. None of these are blockchain operations — they are finance decisions. The platform's job is to make each one a single, observable action rather than a round-trip through an external exchange.
Concretely, halfin gives you three primitives for this, and the rest of the guide walks each in turn. Balance conversion turns one held asset into another. A chosen settlement asset — usually a stablecoin — is the target everything converges toward, so the balance in your books is denominated the way you manage it. And rebalancing across networks moves value to the rails your outbound flow draws from, so a payout never stalls for want of funds on the right chain.
- Asset sprawl is the default outcome of permissive acceptance — treasury work is cleaning it up.
- The decisions are financial (what to hold, how much exposure, which rails to fund), not on-chain plumbing.
- Three primitives cover it: balance conversion, a chosen settlement asset, and cross-network rebalancing.
- Everything stays asset-to-asset and on-chain — there is no fiat off-ramp in this flow.
The boundary: asset-to-asset, never a fiat off-ramp
Before any workflow, fix the boundary, because it governs what you can and cannot plan around. halfin balance conversion moves value between supported crypto assets — native SOL into USDC, ETH into USDT, BTC into a stablecoin you hold. What it does not do is sell crypto for fiat and wire dollars or euros to a bank. There is no on-ramp either: halfin never sells crypto to your customers. The treasury you manage here is, start to finish, a crypto treasury.
That changes how you think about "settling." On a card stack, "settle" means the money lands in a fiat bank account and the crypto question is gone. Here, "settle" means you have converged a messy multi-asset balance into one or two reference assets you have decided to hold. Holding a stablecoin is the closest analogue to holding cash, and for most merchants it is the right reference asset — but it is still an on-chain balance, not a bank deposit, and you should plan custody, accounting, and exposure accordingly.
If your actual requirement is dollars in a bank, that is a separate off-ramp relationship outside halfin, and nothing in this guide substitutes for it. What this guide does cover is everything up to that line: getting your crypto holdings into a clean, low-volatility, well-distributed shape so that whatever you do next — hold, pay out, or off-ramp elsewhere — starts from order instead of scatter.
Step 1 — Choose a settlement asset and convert toward it
Start by deciding the one asset your treasury converges on. For most merchants that is a stablecoin — USDT or USDC — because a stablecoin balance is the closest thing to holding cash on-chain: the number in your books does not swing with the market between the moment a customer pays and the moment you reconcile. Pick the stablecoin and network your downstream flow already favours; if you pay contractors in USDT on Tron, holding TRC-20 USDT means your treasury and your payout rail speak the same asset.
With the target chosen, automatic conversion does the day-to-day work. You set the settlement asset once, and when an invoice is paid in something else, the incoming balance is converted toward that target as part of the credit flow. A customer pays in native SOL against a USDC target; what lands in your balance is USDC. There is no end-of-day batch to remember and no window where a volatile asset sits un-managed waiting for someone to act on it.
One behaviour to design around: conversion only fires when a supported route exists between the asset received and your target. When no route applies, the original asset is credited as-is and stays visible in your balance — nothing is lost or hidden. That fail-open rule means a payment is never blocked because a conversion could not run, but it also means your converged balance can still carry the occasional un-routed asset. That residue is exactly what manual conversion is for.
- Pick one settlement asset — usually the stablecoin and network your payouts already use.
- Turn on automatic conversion: incoming payments convert toward the target on credit, no daily batch.
- Conversion is fail-open — an un-routable asset is credited untouched and stays available to convert later.
- A stablecoin balance manages volatility, but it is still an on-chain balance, not a bank deposit.
Step 2 — Mop up the residue with manual conversion
Automatic settlement handles the bulk, but a real treasury always has a tail: the assets that arrived without a conversion route, the dust left from rounding, the BTC a customer insisted on paying with against your USDC target. Manual conversion is the on-demand counterpart — you decide what to convert, into what, and when, instead of converting reflexively on every credit.
Run it on a cadence rather than per-payment. A weekly pass over the balance is usually enough: open the dashboard, look at what accumulated outside your settlement asset, and convert the lines worth converting into your reference asset. Some dust is not worth the network fee to move, and there is no rule that says a treasury must be a single asset to the last unit — converge the material balances and let trivial dust sit until it is worth touching.
Manual conversion is also your control for deliberate exposure. If you have a policy reason to hold a position in a non-stable asset — say you keep a portion of revenue in BTC by choice — you leave automatic conversion off for that asset and convert manually only when your policy says to. The point of separating automatic from manual is that one removes work you do not want to think about, and the other gives you a deliberate hand on the balance when you do.
Step 3 — Rebalance across networks so your payouts can fund
Converging on a single asset is not the whole job, because the same stablecoin lives on several networks and they do not move money between themselves for free. You can hold USDT on Tron, on Ethereum, and on Solana; a payout draws from the balance on the network it is sent over. If your inbound flow fills up TRC-20 USDT but your contractors are paid USDC on Base, the asset is right and the rail is empty — and the payout has nothing to draw on.
Rebalancing is moving value to the networks your outbound flow actually uses, ahead of needing it. The signal to watch is the gap between where balance accumulates and where payouts draw from. Inbound tends to concentrate on low-fee, high-liquidity rails because that is what customers reach for; outbound is dictated by what your recipients can receive. When those two diverge, you rebalance to close the gap before a payout run, not during one.
Think of conversion and rebalancing as two axes of the same job. Conversion changes which asset you hold; rebalancing changes which network you hold it on. A clean treasury is correct on both axes at once — the right asset, sitting on the rail your next payout will spend from — so that releasing a batch of payouts is never blocked by funds being in the right asset on the wrong chain.
| Treasury move | What it changes | When you reach for it |
|---|---|---|
| Automatic conversion | The asset incoming payments settle into | Standing policy — set the target stablecoin once and let payments converge |
| Manual conversion | A specific held balance, converted on demand | Weekly cleanup of un-routed assets and dust, or a deliberate exposure decision |
| Cross-network rebalancing | Which network a held asset sits on | Before a payout run, when inbound and outbound rails diverge |
| Holding a non-stable asset | Deliberate exposure you keep on purpose | A policy position — automatic conversion left off for that asset |
Step 4 — Read the balance over the API for your own dashboard
Treasury work runs on visibility, and you do not have to live in the halfin dashboard to get it. The same balances you convert and rebalance are readable over the public REST API with a scoped API key, so you can pull them into your own finance dashboard, a daily Slack digest, or a reconciliation job that flags when an asset has drifted outside your settlement target.
The call below reads your current balances. As everywhere in the platform, amounts come back as strings — keep them as strings through your reporting and never let a balance become a JavaScript number, or binary-rounding drift will quietly desync your dashboard from the chain. Use a read-only key for this: the job that displays your treasury should not hold a credential that can move it.
From there the pattern is straightforward. Read the balances on a schedule, compare each line against the asset and network you intend to hold, and surface the deltas — this asset is outside your settlement target, that rail is under-funded for the next payout run. Those deltas are precisely the conversion and rebalancing actions from the steps above, now driven by data instead of by remembering to look. The full balance schema lives at docs.thehalfin.com.
# Read current merchant balances to drive your own treasury dashboard.
# Use a READ-ONLY scoped key — the reporting job should not be able to
# move money. Amounts come back as strings; keep them as strings.
curl -sS https://api.thehalfin.com/api/v1/balances \
-H "X-API-Key: $HALFIN_READONLY_API_KEY" \
-H "Content-Type: application/json"
# Each line is an (asset, network, amount) you can compare against your
# settlement target: anything outside it is a conversion candidate, and a
# rail that's thin for your next payout is a rebalance candidate.
# See docs.thehalfin.com for the full balance response schema.A workable weekly rhythm
None of this has to be elaborate. A small, repeatable rhythm beats an ambitious framework nobody follows, and most merchants can run a sound crypto treasury on a weekly loop plus one standing setting. Set the standing setting once; run the loop on a cadence.
The standing setting is automatic conversion to your chosen stablecoin — that single switch keeps the bulk of inbound flow converging on the asset you hold without anyone touching it. The weekly loop is three quick passes: convert the residue that automatic conversion did not route, check whether any outbound rail is thin for the payouts you are about to release, and rebalance to close that gap before the run. Drive all three from the API read in the previous step so the loop is reacting to the actual balance, not to memory.
- Standing: automatic conversion to your settlement stablecoin — set once, leave on.
- Weekly: manually convert un-routed assets and dust into the settlement asset.
- Weekly: check outbound rails against the next payout run and rebalance any thin one.
- Drive the loop from a scheduled balance read, not from remembering to check the dashboard.