Blockchains and tokens

Wallet-as-a-Service supports multiple blockchain networks. This page describes the features available for each supported chain.

The following table shows feature availability for each blockchain.

The following table shows transaction and signing features for each blockchain.

The following table shows operational features for each blockchain.

Wallet-as-a-Service processes an incoming transaction as confirmed and reflects it in your wallet balance once it meets the chain-specific finality requirement below.

For block-based thresholds, the value is the number of additional blocks Wallet-as-a-Service waits after the block containing the transaction. Under the usual convention where the containing block is confirmation 1, a threshold of N additional blocks means the transaction has N + 1 confirmations when Wallet-as-a-Service processes it.

Some chains expose a finality mechanism instead of requiring Wallet-as-a-Service to apply an additional block threshold:

• BNB Smart Chain, Polygon, and Avalanche C-Chain — Wallet-as-a-Service uses the provider's native finalized block. For Avalanche C-Chain, this corresponds to the chain's consensus-accepted state.
• Solana — Wallet-as-a-Service uses the finalized commitment level.
• XRP Ledger — Wallet-as-a-Service processes transactions from validated ledgers.
• 1Money — Wallet-as-a-Service processes transactions from the latest checkpoint.

For BNB Smart Chain, Polygon, and Avalanche C-Chain, if the provider can't return a finalized block or its finalized head stops advancing, confirmation waits. Wallet-as-a-Service doesn't fall back to the latest block. Confirmation time can vary with network and provider conditions.

Applies to: Ethereum, Polygon, Arbitrum, Avalanche, Base, BNB Smart Chain, Tron

Wallet-as-a-Service detects a native-asset deposit, such as ETH on Ethereum or TRX on Tron, only when the deposit is the value of a transaction sent directly to your wallet address. A smart contract can also send a native asset to your wallet while it runs. That transfer is part of the contract's transaction, not a transaction of its own, and Wallet-as-a-Service doesn't record it:

• The deposit doesn't appear in the wallet's transaction history.
• The wallet's balance in Wallet-as-a-Service doesn't include it, so it's lower than the balance a block explorer shows for the same address.

Some exchanges, smart contract wallets, and decentralized applications send native assets this way. Before you share a deposit address, ask the sender to send native assets as a direct transfer to the address.

If you've already received a deposit this way, refresh the wallet's balances. A refresh reads the native-asset balance from the blockchain, so the wallet's balance then includes the deposit. A refresh doesn't add the deposit to the wallet's transaction history.

Asset sweeping doesn't move these deposits, even after you refresh the wallet's balances. A native sweep moves only deposits that Wallet-as-a-Service recorded. To move the funds, send a withdrawal from the wallet.

This limitation applies only to native assets. Wallet-as-a-Service detects ERC-20, TRC-20, and ERC-721 tokens that a smart contract sends to your wallet, as long as the token contract emits the standard Transfer event.

Wallet-as-a-Service doesn't detect token balance changes that don't emit a standard Transfer event. Examples include tokens with a non-standard transfer event, zero-value transfers, and rebasing tokens whose balances change without a transfer.

This section defines each feature shown in the tables above.

Wallet-as-a-Service classifies tokens using the following standard types. Use these types in the API when you specify token operations.

The following table summarizes which token standards are available on each blockchain.

Applies to: Ethereum, Polygon, Arbitrum, Avalanche, Base, BNB Smart Chain

EVM-compatible chains support the following token standards:

• NATIVE — The chain's native gas token (ETH, MATIC, ARB, AVAX, BNB).
• ERC-20 — Fungible tokens following the ERC-20 standard. BNB Smart Chain uses the BEP-20 standard, which is functionally identical and mapped to ERC20 in the API.
• ERC-721 — Non-fungible tokens (NFTs). Supported operations include mint, burn, and transfer.

Solana supports the following token standards:

• NATIVE — SOL, the chain's native asset.
• SPL — Tokens issued through either the SPL Token program or the Token-2022 (Token Extensions) program. The connector supports both token programs under the single SPL standard type.

Supported token operations: transfer, mint, burn, freeze, thaw, close account, and set authority.

Tron supports the following token standards:

• NATIVE — TRX, the chain's native asset.
• TRC-20 — Fungible tokens following the TRC-20 standard. TRC-20 uses the same contract interface as ERC-20, and Wallet-as-a-Service maps it to ERC20 in the API.

Bitcoin supports NATIVE only (BTC). Transactions use the UTXO model.

Wallet-as-a-Service supports native BTC sweeping. Wallet-as-a-Service doesn't support Bitcoin token standards such as BRC-20, Ordinals, and Runes for sweeping or other token operations.

Wallet-as-a-Service supports these script types: P2PKH, P2WPKH, P2SH, P2WSH, P2TR, and nested SegWit.

XRP Ledger supports the following token standards:

• NATIVE — XRP, the ledger's native asset.
• ISSUED_CURRENCY — Trustline-based tokens issued on the XRP Ledger. These tokens require a trust line between the holder and the issuer.

Additional supported operations: clawback and AMM (Automated Market Maker) transactions.

1Money supports the following token standards:

• NATIVE — 1MONEY, the chain's native asset.
• CUSTOM — Proprietary tokens issued on the 1Money network.

Supported token lifecycle operations: create, mint, burn, freeze, pause, whitelist, blacklist, and authority management.