HyperCore to HyperEVM Asset Transfers
HyperCore and HyperEVM share one L1 but maintain different asset accounting, so supported transfers use protocol-defined system paths rather than an external crosschain bridge.
Moving an asset between HyperCore and HyperEVM is an intra-L1 state transition, not a bridge between two independent consensus systems. The environments still have separate accounting, so the protocol defines system addresses and transfer mechanics for supported assets. Timing differs by direction and should be handled explicitly by applications.
Same chain, separate ledgers
HyperCore spot balances and HyperEVM token or native balances are not one shared Solidity mapping. A transfer changes which execution environment recognizes the asset for use.
This is why a user can have HYPE available for native HyperCore activity but insufficient HYPE for EVM gas, or vice versa.
HYPE has a special system path
The HyperEVM developer documentation specifies a system address for moving HYPE from HyperCore to HyperEVM. Other supported assets use their documented mechanisms and token representations.
Builders should not generalize HYPE's special-case address to every asset.
Direction affects timing
Current interaction-timing documentation says HyperCore-to-HyperEVM transfers wait until the next HyperEVM block. HyperEVM-to-HyperCore transfers are processed in the same L1 block after the EVM block is built.
That ordering matters when a contract tries to fund a HyperCore account and submit a CoreWriter action immediately. The required HyperCore account state must exist at the appropriate point in the block sequence.
Accounting and UX
Interfaces should show pending or environment-specific balances rather than merging them into one number too early. Bots should reconcile the destination state before using transferred funds for margin or another action.
The fact that the transfer is native does not remove the need to handle timing and failure.