Rhino stablecoins can cross supported chains and convert into supported tokens

Updated - 08 Oct 2026

Rhino stablecoins can remain in the same asset across supported chains or convert into a different supported token through Rhino’s enterprise application programming interface (API). Bridging changes the blockchain holding the balance; swapping changes the token the recipient receives. Bridge & Swap can combine those operations in an integrated flow. A stablecoin’s price target doesn’t make every conversion equal in token quantity. Standard conversion, optional 1:1 settlement, and applicable charges determine the output. The input asset, destination asset, and route must all be supported. Rhino provides these capabilities to enterprise clients, whose account configuration determines access to optional features.

The short version: A supported stablecoin route must match the required destination asset, while fixed 1:1 conversion also depends on account limits and market guardrails.

Moving a stablecoin and changing the settlement token

A bridge-only route keeps the selected token while moving its balance between blockchains, so that token must be supported at both ends of the route. The destination balance belongs to a different network. Its token address and the applications able to accept it follow that network’s configuration. Keeping the asset doesn’t establish that the sending and receiving quantities will match after charges.

Bridge-and-swap changes the output asset as part of the cross-chain transfer. The input token needs source-chain support, and the requested output needs destination-chain support. Those conditions allow different receiving assets without requiring the original token at the destination. Without the fixed-rate extension, cross-stable conversion uses market pricing. A same-chain swap changes tokens while keeping the network unchanged.

Token compatibility includes the receiving network

Source acceptance

Rhino’s configurations identify supported tokens by network, with token addresses and decimal precision available in token-specific records. A ticker alone doesn’t establish compatibility. The token sent must match the supported asset on the selected source chain. Token-specific records also expose applicable deposit and withdrawal limits. Bridge & Swap also has a swap-token configuration, so an integration needs the relevant conversion support alongside the bridge configuration.

Destination availability

Incoming and outgoing support can differ, and Smart Deposit Addresses have their own supported-token information. Acceptance on a deposit chain doesn’t establish payout support for every destination. Some assets require activation on request. Others have support on a single chain and can enter a bridge-and-swap flow even though a same-asset bridge isn’t available. The receiving asset must also fit the destination application, if the transfer will fund one.

View image file

Quote modes fix either the sending or receiving amount

The pay mode treats the requested amount as the input-token quantity and calculates the destination output, including the applicable conversion and fee treatment. The receive mode treats it as the desired output-token quantity and calculates the required source amount. These modes express different payment requirements without establishing a universal conversion rate between the two tokens.

The returned payAmount and receiveAmount are human-readable token amounts, not smallest-unit integers. Their corresponding USD fields describe valuations, which aren’t interchangeable with token quantities. Token decimals matter when preparing the blockchain transaction. Separately, expiresAt gives the deadline for committing the quote. An expired quote needs replacement before commitment; the expiry field doesn’t report whether a funded transfer has completed.

A quoted cross-chain conversion from request to receipt

For a cross-chain payment that needs a different stablecoin, the application checks token and route support and obtains a quote before the sender deposits. The quote must specify the recipient’s required token and network. If conversion support is absent, select a supported alternative before funding. A same-asset bridge delivers the original token, so it’s a payment alternative only if the recipient can accept that asset.

Quoted conversion stage	Asset support and completion condition
Authenticate API access	Use the account’s authorized access for the requested operation.
Retrieve bridge configuration	Identify the selected networks and supported bridge assets.
Retrieve swap-token configuration	Confirm conversion support for the selected input and output.
Request the transfer quote	Specify the tokens and chains, the amount and mode, and the sender and recipient.
Commit the quote	Register the selected quote before its commitment deadline.
Submit the source transaction	Complete any required token approval before the matching bridge-contract transaction.
Confirm destination settlement	Use the completion record and destination transaction to confirm the requested asset and recipient.

The committed quoteId connects the request to its status record. For this quoted bridge flow, EXECUTED indicates destination credit. Check the destination transaction for the receiving token and amount. A source deposit alone doesn’t confirm receipt. A different output token won’t complete a payment that requires the specified asset.

Same-chain swaps require the matching transaction format

An atomic same-chain quote has matching source and destination chains and isAtomicSwap: true. Rhino’s atomic same-chain swaps are limited to Ethereum Virtual Machine (EVM) chains.

Token approval target

For an ERC-20 same-chain swap, the approval target is the configured sameChainSwapsAddress. The regular bridge deposit contract is a different target. An allowance granted to that deposit contract doesn’t authorize the swap contract to spend the token. The integration must match the approval to the action it will submit.

Prepared swap transaction

The swap calldata response supplies the transaction for the committed swap. The depositor submits that transaction instead of constructing a regular bridge deposit. Sending the usual deposit transaction for an atomic same-chain commitment causes rejection by the deposit watcher.

Smart Deposit Addresses can select a settlement stablecoin

A Smart Deposit Address can specify tokenOut to direct supported deposits toward a chosen destination asset, with conversion when the incoming token differs from that asset. Its returned supported-token list defines the accepted deposits for the configured route. The destination token must be bridgeable on the receiving chain. Fixed 1:1 pricing remains an account feature with additional conditions.

View image file

When a Smart Deposit Address has tokenOut and has bridgeIfNotSwappable set to true, a deposited token that can’t be converted to the requested output can be bridged unchanged, provided the original asset has a supported destination route. A false value makes that unavailable conversion fail. Bridging the original asset doesn’t produce the requested replacement token. This fallback suits a receiving arrangement able to accept the original asset.

Fixed 1:1 settlement has pricing and volume boundaries

Equal token quantities

The enabled 1:1 Stablecoin Settlement extension converts USDT and USDC at equal token quantities before applicable fees, within its guardrails and limits. Both conversion directions require supported chains where the participating stablecoins are available. Rhino credits the destination from its own reserves and rebalances those positions outside the settlement path. Applicable fees remain separate from the conversion ratio, so net receipt can differ from the deposited quantity.

Market-deviation guardrails

The platform’s guardrail limits the market-price divergence within which it offers 1:1 conversion. Advanced Fee and Limit Management can add a client guardrail to continue that treatment within the client’s configured range. Beyond the applicable guardrails, conversion returns to market pricing.

Account and recipient volume

Account limits govern aggregate 1:1 volume over the configured period. Recipient limits govern volume for a particular recipient. Reaching either limit returns the affected swaps to market pricing. A recipient’s limit affects only their transactions; an account limit governs aggregate eligible volume. Separate transaction-size limits determine whether a deposit or bridge-and-swap amount can be processed at all.

Applicable charges change the net stablecoin receipt

A 1:1 conversion ratio describes exchanged token quantities before applicable charges, while the commercial configuration determines which costs reduce the recipient’s stablecoin balance and which the client absorbs. Subscription arrangements cover most onchain costs, with some chain-specific charges agreed separately. A Client Surcharge can also pass a business’s charge to the customer. Fee customization changes cost allocation, not token compatibility.

Trial accounts apply per-transaction fees and deduct applicable costs from the destination amount. Legacy pricing can also deduct costs from settlement. Subscription quotes still expose fee information even where Rhino bears the underlying cost. Reading every displayed fee as an additional customer deduction would therefore misstate the receiving amount.

Transfer states distinguish funding from destination credit

For a quoted bridge, PENDING means the quote is committed and Rhino awaits the source deposit. ACCEPTED means the deposit has been detected and destination execution is underway. EXECUTED means the bridge has completed and the destination has been credited. Some routes include a confirmation-waiting state, and swap flows can include a source pre-swap state. Neither extra state is a required stage of every transfer.

A swap failure and a completed refund also have distinct states. SWAP_FAILED indicates a failed conversion under refund review; SWAP_FAILED_REFUNDED indicates a successful refund. Smart Deposit Address activity uses its address-specific status and history interfaces. Matching the status interface to the transfer type avoids interpreting an unrelated record as settlement evidence.

Stablecoin value and deposit screening concern different risks

A stablecoin aims to track its reference currency, but its market value can move away from that target. Reserve quality and redemption liquidity affect asset-backed stablecoins. Successful bridging records the movement of an asset; it doesn’t establish the asset’s future purchasing power or the issuer’s ability to redeem it.

Rhino can restrict or suspend access to fixed-rate swaps during depegging, liquidity constraints, or exceptional market disruption. A payment that relies on conversion at par remains subject to those restrictions even when the extension is enabled.

Baseline transaction screening checks deposits before destination credit and blocks deposits failing compliance checks. Know Your Transaction (KYT) and anti-money laundering (AML) screening address the incoming transfer. They don’t certify the stablecoin’s reserves or price stability. Enhanced Compliance and Risk Management adds configurable screening controls for accounts needing them.

Secret API keys allow transaction-history access and belong in server-side code. Browser integrations use public keys, which can’t retrieve the application’s full bridge history.

The destination’s use determines the settlement asset

The useful choice starts with the asset the destination can accept and whether that asset already exists on the sending chain in a supported form. A same-asset bridge addresses network placement. Conversion addresses a different receiving token. If both need to change, Bridge & Swap handles their combined scope. Choosing a familiar stablecoin without destination compatibility can leave the intended payment unresolved.

Automated Onchain Actions can apply settled stablecoins to a configured destination contract when the account has the extension enabled. The action accepts ERC-20 type tokens on EVM destinations, with one configured action per bridge, so both the chosen asset and receiving chain must also meet those conditions when settlement needs to include an application deposit. A plain bridge preserves the selected asset across networks; a conversion becomes useful when the receiving balance must hold a different supported token.

Diagram: The destination’s use determines the settlement asset (Rhino stablecoins)

View image file

Still have questions?

Does a trial account include fixed 1:1 stablecoin conversion?

Trial accounts don’t include the 1:1 Stablecoin Swaps extension. They provide testing access to supported deposit and bridge functions, with fees and limits configured for testing. A subscription can provide optional extensions under the agreed plan, so trial access doesn’t establish production eligibility for fixed-rate conversion.

How should an application read a stablecoin quote’s timing estimate?

The estimatedDuration field expresses an estimated completion time in milliseconds. It isn’t a completed-transfer record or a fixed deadline for every route. Applications should keep the estimate separate from the quote’s commitment expiry and use the relevant transaction status to establish destination completion.

Where can a quoted stablecoin transfer be located using its transaction hash?

Rhino provides bridge-status lookup by deposit transaction hash and by withdrawal transaction hash. These lookups apply to quoted bridge-and-swap activity. Smart Deposit Address transfers use their address-specific status interface, so the lookup should match the way the stablecoin transfer entered the service.

Do unsupported stablecoin deposits receive an automatic refund?

An unsupported Smart Deposit Address token isn’t processed as a normal supported deposit. Rhino’s account-management team can help arrange its return. Recovery shouldn’t be treated as an automatic, immediate settlement path, and a refund destination must remain accessible to the intended recipient.

Will receiving a stablecoin also fund the gas needed to spend it?

A stablecoin credit doesn’t by itself establish a native gas-token balance. Rhino’s Gas Boost can include native tokens for the destination recipient when configured and supported for the transfer. That native-token amount is separate from the stablecoin receipt and appears in the quote’s gas-boost information.

Can a business request an unlisted stablecoin or chain?

Custom Chain and Token Support allows businesses to request additions beyond the standard configuration. Rhino evaluates liquidity, security, and operational requirements before adding support. The extension isn’t self-service, and requesting a token or chain doesn’t make an unsupported transfer available immediately.

Does reusing a stablecoin deposit address prove it’s still active?

Reusing an address doesn’t establish that Rhino is currently processing its deposits. The isActive field reports monitoring status, while isPaused reports whether the address is paused. Paused addresses reject incoming deposits until unpaused. An address’s existence and its ability to process a supported stablecoin deposit are separate facts.