Balance conversion and treasury rebalancing

You accept payment in whatever your customers hold — USDT on Tron, ETH on mainnet, SOL, BTC, USDC on Base — but you usually want to hold or pay out in one or two assets. Balance conversion turns the asset that arrived into the asset you keep, automatically on receipt or manually on demand, so your treasury stays in the shape your finance team actually manages.

The problem: you collect in many assets, you want to hold in few

A crypto payment stack solves acceptance and payouts, then quietly creates a second problem: asset sprawl. A week of invoices leaves you with dust amounts of ETH, a chunk of SOL, USDT on three networks, and a little BTC. Each of those is a separate line your finance team has to price, reconcile, and eventually move. Most businesses don't want to run a trading desk to clean that up.

What they want is simpler. Settle everything into one or two reference assets — usually a stablecoin — so the balance that shows up in the books is the balance they intend to keep. The asset a customer paid with is the customer's choice; the asset you hold should be yours.

Balance conversion is the halfin primitive for that. It converts held balances between supported assets, either automatically as payments land or manually when you decide, and it does it inside the platform so you never have to bridge funds out to an exchange, swap them, and bring them back.

Automatic conversion: settle in the asset you chose

Automatic conversion runs at the point a payment is credited. You pick a target settlement asset, and when an invoice is paid in something else, the incoming balance is converted toward that target as part of the credit flow. The merchant balance that results is denominated the way you want it, not the way the customer happened to pay.

This is the path most teams turn on first, because it removes the daily cleanup entirely. A customer pays an invoice in native SOL against a USDC settlement target; what lands in your balance is USDC. There is no manual step, no end-of-day batch to remember, and no window where the asset sits un-managed waiting for someone to act on it.

Automatic conversion only fires when a supported conversion 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, and you can convert it manually later. That fail-open behavior matters: the system never blocks a legitimate payment because a conversion couldn't run.

• Set a target settlement asset once; incoming payments are converted toward it on credit.
• Removes end-of-day asset cleanup — the held balance is already in your reference asset.
• If no conversion route applies, the original asset is credited untouched and stays available for a manual conversion.

Manual conversion: convert on your terms

Manual conversion is the deliberate counterpart. Instead of converting every payment as it arrives, you hold balances as received and convert when it suits the business — to consolidate accumulated assets, to fund an upcoming payout run in the right currency, or to act on a treasury decision your team made off-platform.

A manual conversion is an explicit operation: you choose the source asset, the target asset, and the amount, and the platform records the result against your balance with full history. That makes it auditable in the same way every other money movement in halfin is — the conversion is a recorded event, not an opaque adjustment that appears in your books without provenance.

Teams commonly use both modes together. Automatic conversion keeps the bulk of revenue settling into a stablecoin with no effort, while manual conversion handles the periodic, judgment-based moves — rebalancing across networks before a large batch payout, or consolidating leftover assets at month-end.

Treasury rebalancing across assets and networks

Holding one logical asset still means holding it in specific places. USDT exists as TRC-20, ERC-20, and Solana SPL; USDC exists as ERC-20, Solana SPL, and on Base. Where your stablecoin sits decides what it costs to pay someone with it — a Tron payout and an Ethereum payout draw from different balances and carry very different network fees.

Rebalancing is the act of moving value between assets and the networks they live on so the right liquidity is in the right place before you need it. If a payout run will go out over TRC-20 but most of your stablecoin accumulated as ERC-20, you want that addressed before the run, not discovered mid-batch. Balance conversion is the tool that shifts held value toward the asset and network your upcoming obligations require.

The point is operational predictability. Conversion lets a finance team keep treasury in a deliberate shape — a known settlement asset, positioned on the networks the business actually pays and receives on — rather than reacting to whatever mix the last week of customer payments produced.

Where conversion sits in the payment lifecycle

Conversion is not a standalone product you bolt on; it sits between acceptance and payout as the layer that normalizes what you hold. Money arrives through invoicing, hosted or self-hosted checkout, or a static deposit address. It leaves through single, mass, or M2M payouts, and through refunds. Conversion is what keeps the balance in between in a usable shape for both directions.

The table below shows where each conversion mode applies across that lifecycle. Read it as a routing guide: most steady-state revenue belongs on automatic conversion, while periodic, intentional moves belong on manual conversion.

Conversion and the rest of your integration

Conversion is observable the same way the rest of halfin is. Balances are read through the REST API at api.thehalfin.com/api/v1, the same place you read invoice and payout state, so your accounting system can reconcile held assets without a separate integration. The snippet below reads current balances; treat conversion results as changes to those balances rather than as a parallel ledger you have to stitch together.

Because conversion records are part of your balance history, they reconcile cleanly against the events you already consume. Webhooks notify you of payment and payout activity; balances reflect the converted result of that activity. Keep the API balance as the source of truth for what you hold, and let conversion be the thing that keeps that number denominated the way your team manages money.

# Read current merchant balances after conversions have settled
curl https://api.thehalfin.com/api/v1/balances \
  -H "X-API-Key: $HALFIN_API_KEY"

# Each entry reports the asset, network, and amount you currently hold.
# Amounts are JSON strings — never parse them as floating-point numbers.

What conversion does not do

Balance conversion moves value between crypto assets you already hold on the platform. It is not a fiat on-ramp or off-ramp: halfin does not sell crypto to your customers and does not turn your held crypto into bank-settled fiat. Settling "in USD" here means settling into a USD-denominated stablecoin, not into a fiat bank balance.

Conversion also depends on a supported route existing between the two assets. Routes cover the assets and networks halfin supports for settlement; where a direct route isn't available, the source asset stays held and you decide what to do with it. The platform's job is to make the supported moves clean and recorded, not to promise a path between every possible pair.

Finally, conversion is a treasury operation, not a custody guarantee. halfin's controls here are the same ones that apply everywhere on the platform — scoped API keys, operator permissions, and a full audit trail of every recorded move — and nothing beyond that should be read into it.