The Solana network: how halfin settles SOL and SPL payments

Solana is the rail customers reach for when they want a transfer to land in seconds for a fraction of a cent. This page is about the network underneath that, not the asset on top of it: how Solana orders and confirms transactions, what the SPL token standard is and why it makes Solana payments feel slightly different from an EVM chain, why a transfer costs so little, and how halfin's Solana gate confirms an incoming payment and disburses one back out. If you already know you want to accept SOL or a Solana stablecoin, the question this page answers is what the network beneath that decision actually does.

Solana is a proof-of-stake network with a built-in clock

Solana is a single global state machine secured by proof of stake: validators stake SOL, and the protocol weights their say in consensus by how much is staked. What sets it apart from a typical proof-of-stake chain is how it orders transactions before voting on them. Solana sequences time with a verifiable delay function it calls proof of history — a continuously hashed record that stamps the order of events independently of any validator's clock. Consensus then runs over that pre-ordered stream rather than having to agree on ordering and content at the same time.

The practical reason that matters to a merchant is throughput and cadence. Solana advances in fixed time units called slots, and a leader validator is scheduled to produce a block for each slot in a known rotation. Slots are short and regular, so a customer's transfer is picked up into a block very soon after they send it — the fast, in-seconds feel that makes Solana comfortable for small, frequent payments. halfin does not treat that first inclusion as money in the bank, though: a transaction landing in a slot is an observation, not a settled payment, and the gate waits past it before crediting your balance.

Because consensus is stake-weighted and the leader schedule is known in advance, Solana's liveness and security rest on the staked validator set behaving honestly and staying online. That is a property of the network's design, not something halfin asserts or guarantees. What halfin does is apply a confirmation discipline on top of whatever the network delivers, so the amount you see as settled is an amount that has actually held.

Confirmed, finalized, and how halfin treats finality

Solana exposes a transaction's progress as commitment levels rather than a raw confirmation count. A transaction first lands in a slot; it becomes confirmed once a supermajority of stake has voted on the block that contains it; and it becomes finalized once enough subsequent blocks have been built on top that reverting it is no longer realistic. This is the same idea as confirmation depth on Bitcoin or an EVM chain, expressed in Solana's own vocabulary — the deeper a transaction is buried under voted-on blocks, the safer it is to act on.

halfin does not credit a Solana deposit the instant it appears in a slot. The Solana gate watches your addresses, recognises an incoming transfer, and waits for Solana's confirmation threshold before marking the invoice paid. Until that threshold is met the payment sits in a confirming state, surfaced to you as the invoice.confirming event, and only crosses to paid once it has held. This is the same confirm-then-credit discipline halfin applies on every chain it settles — the threshold is tuned per network, but the principle is identical across Bitcoin, the EVM chains, Tron, and Solana.

Crediting on Solana is reorg-aware. A network can briefly settle on a fork and then switch to a heavier one, dropping blocks that were tentatively seen; if that unwinds a transfer the gate had observed, halfin reflects it rather than leaving a phantom credit on the books. Waiting for the deeper, voted-on commitment is precisely what protects you here — by the time halfin marks an invoice paid, the transaction is buried far enough that a reorg taking it back is not a practical concern. A Solana payment you see as settled is one that reached the network's confirmation threshold and stayed there.

SPL is Solana's token standard — and token accounts are the twist

Solana has one native coin, SOL, and everything else is an SPL token: a mint created through Solana's token program, with its own on-chain address. SPL is the role-equivalent of ERC-20 on Ethereum or TRC-20 on Tron — the common interface a token follows so wallets and programs can transfer it and read balances uniformly. When you accept a stablecoin on Solana, you are accepting an SPL token transfer that the Solana gate watches for and confirms like any other deposit.

Where Solana differs structurally is how balances are held. A wallet does not hold an SPL token balance directly on its main account; it holds it in a separate token account owned by that wallet, one per mint — usually the associated token account derived deterministically from the wallet and the mint. This is the single most common way a hand-rolled Solana payment flow goes wrong: a receiving address has to have the right token account for the mint being sent, or the transfer has nowhere to land. halfin's Solana gate handles this token-account nuance so that accepting SPL tokens is not a special case you have to engineer around.

The same dollar-denominated stablecoins also exist on other networks — USDC as an ERC-20 on Ethereum and on Base, USDT as an ERC-20 on Ethereum and a TRC-20 on Tron. The Solana versions are independent SPL deployments of the same peg: a customer's Solana USDC cannot pay an Ethereum address, and vice versa. That is why "accept USDC" is incomplete until you name the network. The table below is the real supported surface on Solana — not an aspirational list — alongside how each settles.

Why a transfer on Solana costs so little

Solana prices transactions with a small base fee charged per signature, paid in SOL — not a single floating gas market priced by computational work the way EVM chains are. Because that base fee is tied to signatures rather than the size of a value transfer, sending a stablecoin payment costs a fraction of a cent regardless of the amount being moved. That qualitative property — a tiny, predictable per-transaction fee — is the characteristic that makes Solana a natural rail for small-ticket and high-frequency payments, where a higher-fee chain would add friction a customer resents on a few-dollar invoice.

Solana also has an optional prioritization fee: when blockspace is contended, a sender can attach a small extra fee to have their transaction ordered ahead of others competing for the same slot. It is a way to buy priority during congestion, not a charge that applies to a quiet network, and it is still measured in tiny amounts of SOL. Whatever its form, the network fee is borne by the party sending the transaction — it is a property of the rail, not a halfin charge.

For a merchant accepting on Solana, the fee model is mostly invisible: the customer's wallet attaches the SOL fee when they send you a payment, and an SPL stablecoin transfer carries a negligible cost. It becomes relevant on the payout side, where halfin is the one sending SPL transfers out to your recipients — and there the same low per-transfer cost is what keeps disbursing to many recipients viable even at volume.

How halfin accepts and pays out on Solana

Accepting on Solana does not require a Solana-specific integration on your side. You create a fiat-anchored invoice the same way you would for any asset; the customer chooses to settle in SOL or a Solana stablecoin, and halfin presents the correct Solana address and amount — including the token-account detail an SPL transfer needs. The Solana gate recognises the incoming transfer, waits for the network's confirmation threshold, and credits your balance, at which point a signed webhook tells your backend. Monetary amounts are strings end to end, never floats, and the network the payment settled on is recorded on the invoice so your reconciliation always knows it arrived over Solana rather than over Ethereum or Tron.

Solana is a payout rail as well as an acceptance rail. The same low transfer cost and fast confirmation that make it good for taking money make it good for sending it — creator earnings, affiliate commissions, gaming withdrawals, and other many-recipient operations are often paid in a Solana stablecoin precisely because recipients ask for it. halfin sends payouts over the Solana gate, so the chain you accept on is also one you can disburse on. Mass payouts fan out over the single-payout API, and each payout carries a caller-supplied idempotency_key field in the request body — so a timeout, a worker restart, or a re-run of a payout file never double-pays a recipient, which matters most on exactly this kind of high-volume rail.

The create call below commits to no network: it bills a flat fiat figure, and the customer's asset choice on checkout resolves the rail. The response and the subsequent signed webhook events carry the resolved asset and network. Verify the HMAC signature on any webhook before you act on it, and read the field schemas in the docs rather than guessing them.

curl -X POST https://api.thehalfin.com/api/v1/invoices \
  -H "X-API-Key: $HALFIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_fiat": "25.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Top-up — Solana",
    "idempotency_key": "00000000-0000-4000-8000-000000000001"
  }'

# The invoice commits to no network. If the customer settles in SOL or
# an SPL stablecoin (USDC / USDT on Solana), halfin's Solana gate
# confirms the deposit against the network's threshold and credits your
# balance; the resolved asset and network come back on the invoice and
# on each signed webhook event. Field schemas live at docs.thehalfin.com.