We just had the announcement that native @USDC has been linked to @HyperliquidX HyperCore, but unfortunately it’s still not as simple as people think. There are limits on how much can be withdrawn from HyperCore to the HyperEVM, and from the outside it looks weird that any restriction would exist. But once you understand the nuance of how this integration works, it becomes clear why it behaves the way it does and why it took so long. Firstly, there’s still over $4B in USDC sitting in the Hyperliquid “bridge” contract on Arbitrum, and that alone makes the integration much more complex. It all comes down to how USDC has historically been accounted for. When users deposit into Hyperliquid through the Arbitrum bridge, they send USDC to the bridge contract where it’s locked, and then an equivalent amount is “minted” inside HyperCore. In reality nothing is actually minted — only Circle can mint USDC — but it effectively becomes a wrapped USDC on HyperCore. The balance you see in HyperCore is redeemable 1:1 for the USDC locked on Arbitrum. Now with the HyperEVM, Circle deployed native USDC and linked it to HyperCore, which means anyone can send USDC from any chain into the HyperEVM and then into HyperCore. And from HyperCore, you can now withdraw to HyperEVM and bridge out to any chain, or even redeem back into USD via Circle. This last part is where things get complicated, because Circle now has to trust that the “wrapped” USDC inside HyperCore really represents native USDC at a 1:1 ratio. Given the scale — billions — it’s likey one of the only integrations where Circle adds this extra trust layer. From an accounting perspective, the system stays in equilibrium as long as: USDC in the CoreDepositWallet + USDC in the Arbitrum bridge = USDC in HyperCore Because there are now two ways to enter and exit USDC (Arbitrum bridge + HyperEVM), we end up in the situation we see today: you can get illiquidity on one side even if the total system is fine. The same issue can technically happen withdrawing via Arbitrum too — it’s just far less likely because of the huge balance sitting there. So what’s the long-term solution? At a high level it’s simple: zero out the Arbitrum bridge balance and credit that same amount to the CoreDepositWallet on the HyperEVM. But actually doing that is more nuanced, and both the Hyperliquid and Circle teams have clearly chosen a cautious rollout. My guess is that both the Arbitrum bridge and HyperEVM flows will run in parallel for a while to give builders time to migrate. Tools like Stargate and Wormhole that support native USDC transfers via CCTP need to update to support USDC all the way through to HyperCore. Once the ecosystem has caught up, the Arbitrum bridge will likely be disabled — probably in the UI only, since the contract isn’t upgradeable. From there, there are two options that come to mind immediately: a) The Arbitrum bridge is paused permanently by validators, Circle blacklists the bridge address, and then force-mints the same amount of USDC to the CoreDepositWallet. Probably the safest, but it leaves $4B+ blacklisted on Arbitrum. b) Hyperliquid nodes are upgraded to only allow withdraws from the Arbitrum bridge to a specific destination, letting an internal sweep send the entire balance to a Circle-controlled wallet. Circle burns that USDC and force-mints the same amount to the CoreDepositWallet on HyperEVM. Either path consolidates everything behind native USDC and removes the historical dependency on the Arbitrum bridge. Once that’s done, the withdrawal limits due to illiquidity will disappear and the whole system will behave exactly how people expect from a “native” USDC integration.
· 13K Views
