The OneSec Bridge Thread Exposes a Missing Ownership Handoff in ICP Chain Fusion

A support thread about a stalled USDC transfer has exposed a practical weakness in chain-fusion UX: users may see one bridge flow while control of the funds changes between several independent steps and canisters.

The case began on August 2, when a user reported sending roughly 497 USDC from Ethereum toward Arbitrum through Plug and OneSec. The user believed the funds were trapped in a OneSec processing canister after a liquidity error. The full transaction sequence and the later clarification are documented in the Internet Computer Developer Forum thread.

According to OneSec representative 1eo, the first leg—Ethereum to ICP—completed successfully. The USDC was locked on Ethereum, 497.0025 USDC was minted to the user’s ICP principal, and approximately 496.9725 USDC was then transferred to the canister identified as cxanv-7aaaa-aaaar-qbxpq-cai. The second leg, ICP to Arbitrum, was a separate operation.

That distinction matters because the canister holding the funds was not controlled by OneSec, according to the representative. OneSec said its Arbitrum liquidity check rejected the transfer before the bridge took custody, but that the failed liquidity condition was its responsibility. The representative also said that the retry required a call from the account holding the funds, meaning the user could not simply retry from their own principal.

This is an ownership-handoff problem as much as a liquidity problem. A wallet interface can make Ethereum-to-Arbitrum feel like one action, while the underlying route may be Ethereum→ICP followed by ICP→Arbitrum. If the second step deposits assets into a forwarding or intermediary canister, recovery depends on knowing which component controls that canister and which identity is authorized to invoke the next action.

Plug’s own announcement describes its ICP-to-EVM bridging plans as powered by a partnership with OneSec and names Ethereum, Arbitrum, and Base as target networks. That confirms the product relationship, but it does not establish which canister owns a particular user balance in this incident.

The immediate lesson for builders is to expose custody and retry boundaries as first-class state. A bridge UI should identify the current asset holder, the component authorized to move it, whether the next step is reversible, and which support channel can act. “Processing” is not enough when the user and the bridge operator have different control over the account holding the funds.

The evidence remains limited. This report relies primarily on a single support thread; the 765+ USDC liquidity figure was stated by a OneSec representative and was not independently verified here. The thread also does not record a final recovery of the funds or a response from Plug support. Those gaps are precisely why cross-chain systems should publish machine-readable ownership, failure, and recovery states rather than leaving users to infer them from wallet labels.