The first question is not "which coin." It's "what should this balance be doing while it sits there?"
Every merchant we onboard asks the same thing within the first week: what currency do I actually end up holding? It's a fair question, and the honest answer is that it's a decision, not a default. You get paid in whatever asset the payer sent — BTC, ETH, USDT on Tron, USDC on Base, SOL — and from there you choose what that balance becomes. There are exactly three answers, and most businesses pick the wrong one first because nobody framed it as a choice.
Before anything else, one boundary that saves a lot of disappointed support tickets: a settlement currency on halfin is always a digital asset. Balance conversion moves you between crypto — USDT to USDC, ETH to a stablecoin, SOL to USDT. It does not end at a bank account. If your plan depends on dollars landing in a checking account, that's a separate off-ramp problem, and halfin isn't it. Everything below assumes you're choosing between assets you'll continue to hold on-chain.
Option one: hold the asset you were paid in
The simplest posture is to do nothing. The payer sends USDT on Tron, your balance grows in USDT on Tron, and it stays there until you spend it on a payout or a conversion later.
This is the right call more often than people expect. If you already pay suppliers, affiliates, or contractors in the same assets you collect, holding is the cleanest path — the coin walks in the front door and out the back door without a single conversion in between. Marketplaces that collect USDT and pay sellers in USDT are running a closed loop. Don't add a conversion to a loop that's already balanced; you'd just pay network fees twice and add a moving part that can break.
The thing to actually watch isn't volatility — it's fragmentation. If you accept USDT on three different chains, you don't have "USDT," you have three balances that can't pay each other without a bridge. Decide which rails you want to settle on and steer payers there at invoice time. A balance spread thin across Tron, Ethereum, and Solana is harder to deploy than the same total sitting on one rail.
Option two: auto-convert toward a stablecoin
If you bill in fiat-anchored terms — a $200 invoice that the payer settles in whatever crypto they hold — you probably don't want your treasury to inherit the price risk of whatever they happened to send. That's what auto-conversion is for: incoming assets convert toward a stablecoin target you set, so a BTC payment and a SOL payment both land in your balance as the same dollar-denominated asset.
A SaaS company that prices in USD shouldn't wake up long on ETH because that's what a customer happened to pay with on Tuesday.
The mental model: the invoice locks a rate when it activates, the customer pays, and the conversion settles the incoming asset into your chosen stablecoin shortly after the deposit confirms. You read the outcome the same way you read everything else — off the webhook stream. invoice.paid tells you the customer settled; balance.credited tells you the converted funds are sitting in your balance and ready to deploy. If you're reconciling, those two events are your source of truth, not the block explorer.
Two honest caveats. First, conversion is asset-to-asset; "stablecoin" here means USDT or USDC on a chain we support, not dollars in a bank. Second, every conversion crosses a market, so the amount that lands is the converted amount, not a guaranteed face value — the same way a rate lock protects the invoice but not your later treasury decisions. For most fiat-priced businesses this is still the correct default, because the alternative is carrying directional crypto exposure you never wanted. If you only read one supporting page, make it what balance conversion is — it spells out exactly where the asset-to-asset line sits.
Option three: rebalance treasury by hand
The third posture is for businesses that treat their balance as an actual treasury rather than a pass-through. You hold a mix on purpose, and periodically you rebalance — move some USDT into USDC to diversify stablecoin issuer risk, consolidate dust from five chains onto the two you actually pay out from, or shift a position before a large payout run so the funds are already sitting on the right rail.
This is manual conversion: you decide the pair, the amount, and the moment. It's deliberate, not reactive. The pattern we see work is a standing weekly or pre-payout review — look at where the balance is fragmented, decide where it needs to be for the next batch of obligations, and execute the conversions before the payouts go out. Doing it in that order means your mass payout run isn't blocked waiting on a conversion to clear mid-flight.
The trap here is fiddling. Manual rebalancing rewards a schedule and punishes nervous, every-price-tick activity. Each conversion is a market crossing and a network fee; a treasury that's rebalanced on a calendar beats one that's rebalanced on a feeling.
Picking, without overthinking it
Here's the decision the way we'd reason about it out loud:
Most businesses land on a blend: auto-convert the unpredictable fiat-priced inflows so the treasury stays clean, hold the assets that match their payout obligations, and rebalance by hand a couple of times a month to keep the rails consolidated. That's not a cop-out — it's what a treasury actually looks like once it's running.
Operating rule
Pick the posture from the outflow, not the inflow. The question that decides everything is "what do I pay out in, and on which rail?" — answer that, and the right settlement currency falls out of it. Collect in whatever the payer wants to send; settle toward whatever your obligations are denominated in. If those two already match, hold and don't touch it. If they don't, that gap is exactly the conversion you should be running, and nothing more.
For the treasury-first version of this conversation — staging funds before a payout run, diversifying issuer risk, keeping balances off the wrong chains — we went deeper in balance conversion for treasury teams. And if a teammate keeps asking whether any of this ends in a bank wire, the stablecoin and network fees pages settle it faster than another Slack thread will.
L. Tanaka, halfin product