Stablecoin settlement is the point at which a stablecoin payment can no longer be reversed by the network and the business receiving it can treat the funds as its own, in the token and on the chain where it operates. For a business that accepts deposits on many chains, that point is reached in three steps: the deposit has to be final on the chain it was sent on, or guaranteed by someone who carries the risk until it is, it has to be attributed to the right customer, and it has to arrive in one balance, which usually means moving value across chains and between versions of the same token.
What follows takes those steps in order, then adds token versions, reconciliation and compliance, and ends with the failure modes and a checklist of questions to ask any provider before signing. Rhino.fi sells a stablecoin payments API, so its own model gets one section, and that checklist applies to Rhino.fi as much as to anyone else.
Quick Answer
Stablecoin settlement is complete when a payment is final on its chain, credited to the right customer and usable in the business's own token and chain. Hard finality takes about a minute on Tron and about 13 to 19 minutes on Ethereum and 20 on Base. Providers that credit sooner front the funds before finality, up to set limits.
What does "settled" mean on a blockchain? A transaction visible in a block explorer has been included in a block, which is not the same as final: a transaction is “settled” when a reorganisation of the blockchain can no longer remove it.
A reorganisation happens when the network replaces its most recent blocks with a different version, causing transactions that were only in the replaced blocks to disappear.
Because the risk of this happening depends on the chain's consensus design, the word "settled" means something different on each network.
Bitcoin, for example, never reaches a single final point. Its developer guide recommends six confirmations (eaning six additional blocks built on top of the one containing the transaction) before treating a high-value payment as safe to accept. This typically takes about an hour.
Ethereum, on the other hand, finalises at checkpoints , about 13 to 19 minutes after a block is proposed. Reversing a finalised block would require validators holding at least a third of all staked ETH to break the protocol's rules, and they would lose that stake, so in practice a finalised block is permanent.
Other chains, such as rollups (built on top of Ethereum) or non-EVM chains, have different definitions and times.
The table below shows the definition of "finality" according to the documentation of the most popular chains, as well as their typical time required to reach it.
Chain
What the chain's documentation treats as final
Typical time to that point, per the documentation
Bitcoin
No single final point; six confirmations recommended for high-value payments
About an hour for six confirmations
Ethereum
Block in a finalized checkpoint, backed by at least two-thirds of staked ETH
About 13 to 19 minutes after proposal
OP Mainnet
Batch data in a finalized Ethereum block
About 15 to 30 minutes; "safe" in a few minutes
Base
L1 batch finality
About 20 minutes; batch on Ethereum in about 2 minutes
Tron
Solidified: at least 19 of 27 Super Representatives have built at or above the block
About 1 minute
Solana
Confirmed or finalized under Alpenglow (equivalent)
Design target of about 150 ms, per the Solana Foundation
Crediting before finality moves the risk to someone The risk of crediting early is that a reorganisation can remove the deposit after the customer has already spent the funds.
So, waiting for hard finality before crediting a deposit is the safe option, but on Ethereum or Base it means keeping the customer waiting for a quarter of an hour or so. The other option is to credit earlier, but the business that does so has to decide who covers the loss if a reorganisation removes the deposit.
Circle's Cross-Chain Transfer Protocol (CCTP) shows the trade-off in its own parameters . A Standard Transfer is attested after hard finality: about 65 Ethereum blocks (15 to 19 minutes) from Ethereum or Base, 32 blocks (about 17 seconds) from Solana. A Fast Transfer is attested once the transaction is in a block: 2 confirmations (about 20 seconds) from Ethereum, 1 (about 8 seconds) from Base.
Fast Transfers draw on a global allowance that "limits the total value of USDC that can be minted through Fast Transfer before related burns reach hard finality". When it runs out, Fast Transfer pauses until earlier burns finalise.
So any provider that credits before finality is taking on the risk that a deposit disappears in the meantime. What matters is how much of that risk it accepts, per transaction and per chain, and who pays if it happens.
How do deposit addresses, attribution and sweeping work? Before a deposit can count as settled, the business has to know who sent it and move the money into an account it can use. Two pieces of infrastructure do that: deposit addresses and sweeping. A deposit address tells the business who paid, while sweeping moves the money from that address into a treasury. Across several chains, each with its own address format and fee currency, both need dedicated engineering and operations work.
Why each customer gets an address A stablecoin transfer carries only a recipient and an amount: the token standard has no field for a payment reference. If every customer pays into one shared address, the business sees deposits from senders it may not recognise, often an exchange's wallet rather than the customer's own. So each customer, or each invoice, gets its own deposit address, and the address a payment lands on tells the business who paid.
Why sweeping deposits takes real work Every move is a transaction, and every transaction pays a network fee in the chain’s own currency: ETH on Ethereum, SOL on Solana , TRX on Tron , etc. An address that holds only stablecoins has nothing to pay that fee with, so someone first has to send it a small amount of the chain’s currency, address by address. Across thousands of addresses and several chains, that becomes a job of its own. Bitcoin is simpler here: a BTC deposit pays for its own sweep out of the BTC it holds.
On Ethereum, a recent upgrade, EIP-7702 , makes this easier than how it used to be: it lets another account pay the fee on the address's behalf, so the deposit address no longer needs its own ETH. Rhino.fi uses it to sweep deposits on Ethereum-compatible chains and pays the fees itself.
Tokens also behave in slightly different ways, and code written for one can fail on another. Tether's integration notes , for example, warn that USDT on Ethereum does not confirm a successful transfer the way most tokens do, which can break sweeping code that expects that confirmation.
Between the deposit and the sweep, someone holds the key to each address, so sweeping also raises a custody question.
Wrong chain, wrong token Because the same address can receive money on many chains, it is also where most mistakes happen. EVM chains share an address format, so a customer can use the right address on the wrong network. If the business only watches the chains it advertises, that deposit goes unnoticed, and recovering it takes a manual transfer from the same address on the same chain. The safer setup is to monitor every EVM chain where the address is valid, including the ones the business does not advertise.
On the other hand, non-EVM chains such as Solana and Tron use a different address format, so each needs its own address. Tokens the business does not accept are harder to catch. Most monitoring covers only a selection of unsupported tokens on each chain, so some will arrive without any alert. Rhino.fi , for example, sends a rejection event for the unsupported tokens it monitors , but does not monitor all of them.
How does value move in cross-chain stablecoin settlement? A final deposit usually still has to reach the chain where the business's ledger or card programme lives. There are three ways to get it there, with risk in different places. The table adds the canonical rollup bridge, because its withdrawal window is often mistaken for finality.
Lock-and-mint. The original token is locked in a contract on its home chain and a representation is minted on the destination. USDT0 works this way: USDT is locked in a contract on Ethereum, and USDT0 is minted 1:1 on the destination chain once independent verifiers have confirmed the transfer. Between two USDT0 chains, tokens are burned and minted without touching Ethereum. The USDT on Ethereum stays locked as backing the whole time, and it is released only when USDT0 is burned to move funds back to Ethereum.
Issuer burn-and-mint. The issuer burns tokens on the source chain and mints its own token on the destination. Circle's CCTP works this way for USDC, with no bridge liquidity pool involved. The recipient ends up with USDC issued by Circle itself, with no bridged or wrapped version in between.
Liquidity or intent. Nothing crosses chains at the moment of payment. A solver that already holds funds on the destination pays the recipient from that inventory and rebalances later. Rhino.fi describes the model this way: "A solver fronts destination funds, then claims reimbursement via settlement/backstops." The risk sits on the solver's balance sheet. In a custodial design, the business also depends on the provider to pay out.
Settlement model
What moves at payment time
What the recipient ends up holding
What sets the time
Where the risk sits
Lock-and-mint
Collateral is locked on the home chain; a representation is minted on the destination
A token backed by the locked collateral (for example USDT0)
Cross-chain message verification
The lock contract and the message verifiers
Issuer burn-and-mint (CCTP )
Tokens are burned on the source; the issuer mints on the destination
The issuer's native token (USDC, EURC)
The issuer's finality threshold before attestation; faster paths are capped by an allowance
The issuer's attestation service; reorganisation exposure on fast paths is capped by the issuer
Liquidity or intent
Nothing crosses; a solver pays out of its own inventory on the destination
Whatever token the solver holds on the destination
Source-chain confirmation plus the solver's release policy
The solver's liquidity, confirmation policy and rebalancing; in custodial designs, counterparty risk on the provider
Canonical rollup bridge (withdrawal to L1)
A withdrawal claim is proved on the parent chain
The canonical token on the parent chain
The window: seven days on the OP Stack Standard Bridge ; Base documents five days, or one on its dual-proof path
The rollup's proof system
These models are not exclusive. A liquidity provider can pay the customer in seconds and rebalance its own inventory over CCTP or USDT0 afterwards.
Why is the same ticker not the same asset? A ticker names a brand, not a contract. Two balances labelled USDT can have different issuers and different bridges behind them, so a settlement flow has to work at the level of the contract address.
USDT Tether’s supported-protocols page lists Ethereum (ERC-20), Tron (TRC-20), Solana and TON among the networks where it issues USDT itself; Arbitrum, Optimism and Polygon do not appear: on those networks, the “USDT” in a wallet is a different token, so a bridged version, or USDT0.
Rhino.fi's supported-chains table shows USDT "Represented as USDT0" on Arbitrum One, Polygon, HyperEVM and Mantle, and "Represented as USDT.e" on Base, Avalanche, Linea and Optimism. On Avalanche, Tether also issues native USDT, so USDT.e there is an older bridged version.
USDT on Tron and USDT on Ethereum are both issued by Tether, but they are separate token contracts on separate ledgers. A balance on one is not spendable on the other without a bridge, a swap or a provider that holds inventory on both.
USDC Circle is plain about the difference . Native USDC is issued by Circle itself and moves between chains through CCTP. Bridged USDC is created by a third party, backed by USDC locked in a smart contract on another chain, and cannot be moved through CCTP. Rhino.fi’s bridge table , for example, lists USDC.e on Katana and Mantle and USDC.b on BNB Smart Chain, which are bridged versions, not Circle’s native USDC.
A treasury that books "USDC" without the contract cannot say what it can move by CCTP, and a flow that accepts any token named USDC carries the risk of whichever bridge minted it.
Converting between USDT and USDC Both are pegged to the dollar and still trade at a market rate against each other . Rhino.fi's documentation says that without its 1:1 Stablecoin Settlement extension , a cross-stable swap "is routed through a market" and the settled amount depends on the USDT/USDC price at execution. With the extension, Rhino.fi credits the destination from its own reserves at 1:1 while the market rate stays within 3 basis points of 1:1, or within a wider guardrail of up to 20 basis points that the business can set. Volume limits apply, and settlement falls back to the market rate beyond them.
In practice, this means keeping a per-chain allowlist of token contracts, refreshing it from the provider's configuration, and recording the contract address (not only the symbol) on every deposit.
What should a business record for every deposit? Once deposits are credited, the ledger has to be able to explain each one: indeed, each deposit record should include the source chain, transaction hash, token contract address, amount in the token's own units, sending address and receiving address. Furthermore, the internal customer or invoice reference, the confirmation status at which it was credited, any conversion rate and fee, and the payout transaction hash, should be added, too. With those fields, a ledger can be rebuilt from the chains alone.
Rhino.fi , for example, notifies the business when a deposit is accepted, when it settles on the destination chain and when it is rejected, with the reason (such as an amount below the minimum). Each address also carries a short free-text note, returned with every status update , where the business keeps its own customer or invoice reference.
Fees are the other gap: deducted in flight, the invoice says 100 and the account receives less. This implies that the fee should be recorded directly from the quote and before the deposit is sent, so the ledger can explain the gap between the invoice and what arrives.
What compliance checks apply at the point of settlement? For a regulated business, a deposit is not settled until the required originator information has arrived and been checked, and the funds have cleared sanctions screening.
The Travel Rule FATF 's Recommendation 16 requires originating virtual asset service providers to "obtain and hold required and accurate originator information and required beneficiary information on virtual asset transfers". They must pass it on "immediately and securely", which FATF's 2021 guidance defines as before, simultaneously with or concurrently with the transfer. Countries may set a USD/EUR 1,000 threshold; below it, names and a wallet address or transaction reference are still collected.
The EU went further. Regulation (EU) 2023/1113 , applicable from 30 December 2024, requires the originator's provider to send the originator's name, ledger address, address and identification number (or date and place of birth). The beneficiary's name and ledger address go too, with no threshold between providers. The beneficiary's provider must detect missing information and either reject or return the transfer or request the information "before making the crypto-assets available to the beneficiary". Above EUR 1,000 from a self-hosted address, it must assess whether its customer owns or controls that address.
In the US, the Funds Travel Rule (31 CFR 1010.410(f) ) applies to transmittals of $3,000 or more. FinCEN's 2019 guidance says the equivalent in convertible virtual currency may trigger it.
Sanctions screening OFAC states that its obligations "apply equally to transactions involving virtual currencies and those involving traditional fiat currencies" and that civil penalties generally follow strict liability. It has listed virtual currency addresses on the SDN List since 2018. FATF asks both sides of a transfer to screen the other party's name.
The token itself can also be stopped. The US GENIUS Act was enacted on 18 July 2025 and takes effect by 18 January 2027 at the latest. It requires a permitted payment stablecoin issuer to have "technical capabilities, policies, and procedures to block, freeze, and reject specific or impermissible transactions". It allows such an issuer to issue only if it can comply with lawful orders, defined as orders to "seize, freeze, burn, or prevent the transfer of payment stablecoins". USDT0's documentation lists an onchain blocklist under which blocked addresses cannot send tokens. A final deposit can still be frozen at the address that received it, so screening belongs before crediting and commingling.
How Rhino.fi 's model fits Rhino.fi describes its product as the Activation Stack with three steps : deposit, settlement and activation. A customer sends stablecoins to a Smart Deposit Address from any supported chain, exchange or wallet. Rhino.fi detects the deposit, screens it and credits the destination chain through its liquidity layer. Optionally, a predefined onchain action (such as a vault deposit) runs on arrival. In the terms above, Rhino.fi places itself in the liquidity model, and says it runs "our own solver".
Settlement from its own liquidity Rhino.fi holds its own pools on every supported chain, and a blog post explains that funds settle from the pool on the destination chain, "with no bridging, swapping or aggregation in the user's path". Rhino.fi fronts and rebalances these reserves across 30+ chains, so every transaction settles from Rhino-owned liquidity , according to the Bridge and Convert page . An aggregator, by contrast, routes the payment through other providers' bridges and DEXs. Rebalancing between chains does use third-party routes such as CCTP and LayerZero, outside the payment path. Rhino.fi has settled more than $15 billion across more than 30 chains.
Crediting before finality, within limits Rhino.fi controls the keys to each Smart Deposit Address and sweeps the funds into its own pools after the payout. The payout doesn't wait for funds to travel across chains, but it does wait for the deposit to be confirmed on the origin chain. Within that, the payout can come early:
Funds can be released after as little as one block, before the origin chain reaches finality, up to configurable limits per transaction and per chain.
Above those limits, the payout waits for the number of confirmations Rhino.fi requires on that chain.
On Ethereum, early payouts cover deposits of up to $50,000 each, and no more than $250,000 in total that has not yet reached finality.
If a reorganisation later reverses a deposit that was already paid out, Rhino.fi 's terms require the client to return the funds.
Deposit addresses and quotes Each end customer gets one reusable SDA , and every payment starts from a quote:
By default, the API returns the same address when it is asked again for the same customer.
A short free-text note on the address carries the business's own customer ID.
Rhino.fi monitors each address for seven years by default, and the period can be extended.
Rhino.fi honours the quoted fee until the quote expires, and a separate mode lets the business fix the amount that must arrive.
Bitcoin is the exception : the deposit is quoted once Rhino.fi has received the BTC, so the settled amount depends on the price at that moment.
Fees As stated in the fees page , Rhino.fi covers the onchain costs of moving funds from SDAs and of settlement, except on Tron, Solana and Bitcoin, where a fixed per-transaction cost applies:
$1.40 per Tron SDA deposit.
$1 per Bitcoin SDA deposit.
$0.50 when Solana is the destination.
The business chooses whether it pays that cost or passes it to the end customer.
Compliance and screening Every deposit is screened before it is credited, and the documentation says that any deposit failing compliance checks is blocked.
Clients can add their own rules through providers such as Chainalysis or Elliptic.
Rhino.fi screens every inbound and outbound transaction for KYT and AML, while KYC on the business's own end users stays with the business.
Rhino.fi doesn't yet exchange Travel Rule data on its clients' behalf: an integration is on the roadmap , so for now the business remains responsible for the Travel Rule on its own flows.
What the route data shows Rhino.fi 's published data shows that the origin chain sets most of the timing, and that one speed figure cannot describe a multi-chain flow. Between 1 July and 30 September 2026, Rhino.fi completed 376,488 fast-mode payments to Base from six origin chains:
Origin chain
Payments
Median
90th percentile
99th percentile
BNB Chain
296,185
1 s
2 s
13 s
Polygon PoS
8,244
2 s
3 s
24 s
Arbitrum
6,721
2 s
8 s
35 s
Tron
19,282
2 s
29 s
65 s
Solana
21,731
3 s
26 s
31 s
Ethereum
24,325
48 s
53 s
71 s
Source: Rhino.fi internal data, as published. Time runs from the moment Rhino.fi registers the deposit to the moment the payout is committed on Base. Executed payments only, origin chains with at least 1,000 payments, percentiles approximated.
Two things stand out in these figures:
Speed depends on the origin chain, and on five of the six routes the median payment settled in 3 seconds or less. On every route, 99 in 100 payments completed within 71 seconds.
Ethereum is the slowest route and also the most consistent: 48 seconds at the median and 53 at the 90th percentile. Tron and Solana have medians of 2 and 3 seconds, with 90th percentiles of 29 and 26 seconds.
The clock starts when Rhino.fi registers the deposit and stops when the payout is committed on Base. The figures are historical: the Solana row predates Alpenglow, and network conditions, confirmation policies and risk limits can change the results. Publishing timing by route and percentile is what lets a business judge settlement speed for the chains it actually uses.
So, settlement time on Rhino.fi depends on the route and the size of the transaction. Most routes settle in seconds, and Ethereum, with a median of 48 seconds, is the slowest. Every quote also includes an estimated duration for the transfer, which our docs call “an estimate, not a guarantee”. A more useful measure is time to usable balance : how long it takes until the business can actually use the funds.
One deposit through Rhino.fi , from start to finish With Rhino.fi , take a payment where the customer holds USDT on Tron while the merchant settles in USDC on Base. The merchant creates a Tron deposit address for that customer, chooses USDC on Base as the destination, and tags the address with the customer's ID.
The customer sends USDT. Tron solidifies the block in about a minute, but the payout need not wait for that if the deposit is within Rhino.fi 's limits. In the Q3 data, Tron to Base took a median of 2 seconds, and 99 in 100 payments finished within 65 seconds.
USDT arrives as USDC, at the market rate or, with the 1:1 extension , at 1:1 inside its guardrail and limits. Rhino.fi notifies the merchant and returns the payout transaction ID for its ledger. Rhino.fi sweeps the Tron address later, and the customer never sees that step.
One Rhino.fi client, a crypto card and neobank, accepted SDA deposits from 18 origin chains in Q3 2026, including Tron, Solana and Bitcoin, and settled them to two destination chains. It received 54,569 deposits worth $38.5 million. The median time from registered deposit to payout was 3 seconds, and 90% of deposits settled within 6 seconds.
What goes wrong in stablecoin settlement? Most settlement problems come from the less common cases, such as a deposit on the wrong chain, a refund or a frozen token. They apply whether a business runs its own deposit infrastructure or works with a provider such as Rhino.fi , and each one needs an owner before the first live deposit.
Crediting a deposit that later disappears If a deposit is credited on an unsafe Layer 2 block or after one Ethereum confirmation, a reorganisation can remove it after the customer has already spent the funds. The loss falls on whoever credited the deposit early, unless a contract moves it elsewhere, which is why the confirmation level for crediting is set chain by chain.
Deposits that cannot be credited Deposits on the wrong network or in a token the business does not accept, described earlier, are returned by hand, so they need an agreed process before the first live deposit. On Rhino.fi , deposits on any listed EVM chain are detected and settled automatically, and rejected deposits are held so the team can return them.
Every provider, and every in-house system, also has a minimum and a maximum deposit. On Rhino.fi , for example, two $3 deposits to an address with a $5 minimum are each rejected , and Rhino.fi 's team then refunds them manually. Showing the minimum before the customer sends prevents most of these.
The refund itself can go wrong. A deposit sent from an exchange arrives from a pooled hot wallet the customer does not control, so Rhino.fi’s documentation recommends, in most cases, not setting a refund address: a refund to the sending address “may never reach them”.
Funds sent to a paused address Pausing an address is a normal way to offboard a customer, but customers do not always stop using it. Rhino.fi's documentation warns that "A paused address is not monitored, so any funds sent to it get stuck and are not processed".
The fast path runs out Faster-than-finality paths are capped, whether by CCTP's allowance, a provider's per-chain limits or a 1:1 conversion's volume limits. When a cap is reached, payments fall back to the slower path, often without the customer being told.
Sanctioned or frozen funds at your address Screening after the sweep means a tainted deposit is already mixed with clean ones, and separating it again is difficult.
Questions to settle before you sign with a stablecoin infra provider Most comparisons of stablecoin settlement infrastructure stop at a headline speed, but speed is only one part of the picture. These questions cover the rest, and they apply to any provider, Rhino.fi included:
On each source chain, at what confirmation status is a deposit credited, and who carries the loss if it is reorganised away?
What are the per-transaction and per-chain limits for crediting before finality, and what happens above them?
Who controls the keys to each deposit address, and who holds the funds between deposit and sweep?
Which token contracts are accepted on each chain, which are native and which bridged, and how is the list kept current?
If a deposit is converted into a different stablecoin (for example, USDT to USDC), at what rate is it settled, and who bears the difference if the market rate moves?
How are wrong-chain deposits, unsupported tokens and below-minimum deposits detected and returned, and at whose cost?
Can the business reconcile every deposit in its own books using only the provider’s status updates and public blockchain data?
Is the fee quoted before the deposit and honoured until a stated expiry, or deducted from the settled amount?
Who is the obliged entity for Travel Rule data on each flow, and is screening done before crediting?
What timing do you publish by route and percentile, where does the clock start, and does it include detection?
”The point of a Smart Deposit Address is that the customer doesn’t have to think about the chain. They send from whichever chain, exchange or wallet they use, and the business gets one status update and one balance. Monitoring, screening and sweeping happen on our side, so the team can spend its time on the product instead,” says Jan Zibelnik, Product Manager at Rhino.fi .”
If your customers deposit from more than one chain, talk to the team about how settlement would work for your flows: which chains, which tokens, and who carries the risk at each step. Rhino.fi replies within one working day, and the first call is 15 minutes.
Sources Chain documentation: Bitcoin developer guide: payment processing , Ethereum: blocks , OP Stack transaction finality , Base: transaction finality , Tron consensus documentation , Solana Foundation: Alpenglow .
Issuers and token networks: Circle: CCTP block confirmations , Circle: bridged USDC standard , Tether: supported protocols and integration notes , USDT0 documentation .
Regulation: FATF 2021 updated guidance on virtual assets , Regulation (EU) 2023/1113 , FinCEN 2019 guidance on convertible virtual currency , OFAC sanctions compliance guidance for the virtual currency industry , GENIUS Act .
Rhino.fi : Fees and limits , Smart Deposit Addresses , What is deterministic settlement in crypto? , Time to usable balance , Rhino.fi internal transaction data, 1 July to 30 September 2026.
