OneSec bridge support

Developers Showcase
1

Hi @EnzoPlayer0ne @1eo @uk4z — I have a swap that’s been stuck for +5 hours and wanted to flag it.

What happened:

Details:

  • My account: yrkmr-p5bg3-mcvjn-mspgg-gpgu4-ghxcb-3alhi-gf6fa-zq6sp-xx6xk-nqe
  • USDC ledger: 53nhb-haaaa-aaaar-qbn5q-cai
  • Transaction indices: 19598-19602
  • Time: Aug 2, 2026, 8:07-8:12 AM UTC
  • Amount: ~496.99 USDC

Sequence was: mint in (497.0025) → approve/transfer to cxanv-7aaaa-aaaar-qbxpq-cai → approve from cxanv to 5okwm-giaaa-aaaar-qbn6a-cai → retry approve (same amount) → nothing since.

Could someone help?

Happy to provide any other details needed. Thanks.

2

@SenseiVague, did you eventually get help on this?

3

No, I did not :\

The transaction still seems to be stuck in the processing canister.

4

Has any member of the dev team been reachable, or any active members of that community (if any)?

5

Traced it — thanks for including the ledger indices, that made it fast.

The OneSec side of this actually completed. Your Ethereum→ICP transfer landed fine: 497.50 USDC locked on Ethereum (`0xbefbe2d5…7257f4`), 497.0025 minted to your principal at USDC ledger block 19598, 08:07:13 UTC. Run `get_transfers` on your principal against `5okwm-giaaa-aaaar-qbn6a-cai` and you’ll see it as Succeeded with destination chain ICP. So this was never one Ethereum→Arbitrum transfer through us — it was Ethereum→ICP, then a separate ICP→Arbitrum step.

Four minutes later, at block 19600, that 496.9725 moved from your principal to `cxanv-7aaaa-aaaar-qbxpq-cai`. That’s not one of our canisters and we can’t touch it. The balance you’re looking at on the dashboard is that canister’s account, not a OneSec processing account.

The liquidity error was us, though. `cxanv-7aaaa-aaaar-qbxpq-cai` approved the bridge, tried the ICP→Arbitrum leg, and we turned it down because we’d run dry on Arbitrum USDC. That check runs before we take custody of anything, so nothing of yours ever got stuck inside the bridge — but running out was our problem, and we’ve topped it back up. 765+ available now, so a retry will go through.

Catch is the retry has to come from `cxanv-7aaaa-aaaar-qbxpq-cai`. Our endpoint requires the caller to be the account holding the funds, and that’s `cxanv-7aaaa-aaaar-qbxpq-cai` — not you, not us. Whoever runs it needs to either send the USDC back to your principal or re-run the transfer themselves.

So: what did you use for the Arbitrum step? If we know what `cxanv-7aaaa-aaaar-qbxpq-cai` is we can probably chase it down ourselves. And your transactions are all Aug 2 but you mentioned ~5 hours — is there a newer attempt we should be looking at too?

Sorry about the liquidity gap, that one’s on us.

7

The account is tagged “OneSec” in my wallet’s own view, which reads to me like it’s part of your product’s flow, so I’m not clear how that squares with it being “not OneSec-controlled.” Can you explain exactly what that relationship is?

This label suggests this is a shared/decentralized canister your protocol uses.

Its says it on the internet computer dashboard…

https://dashboard.internetcomputer.org/tokens/53nhb-haaaa-aaaar-qbn5q-cai/account/cxanv-7aaaa-aaaar-qbxpq-cai

To clarify: I initiated this transfer through Plug Wallet, not through any custom canister of my own.

8

Have you tried Plug support on this?

Plug’s bridge runs on top of OneSec, and the canister currently holding your USDC looks like theirs, not ours — we can’t call it or move anything out of it.

Worth telling them the liquidity problem on our end is fixed: 765+ USDC available on Arbitrum now, so a retry from their side will go through.