Shibarium bridge - Token Routes and Arrival Verification

Asset Mapping Before Route Selection

Token compatibility determines which bridge mechanism can handle a transfer before withdrawal speed becomes a useful comparison. Proof-of-stake (PoS) bridge support covers ETH and the ERC-20, ERC-721, and ERC-1155 token standards. That coverage describes supported formats. An individual token or collection also needs the relevant mapping and an enabled route for the requested direction, because format compatibility alone doesn’t establish a connection between its contracts on Ethereum and Shibarium.

Plasma uses its own mapped assets and Ethereum exit contracts. Plasma’s general compatibility list covers ETH, ERC-20, and ERC-721, and excludes ERC-1155. The withdrawal instructions distinguish Plasma (BONE) from PoS token options. A listed format doesn’t guarantee an enabled route for a particular asset. Custom integrations using Chainlink’s Cross-Chain Interoperability Protocol (CCIP) form another implementation option. CCIP must support the network pair and token route, and the deployed contracts must support the transfer; the possibility of building an integration doesn’t establish a live transfer service.

PoS Checkpoints and Plasma Exit Contracts

PoS and Plasma connect source-chain activity to Ethereum through different validation mechanisms, which affect how a withdrawal progresses.

PoS Checkpoints

Validators create checkpoints that record Shibarium chain data on Ethereum. A PoS withdrawal relies on inclusion of its source transaction in a checkpoint before Ethereum can process the corresponding exit. Fast block production on Shibarium doesn’t eliminate that dependency. The withdrawal’s Ethereum stage needs the relevant checkpoint proof, even after the source chain has confirmed the burn.

Plasma Exits

Plasma contracts use an Ethereum exit mechanism for assets assigned to that path. The source burn, exit proof, and Ethereum processing belong to one withdrawal, so its exit conditions determine progress even when the Shibarium receipt already reports success and the source balance reflects the burn. The documented Plasma mechanism combines exit-proof validation with fraud challenges and validator verification. An advertised duration alone doesn’t establish the strength of those checks.

Source Networks and Fee Balances

The network executing each transaction determines the native balance that pays for gas. An Ethereum deposit needs ETH alongside the transferable asset. A withdrawal begins on Shibarium and needs native BONE for that transaction. An Ethereum exit transaction needs ETH, including the exit call in the documented PoS contract flow.

Mainnet Shibarium uses chain ID 109, while Puppynet uses chain ID 157. These identify separate networks. A wallet displaying testnet BONE doesn’t establish a mainnet fee balance. MetaMask or another compatible wallet must connect to the network that executes the requested operation. The documented withdrawal interface uses the same wallet address on Shibarium and Ethereum. BONE delegation records belong to Ethereum staking contracts, so bridged funds in Shibarium don’t constitute a validator stake.

Open full-size image

ERC-20 Approval and Transfer Commitment

ERC-20 authorization and the bridge transfer have different effects, even when an interface presents them within the same deposit flow.

Spending Allowance

ERC-20 approval gives a designated spender an allowance to move tokens from the owner’s balance. The spender address and approved amount define that permission. Check the token’s allowance for the owner and spender, because approve can return false without reverting the transaction. That permission doesn’t establish a bridge deposit or destination credit. An existing allowance can affect whether the interface requests another approval.

The Bridge Transaction

The transfer transaction invokes the selected bridge contract with the relevant asset and recipient details. Wallet connection alone doesn’t authorize that transfer. Signing authorizes the transaction, submission broadcasts it, and an execution receipt establishes what the source chain did. The contract address, encoded action, network, and amount deserve attention before signing, because a valid signature authorizes the specific transaction presented.

Deposits Through Ethereum State Sync

An Ethereum deposit locks eligible source assets and creates their pegged representation on Shibarium. The bridge’s deposit model uses a 1:1 token quantity relationship. That relationship concerns the transferred units; gas charges remain separate from the representation’s token amount.

State synchronization carries Ethereum events into Shibarium. Heimdall monitors the StateSynced event, and the receiving contract applies the associated data on the destination network. Bor executes the destination-side state changes. These components explain why successful Ethereum execution can precede the receiving balance update, without implying that a wallet must sign a separate transaction for every internal synchronization step.

Withdrawal Burns and Ethereum Exits

A withdrawal burns the bridged representation on Shibarium and unlocks its counterpart on Ethereum through the selected route’s exit mechanism.

Checkpoint-Based Withdrawal

The PoS contract flow waits for checkpoint inclusion before processing an exit through the RootChainManager . That contract verifies inclusion and decodes the relevant event logs. An authorized predicate contract applies the Ethereum state change. The source transaction hash identifies the burn that the proof concerns; it doesn’t itself replace the proof or confirm the recipient’s Ethereum balance.

Plasma Withdrawal

The Plasma path handles its assigned assets through Plasma exit contracts. Ethereum processing must complete before the recipient can treat the corresponding assets as received. Exact prompts and permitted tokens belong to the selected interface and mapping. A withdrawal instruction for one token’s Plasma path doesn’t establish that another token can use it.

Processing Time and Route Availability

Bridge timing follows the work that remains on each network, including source inclusion, state synchronization, checkpoint production, or Ethereum exit processing. Congestion and validator activity affect those stages. A fast source receipt can coexist with an incomplete cross-chain transfer. A displayed estimate describes the selected operation’s expected duration. It doesn’t turn elapsed time into an arrival record. Available token choices, transfer limits, and fee quotes can also change. A wallet connection establishes access to the interface, while acceptance of the particular asset and direction determines whether that interface can submit the requested transfer.

Transaction Receipts and Bridge Progress

A transaction receipt records execution on one chain, so bridge progress requires distinguishing the source operation from the destination operation. The eth_getTransactionByHash method identifies a transaction known to the queried node. The eth_getTransactionReceipt method returns its receipt after inclusion, when that node has one.

A pending transaction has no transaction receipt. A receipt with status equal to 0x1 reports successful execution; 0x0 reports failure. The intended deposit or burn’s successful receipt and relevant event logs establish its source-chain result. Bridge event logs, checkpoint inclusion, and the applicable exit record connect that result to subsequent processing.

Destination Tokens and Wallet Display

Wallet visibility depends on the destination network and token contract, as well as the underlying balance. An ERC-20 balance can exist on-chain without appearing in the wallet’s token list. Importing the mapped destination contract can reveal that balance; importing a token doesn’t move funds. For ERC-20 tokens, balanceOf identifies the account balance, and the token’s decimal precision determines its readable quantity. The contract address belongs to that particular network. For an NFT transfer, ownership of the relevant collection’s token ID provides the appropriate destination evidence. ERC-1155 assets require matching the token IDs and their quantities. A ticker alone can’t distinguish different deployments.

Recovery Boundaries After a Transfer Failure

Recovery depends on whether the intended source transaction failed, remains pending, or succeeded and awaits destination processing. The source transaction’s state determines whether recovery concerns that transaction or later bridge processing. An absent destination balance alone doesn’t identify the failing stage or justify replacing a confirmed source transaction.

A pre-submission error can concern insufficient native gas funds, missing authorization, unsupported token mapping, or invalid call parameters. Correct the affected input before submitting. For an included failure, inspect the receipt and available error details; retry only after correcting the cause, such as an insufficient gas limit. An increased fee doesn’t repair incompatible token support or an incorrect contract call.

A low-fee pending transaction can require a replacement using the same nonce and higher fee settings that its transaction type supports. That mechanism concerns a transaction awaiting source inclusion. It doesn’t replace a successful bridge burn, and a new nonce represents another source transaction.

After successful source execution, unresolved state synchronization, checkpoint inclusion, or exit validation belongs to bridge processing. Preserve the transaction identifiers and route details when investigating that stage. A missing proof or mapping error needs resolution for the existing transfer. An incorrect event signature can prevent exit validation by RootChainManager .