Which Assets and Networks Should You Accept?

A few years ago, the question a business asked before taking crypto was short: should we accept Bitcoin? Today it's longer and harder to answer with a yes or no. Which assets should we support, and on which network? What does each choice actually cost in fees, confirmation wait, and accounting overhead? That's a different question, and it deserves a different framework than "Bitcoin, yes or no."

Bitcoin and stablecoins: the market context

Bitcoin is still the asset everyone has heard of, and its price still moves enough that a payment worth $500 at broadcast can be worth meaningfully more or less by the time a business reports it. Stablecoins solved a narrower problem: track a fiat unit closely enough that a payment is worth roughly the same when it lands as when it was sent. That narrowness is exactly why they grew faster for payments specifically. The Chainalysis Geography of Cryptocurrency Report identifies stablecoins as one of the fastest-growing segments of the digital asset ecosystem, and Circle's State of the USDC Economy makes the same point from the issuer side: businesses increasingly use stablecoins as a settlement layer for cross-border commerce, combining blockchain-speed transfer with the price stability day-to-day operations need.

That comparison is market context, not a product decision Suward makes for you. Suward doesn't operate a Bitcoin rail, so the real decision a business makes here isn't Bitcoin versus stablecoins. It's which assets and which network.

What Suward actually supports

Suward's live network coverage is seven EVM chains: Ethereum, BSC, Arbitrum, Optimism, Base, Polygon, and Plasma. USDT settles across all seven. USDC covers six of them, sitting out only on Plasma. Arbitrum is the one chain where USDC actually means two different contracts, a native version and a bridged USDC.e, which is its own trap explained below. Each chain also accepts its own native gas token for customers who hold that instead: ETH on Ethereum, Arbitrum, Optimism, and Base; BNB on BSC; POL on Polygon; XPL on Plasma. GET /v1/assets is the live, authoritative list of everything accepted, and any fixed list, including this one, is a snapshot rather than a promise.

Those aren't cosmetic distinctions. "We accept USDT" is not a complete sentence. USDT on one network and USDT on another can carry a different fee, a different wait before it's safe to act on, even a different number of decimal places under the hood. None of that shows up on a checkout page displaying "USDT" as a label. It only surfaces once you look at what each network actually charges and requires.

The same token, seven different bills

USDT is the one asset that touches every network Suward supports, which makes it the cleanest way to see how much a network changes the economics of an identical token.

On Ethereum, USDT_ETHEREUM carries a $0.20 network fee and needs 12 confirmations before Suward marks a payment accepted. Move to Arbitrum, Optimism, Base, or Plasma and the same USDT costs $0.01 in network fee, at the same 12-confirmation depth. BSC's USDT is also $0.01, but needs 15 confirmations instead of 12. Polygon's USDT is $0.01 too, yet needs 128 confirmations, over ten times deeper than Arbitrum for an identical fee. Fee and confirmation depth are not the same axis. Each network sets both independently, and GET /v1/blockchains is where the current numbers live.

There's a third axis that doesn't show up in either figure: decimals. Most of Suward's stablecoin contracts, on Ethereum, Arbitrum, Optimism, Base, Plasma, and Polygon, report amounts in 6 decimal places. BSC's USDT and USDC contracts use 18, matching BNB itself rather than the convention every other network follows. An integration that assumes 6 decimals because that's what the first five networks used will misread a BSC amount by a factor of a trillion, not round it wrong by a cent. That's exactly why GET /v1/assets exposes decimals per asset instead of a business hardcoding it once and forgetting.

None of this is arbitrary. → Confirmations, Finality, and Reorgs covers why confirmation depth is set per network in the first place, and what happens if a chain reorganizes before that threshold is met.

The business consequence is direct. Suward's fee defaults put both the service fee and the network fee on the merchant unless configured otherwise, so a $10 charge routed through Ethereum gives up 2% of the transaction to the network fee alone. The identical $10 charge on any of the other six networks gives up a tenth of a percent. Same asset, same customer intent, a twenty-times difference in what actually lands in your account.

Two USDC contracts, one chain

Arbitrum is the one place where the same ticker maps to two different assets in Suward's ledger. USDC_ARBITRUM is the token Circle issues natively on Arbitrum. USDCE_ARBITRUM is the older bridged version, minted through Arbitrum's canonical bridge from back before Circle deployed there directly. Both settle at $1. Both show up as "USDC" in a customer's wallet. Neither one knows the other exists.

That's the trap. A customer holding USDC.e who sends it to an address expecting native USDC has sent the wrong asset, even though the symbol on their screen matched perfectly. A gateway that tracks "USDC on Arbitrum" as a single bucket either merges two balances that aren't fungible on-chain, or silently drops whichever variant it wasn't watching for.

Suward avoids that by treating them as what they are: two entries under the same USDC group, carrying distinct ids. A payment fixes one specific asset at creation, so the choice never comes up mid-transaction there. A static wallet's allowedAssets list is where it actually matters, since the same address stays open to whatever a customer sends. Most integrations standardize on native USDC_ARBITRUM and leave USDCE_ARBITRUM off the allow-list, rather than accepting whichever variant happens to arrive. → Static wallets covers how that allow-list works end to end.

Native gas tokens carry Bitcoin's volatility back in

Alongside stablecoins, Suward accepts each chain's own gas token as payment: ETH on Ethereum, Arbitrum, Optimism, and Base; BNB on BSC; POL on Polygon; XPL on Plasma.

None of these are stablecoins. Their price moves the same way Bitcoin's does, sometimes double digits in a single bad week, landing right back on the "Low" end of the price-stability row in the table above. The fee and confirmation figures from the previous section don't change just because the asset is a gas token instead of a stablecoin on the same chain. What changes is that the merchant is now holding an asset whose fiat value moves between broadcast and settlement, the exact problem stablecoins exist to avoid.

That trade-off is sometimes worth making. A customer who already holds ETH and would rather not swap into a stablecoin first pays faster and with less friction if you'll simply take ETH. A crypto-native platform whose treasury already carries some of a chain's native token isn't adding meaningfully new exposure by accepting more of it.

It's a worse trade for recurring billing, invoices priced against a fixed fiat figure, or a finance team that wants settlement to be boring. A $29 subscription shouldn't turn into a different dollar amount every renewal just because it happened to be paid in ETH. If gas tokens sit on your checkout page, treat them the way this article treats Bitcoin: an option for the customer, not a pricing assumption for the business.

How many networks should you actually open

Seven supported networks doesn't mean every business should open all seven. Each one added is another item on a checkout page, and another way for a customer to get something wrong: the wrong network selected inside their wallet's send flow, an asset that isn't actually on your allow-list, a chain whose confirmation policy nobody on the team read before launch.

The fee and confirmation numbers from the sections above aren't the same for every network, and that's exactly why the decision belongs to the business instead of defaulting to "support everything." A checkout aimed at retail customers making small, frequent purchases benefits from steering toward the cheap, fast-confirming networks, Arbitrum, Optimism, Base, and Plasma, where a $0.01 fee and a 12-block wait don't get in anyone's way. A business processing large, infrequent institutional transfers can afford Polygon's deeper 128-confirmation window in exchange for the same fee floor, because the wait matters less than the ticket size does.

Ethereum is the harder case. Its $0.20 fee is a rounding error on a five-figure transfer and a real cost on a $10 one, so whether it belongs on your checkout depends more on customer expectation than on your own economics.

What happens to an asset that isn't on the list

None of this matters if a customer can send whatever they want and have it counted anyway. Suward doesn't work that way, and the exact behavior depends on which object is receiving the funds.

A one-off payment fixes its asset and network at creation. POST /v1/payments takes a single asset id, and the deposit address is scoped to receive exactly that asset. There's no "wrong asset" case to design around, because the checkout was never showing more than one option to begin with. The amount-matching edge cases, overpaid and underpaid, are a different problem, already covered in Accepted vs. Success.

A static wallet is where an out-of-scope asset actually shows up, because the same address stays open indefinitely and a customer can send anything to it. Every static wallet carries an allowedAssets list set at creation, and a deposit in anything outside that list is recorded with status ignored, visible in the deposit history for audit but never credited, with no webhook fired for it. No transfer is lost silently, and none is credited by accident either. → Static wallets documents the full deposit lifecycle, and Payments vs. Static Wallets covers when a static wallet is the right object to model in the first place.

The practical rule follows directly. Scope allowedAssets to exactly what your business is prepared to reconcile, not to everything Suward happens to support. A wider allow-list doesn't buy you more customers paying successfully. It buys you more ignored deposits sitting in a customer's history, with no way for either side to know a transfer went nowhere until someone asks why their balance didn't move.

The strategy that actually scales

The mistake most businesses make isn't picking the wrong asset. It's treating "which crypto do we accept" as one decision instead of two. The customer decides what they want to pay with, among the assets and networks a business actually offers, that's a UX and reach question. The business decides which of those assets and networks to support, and what sits on its balance sheet, that's a treasury question. A checkout page can list several stablecoin and native-token options across networks without forcing a finance team to carry Bitcoin, or a gas token's own volatility, on any invoice.

That separation is also why the underlying infrastructure matters more than the asset list. Whether a customer pays in a stablecoin or a network's native token, a payment gateway still has to detect the transfer, wait out the right confirmation depth for that specific network, screen it, and only then hand over a balance that's safe to act on. The Complete Guide to Crypto Payment Gateways walks through that lifecycle in full, and Choosing a Crypto Payment Gateway lays out the questions worth asking before committing to a provider.

Most businesses don't need to bet on an asset. They need a settlement layer that's predictable enough to build a P&L on, across the networks that actually carry commercial volume.