The problem: the same asset in the wrong place is the wrong asset
Once you settle revenue into a reference asset, it is tempting to think the treasury problem is solved. It is half solved. A balance of USDC is only useful if it is on the network you are about to pay over. USDC on Base does not fund an Ethereum ERC-20 payout, and USDT that accumulated as TRC-20 does not pay a counterparty who only takes ERC-20. The asset matches; the placement does not.
That placement comes from how money arrived, which is the customer's choice, not yours. A week of invoices and checkout payments leaves your stablecoin scattered across whichever networks customers happened to use. Left alone, that scatter quietly decides your payout costs — a Tron transfer and an Ethereum transfer draw from different balances and carry very different network fees — and occasionally decides whether a batch can go out at all.
Rebalancing is the deliberate counter-move: shift held value toward the asset and network your upcoming obligations actually require, on your schedule, before the obligation is due.
What rebalancing moves
Rebalancing operates over the assets and networks halfin supports for settlement. Two axes matter, and they compound: which asset you hold, and which network it sits on. A stablecoin position is really a set of per-network positions, and a payout draws from exactly one of them.
The table names where the same logical stablecoin can live across halfin's supported gates. Read it as the menu rebalancing draws from — the placements you can hold, and therefore the placements you can move value toward before a run.
| Asset | Networks it can sit on | Pays out cleanly to |
|---|---|---|
| USDT | Tron (TRC-20), Ethereum (ERC-20), Solana (SPL) | A counterparty on the same network the balance sits on |
| USDC | Ethereum (ERC-20), Base, Solana (SPL) | A counterparty on the same network the balance sits on |
| Native assets (BTC, ETH, SOL, XRP, BNB) | Their own chain | Their own chain — no cross-network placement choice |
Rebalance before the run, not during it
The failure mode rebalancing prevents is the mid-batch surprise: a mass payout starts going out over TRC-20, the TRC-20 balance runs short two destinations in, and the rest of the run stalls while someone scrambles to move liquidity. The fix is to make the move ahead of time, when it is a calm decision rather than an incident.
The pattern is straightforward. Before a single or mass payout run, look at what the run will pay out and on which network, compare that against where your held liquidity actually sits, and convert held value toward the network the run needs. A conversion that repositions liquidity is the same recorded balance operation as any other conversion — you are not bridging funds out to an exchange and back, you are moving value between assets and networks the platform already settles.
Because the run draws from a positioned balance, it funds cleanly from the first destination to the last. The work moved from the middle of the batch, where it is expensive and visible, to before the batch, where it is cheap and quiet.
- Look ahead at the next payout run: which asset, which network, how much.
- Compare against where your held stablecoin liquidity currently sits.
- Reposition held value toward that network before the run, as a recorded conversion.
- Let the run draw from a balance that is already in the right place.
Managing network exposure deliberately
Rebalancing is not only about funding the next run — it is about keeping the treasury in a shape your finance team chose rather than the shape last week's payments produced. If your business pays counterparties predominantly on one network, you want the bulk of your stablecoin positioned there as a standing posture, and you rebalance back toward it when revenue drifts your holdings elsewhere.
That is a treasury-policy decision, made by your team off-platform, that rebalancing then executes. halfin's role is to make the supported move clean and recorded: you decide the target asset and network, the conversion repositions held value, and the result lands in your balance with provenance. The platform does not pick your posture for you — it gives you a precise tool to hold the one you picked.
The same discipline keeps costs predictable. Network fees differ sharply between chains, and the cheapest network to receive on is not always the cheapest to pay out on. Deliberate placement lets you choose where value rests with payout economics in mind, instead of paying whatever the incidental distribution of incoming payments imposes.
Where rebalancing sits next to automatic and manual conversion
Treasury rebalancing is not a separate engine — it is balance conversion used with intent toward placement. The three ways merchants use conversion line up cleanly, and most teams run all three.
Automatic conversion handles the steady stream, settling mixed incoming assets into your reference asset on credit. Manual conversion handles the periodic, judgment-based moves you trigger yourself. Rebalancing is the placement-focused slice of that manual work: the move whose purpose is specifically to get the right liquidity onto the right network before you need it.
| Mode | Trigger | What it optimizes for |
|---|---|---|
| Automatic conversion | On credit, as payments land | Revenue settling into one reference asset with no manual step |
| Manual conversion | When you decide | Consolidating leftover assets; converting on your terms |
| Rebalancing | Before a payout run, or as a standing posture | Right liquidity on the right network when an obligation is due |
Reading where your liquidity sits
Rebalancing starts with knowing the current distribution, and that comes from the same REST API you already use for invoices and payouts. Balances are read at api.thehalfin.com/api/v1; each entry reports the asset, the network it sits on, and the amount, which is exactly the per-network breakdown a rebalancing decision needs. The only header a public request carries is your API key — there is no separate integration to stand up for treasury reads.
Use the API balance as the source of truth for what you hold and where, decide the move, and treat the conversion that repositions value as a change to those same balances. Conversions are recorded against balance history with provenance, so the repositioning reconciles against the events your accounting system already consumes rather than appearing as an unexplained adjustment.
# See where each balance sits before deciding what to rebalance
curl https://api.thehalfin.com/api/v1/balances \
-H "X-API-Key: $HALFIN_API_KEY"
# Each entry reports asset, network, and amount — that is the
# per-network breakdown a rebalancing decision is made from.
# Amounts are JSON strings; never parse them as floating-point numbers.What rebalancing does not do
Rebalancing moves value between the crypto assets and networks you already hold on the platform. It is not a fiat off-ramp: it does not turn held crypto into a bank-settled balance, and "holding in USD" here means holding a USD-denominated stablecoin positioned where you want it, not a fiat account.
It also depends on a supported conversion route existing between the source and target placements. Where a direct route is not available, the source balance stays held and you decide what to do with it — the platform makes the supported moves clean and recorded rather than promising a path between every possible asset-and-network pair.
And rebalancing is a treasury operation, not a custody guarantee. The controls here are the platform's standard ones — scoped API keys, operator permissions, and a full audit trail of every recorded move — and nothing beyond signing, permissions, and audit should be read into it.