Bridge

Kitchen Layer Official testnet bridge: https://bridge.kitchen-layer.com/

Overview

The bridging process from the HyperEVM testnet (Layer 1) to the Kitchen Layer (Layer 2) is powered by Arbitrum's cross-chain messaging protocol. This involves sending HYPE tokens to a specific Arbitrum Inbox contract on HyperEVM. This contract then facilitates the minting of equivalent tokens for your address on the Kitchen Layer after a finalization period.

Prerequisites

Before you start, ensure you have the following:

  • HyperEVM Testnet Wallet: A wallet like MetaMask or Rabby configured with the HyperEVM testnet RPC: https://rpc.hyperliquid-testnet.xyz/evm.

  • HYPE Tokens: Your wallet must hold sufficient HYPE for both the amount you wish to bridge and the gas fees on the HyperEVM testnet.

  • L2 Receiver Address: The wallet address on the Kitchen Layer where you want to receive the bridged HYPE.

The Core Component: The Arbitrum Inbox Contract

The central piece of this process is the Arbitrum Inbox contract on the HyperEVM testnet. This contract is the designated entry point for all L1-to-L2 messages and asset transfers.

  • Inbox Contract Address: 0xC16204f036b51FC395C00De8FaE8e2be6f3F406a

Bridging Methods Explained

Your script correctly identifies the two primary functions within the Arbitrum Inbox contract used for bridging native assets like HYPE.

Method 1: createRetryableTicket (Recommended)

This is the most robust and standard method for Arbitrum bridging. It creates a "retryable ticket," which is a guarantee that your transaction will either be executed on L2 or that you will be able to redeem it later. This method provides resilience against potential L2 execution issues.

Function Parameters:

  • to (address): The final recipient address on the Kitchen Layer.

  • l2CallValue (uint256): The amount of HYPE (in wei) you want to be credited to the to address on L2.

  • maxSubmissionCost (uint256): A fee paid on L1 to cover the cost of submitting the transaction data to the L2. Any unused portion is refunded.

  • excessFeeRefundAddress (address): The address to receive the refund for the maxSubmissionCost.

  • callValueRefundAddress (address): The address to receive a refund of the l2CallValue if the L2 transaction fails completely.

  • gasLimit (uint256): The gas limit for the transaction's execution on the Kitchen Layer.

  • maxFeePerGas (uint256): The maximum gas price you are willing to pay for the L2 transaction.

  • data (bytes): Additional data for a contract call on L2. For a simple HYPE transfer, this is an empty 0x.

Method 2: sendL2Message

This is a simpler function for sending a message and value directly to L2. While functional, it lacks the built-in retry and refund mechanisms of a createRetryableTicket.

Function Parameters:

  • messageData (bytes): The data payload for the L2 message. For a native HYPE transfer to your own account, this is typically 0x. The recipient is implicitly the sender's aliased address on L2.

Step-by-Step Guide for Direct Interaction

  1. Prepare the Transaction: Choose your interaction method. createRetryableTicket is strongly recommended for its reliability.

  2. Set Parameters:

    • Define your L2 receiver address (to).

    • Convert the amount of HYPE you want to bridge into wei for the l2CallValue.

    • Set appropriate values for gas (gasLimit, maxFeePerGas) and the submission cost (maxSubmissionCost). The values in your script serve as a good starting point.

  3. Execute the Transaction:

    • Use a library like viem or ethers.js to call the chosen function on the Inbox contract (0xC16204f036b51FC395C00De8FaE8e2be6f3F406a).

    • Crucially, the value of your Layer 1 transaction must be at least l2CallValue + maxSubmissionCost. This single transaction value covers both the bridged amount and the associated fees.

  4. Monitor the Transaction:

    • Once you submit the transaction, note the transaction hash.

    • Track its confirmation on a HyperEVM block explorer, such as https://testnet.purrsec.com/.

  5. Verify on Kitchen Layer:

    • After the Arbitrum bridge's finalization period (which can take several minutes), check the balance of your L2 receiver address on a Kitchen Layer explorer to confirm the arrival of your HYPE.

Troubleshooting

The analysis in your script's error handling is excellent. If your transaction reverts when calling the Inbox, it could indicate a deeper issue with the bridge's state:

  • Inbox Paused/Disabled: The bridge operators may have temporarily paused the contract.

  • Inbox Not Initialized: The contract may not be correctly configured.

  • L2 Chain Not Ready: The Kitchen Layer may be experiencing downtime or be unable to accept new messages.

  • Incorrect Inbox Address: You may be sending funds to the wrong contract. Always verify the address.

Other common issues include:

  • Insufficient Funds: Ensure your L1 wallet has enough HYPE to cover the value (l2CallValue + maxSubmissionCost) and the L1 transaction gas.

  • Incorrect L2 Address: Double-check the recipient address on the Kitchen Layer. Transactions to incorrect addresses are often irreversible.

Additional Notes

  • Adjusting the Amount: Bridge any amount of HYPE by specifying the desired _value in wei. Ensure your L1 wallet has sufficient HYPE.

PreviousChain infoNextNative Functions

Last updated