Cronos
Cronos bridge transfers progress from source execution to destination receipt
Cronos bridge uses Inter-Blockchain Communication (IBC) to transfer supported assets between Cronos EVM and connected networks. Successful source execution starts the cross-chain transfer; destination receipt completes delivery. Signing, submitting, and receiving a transaction hash establish earlier states. Completion requires a matching credit to the selected recipient, so a source success message alone does not prove that the destination account holds the transferred asset.
The transfer record must match the chosen networks, asset, amount, and recipient. Fees and elapsed time follow the selected route's conditions. The IBC web interface, wallet-integrated bridge, and separate zkEVM withdrawal system have different receiving-address and completion requirements.
Source confirmation and the refund branch
An accepted IBC transfer advances from source execution to destination delivery through relayed packets and verified proofs. The transfer application escrows assets or burns returning vouchers, depending on the asset's path. Successful receiving-side processing credits the destination representation.
An acknowledgement records the destination application's outcome. Relaying it back settles the packet on the source chain.
A delivery error can trigger a refund after its acknowledgement is processed on the source chain. An undelivered packet can also be refunded through timeout processing. Either outcome needs a recorded chain event, and a delayed interface message does not identify which outcome occurred.
Network, asset, and recipient preflight
The source network, destination network, and selected asset must form a supported route before the wallet authorizes the transfer. Cronos EVM and Cronos POS hold separate CRO balances. Their shared ticker does not make a direct send substitute for bridging.
Network-asset pairings
Documented IBC pairings connect Cronos EVM with Cronos POS for CRO, Cosmos Hub for ATOM, Akash for AKT, IRISnet for IRIS, Canto for CANTO, Celestia for TIA, and Juno for JUNO. The route selector and operational channel determine whether a particular transfer is presently available. An asset's presence in a wallet does not establish bridge support for that asset.
Recipient and fee readiness
A receiving address must belong to the destination chain and intended account. The web interface allows a second compatible wallet or a pasted address for transfers between Cronos POS and Cronos EVM. The Onchain wallet's Cronos Bridge feature limits transfers to addresses within the same wallet. Its transfer form warns against using centralized exchange wallet addresses. Clipboard substitution can change the recipient, so compare the complete pasted address with the intended destination.
The IBC web bridge separates wallet-paid source gas from its destination network fee. Where the promotional destination-fee waiver applies to transfers between Cronos POS and Cronos EVM, source gas remains payable. That promotion can change or end. Available fee funding must cover the selected request's charges; a fee waiver does not establish a universal cost. Cronos gas fees also affect later transactions that use the received balance.
Wallet consent and source execution
Wallet connection makes the selected account available to the bridge interface. The transfer still requires its own authorization. These actions establish different permissions, and neither a connected account nor an approved connection confirms that funds have left the source chain.
Connection consent
The sending wallet must use the selected origin network. A destination wallet connection, where supported, supplies a receiving address. Connecting that wallet does not combine balances across chains. Review which account and network the connection request exposes before allowing access.
Signing and execution
A signing prompt requests authorization for the transaction that it describes. Review the account, source network, transfer details, and gas charge before approval. The transaction identifier provides a way to locate the submitted request. Source-side acceptance requires successful execution on the source network. A transaction hash can exist while the request remains pending, and inclusion in a block does not turn failed execution into a valid transfer. Locate the execution outcome before interpreting a wallet's confirmation message as progress toward delivery.
Where can an in-progress IBC transfer be checked?
Bridge history and the Cronos IBC Bridge Activity API provide the relevant IBC records. IBC transfers on Cronos are processed at the Cosmos layer. Their packet events do not appear as ordinary EVM-compatible transaction logs. A standard EVM explorer or JSON-RPC query can therefore miss that activity, even when the transfer exists. The record must concern the correct sending account and network.
The wallet-integrated ATOM route has an additional display limitation when its indexer does not update the transfer status. Request Submitted can remain visible after delivery. The receiving network's recorded credit resolves whether funds arrived, while the stale interface still shows submission. Refreshing the display does not establish a new packet outcome.
Destination credit and balance reconciliation
Destination receipt requires a matching credit to the intended account on the chosen network. Check the received asset's network identity and representation as well as its amount. The source debit may include gas paid from the same balance, so it need not equal the receiving credit. Likewise, a ticker alone cannot identify which destination token arrived. Match the credit to this transfer, and account separately for fees, other account activity, and any explicitly required conversion.
A pending display after confirmed receipt
In this hypothetical IBC transfer, the sender specifies the source and destination networks, asset, amount, and receiving address. Route availability, the fee quote, and observed records are also hypothetical. The expected destination credit follows the route's stated conversion and fee treatment.
The route is available, the address matches the destination, and the source account covers the transfer and payable gas. A destination-fee waiver, if applicable, changes the payable charge. Any eligible alternative considered alongside this route must deliver the same destination asset and amount; comparing all payable charges for that same receiving result keeps the cost comparison consistent. A cost quote does not establish that delivery has occurred.
The source transaction executes successfully, but the bridge display remains pending. An IBC activity record identifies successful destination delivery, and the intended recipient's balance shows the matching asset credit. The observed credit matches the expected asset, amount, and receiving address, so this transfer has completed despite the stale display. No duplicate request is needed. If the corresponding credit were absent, successful source execution would leave delivery unresolved.
Incomplete delivery and timeout processing
An incomplete IBC transfer may be awaiting relay, carrying a destination error, or awaiting timeout processing. Those conditions lead to different next actions. The published estimate for IBC web transfers is 1 minute to 1 hour, depending on congestion. Elapsed time alone cannot establish whether the recipient received funds or the sender received a refund.
A packet awaiting delivery
When a packet remains undelivered without a recorded refund, successful source execution leaves the cross-chain leg unresolved. While the packet remains eligible for receipt, a relayer can deliver it with the proofs that the destination requires.
A recorded error or timeout
An error acknowledgement differs from a timeout. Processing an ICS-20 error acknowledgement on the source chain refunds the transferred tokens to the original sender. For an undelivered packet, a refund follows successful timeout processing. The timeout transaction and proof must reach the source chain and pass its checks; crossing the configured deadline does not independently move funds back.
A resolved refund belongs to the origin account and transferred asset. If neither destination credit nor a source refund is visible, retain the original transaction record and investigate that request. Repeating the transfer creates another request without resolving the first one's state.
Separate bridge routes and withdrawal conditions
Third-party bridge routes and zkEVM withdrawals have their own completion rules. The EVM bridge lists alternative providers for networks outside its available selection. Their asset support, charges, and recovery mechanisms cannot be inferred from the IBC process. A bridge option must fit the required receiving network and asset before its quoted cost becomes relevant.
The separate Cronos zkEVM Alpha network was deprecated in June 2026, with shutdown scheduled for June 3, 2027, at 03:00 UTC. Its wind-down plan calls for disabling new bridge deposits and keeping withdrawals available, subject to operational, technical, and security conditions. Assets remaining on that network after shutdown will not be recoverable.
zkEVM withdrawals require zkCRO for source gas. Some asset paths return an intermediate token, including LCRO, before conversion to CRO. A bridge receipt and a later redemption can therefore represent different endpoints. For these paths, the asset-specific withdrawal, claim, and conversion requirements determine when the requested receiving asset becomes available.
Cronos bridge - common questions
Can I close or refresh the bridge tab during processing?
Closing or refreshing the web bridge tab does not reverse a transfer that the source chain has already executed. Its interface can restore an in-progress reminder, and bridge history associates past transfers with the connected wallet. Reconnect the relevant sending account to review its records. The account and network matter when identifying the transfer.
Must the recipient sign a transaction to receive a standard IBC transfer?
Standard IBC receipt does not require the recipient to sign the destination delivery transaction. A relayer submits the packet, and the destination transfer application credits the recipient through its receiving logic. This applies to the IBC transfer itself. A separate withdrawal system that requires a claim, or a later conversion of an intermediate asset, can require another signed action.
Are simultaneous Cronos bridge transfers supported?
The IBC web bridge supports multiple ongoing transfers. Each request needs its own record because similar amounts and recipients can make separate transfers difficult to distinguish. Processing one request at a time reduces that confusion. A second, intentionally separate transfer also needs sufficient source funds and fee funding; it does not resolve a pending first request.
When can a pending source transaction be cancelled?
A wallet-supported cancellation can only attempt to replace a source transaction before the network confirms it. It cannot reverse an IBC transfer that has already executed. Cancellation availability depends on the wallet and source network, and a replacement can lose the race to the original transaction. Once execution has occurred, destination delivery and any applicable protocol refund are separate states.
Which records help diagnose an unresolved bridge transfer?
A useful transfer report identifies the source and destination networks, sending and receiving addresses, asset, amount, source transaction identifier, and any available packet or destination record. Include the exact error or progress label without treating it as proof of delivery. These records can expose account activity, so share them through the relevant support channel. Never include a recovery phrase or private key.
How can source and destination IBC records be matched?
Classic channel-based IBC identifies a packet through its source port, source channel, and sequence within the sending chain. Those fields connect the send event with the corresponding receipt or acknowledgement. The source transaction hash identifies source execution; a destination transaction has its own chain record. Matching packet details avoids assuming that the same transaction hash must appear on both networks.
Can the recipient be changed after source execution?
An executed IBC transfer fixes the recipient in its packet data. Editing the bridge's receiving-address field afterward does not change that existing packet. Successful delivery to a valid but unintended address also does not become a timeout refund merely because the sender wanted another recipient. The refund branch applies to the protocol's failure or timeout conditions, not a later change of intention.