Skip to main content

Overview

Starkzap supports bidirectional bridging between Starknet and supported external chains:
  • Ethereum (Canonical, CCTP, OFT, OFT-migrated, Layerswap routes)
  • Solana (Hyperlane, Layerswap routes)
Deposit flow (external chain → Starknet):
  1. Configure the SDK (including optional bridging config)
  2. Fetch bridgeable tokens with sdk.getBridgingTokens(...)
  3. Connect an external wallet (ConnectedEthereumWallet or ConnectedSolanaWallet)
  4. Inspect balance, allowance, and estimated fees
  5. Call wallet.deposit(...) to submit the source-chain transaction
Withdraw flow (Starknet → external chain):
  1. Inspect L2 balance and estimated fees with wallet.getWithdrawBalance(...) and wallet.getInitiateWithdrawFeeEstimate(...)
  2. Call wallet.initiateWithdraw(...) to burn/lock tokens on Starknet
  3. Monitor status with wallet.getWithdrawalState(...) or wallet.monitorWithdrawal(...)
  4. For Canonical and CCTP: call wallet.completeWithdraw(...) when state is READY_TO_CLAIM

Install Optional Dependencies

Install only what you use. For Ethereum routes:
For Solana Layerswap routes (the Layerswap client is inlined — no Hyperlane packages needed):
For Solana Hyperlane routes:

SDK Configuration

Use bridging config when you need custom external RPCs or OFT support. The SDK uses external RPCs to read source-chain state (balances/allowances), estimate bridge fees, and submit source-chain transactions reliably. Without explicit RPC URLs, these operations can be rate-limited or unavailable depending on your environment:
OFT bridging requires bridging.layerZeroApiKey and is supported on Starknet Mainnet routes only.
Layerswap routes and Layerswap token discovery require bridging.layerswapApiKey. Without it, getBridgingTokens(...) omits Layerswap-bridgeable tokens and Layerswap deposits/withdrawals fail.Layerswap API keys are environment-scoped: use a Mainnet key with Starknet Mainnet and a Testnet key with Starknet Sepolia.
Layerswap withdrawals sign calls that come from the Layerswap API. Starkzap checks every one of them before the wallet signs: a call on the bridge token must be a transfer, and any other call must target a contract listed in bridging.layerswapAllowedContracts. With that list unset or empty, only the transfer is accepted, and a deposit action carrying any other call fails before signing with an error naming the address.Before enabling a Layerswap route, run one withdrawal on Sepolia and inspect the deposit action Layerswap returns. If it includes a helper call, confirm with Layerswap which contract it is and why, then list that address. Do not list an address you have not verified — listing the bridge token itself changes nothing, since calls on it must be transfer regardless.

Fetch Bridgeable Tokens

Layerswap-bridgeable tokens are sourced from the Layerswap API and only appear when bridging.layerswapApiKey is configured. Without it, discovery silently omits Layerswap routes.

Connect External Wallets

Take a look at the Examples. For WalletConnect setup details, see WalletConnect Docs. In practice, you establish the external wallet session first (for example with WalletConnect), then pass its provider/account/chain into ConnectedEthereumWallet.from(...) or ConnectedSolanaWallet.from(...) for bridge calls.

Ethereum (EIP-1193)

Solana

External wallet network and Starknet network must match by environment: Ethereum Mainnet with Starknet Mainnet, Ethereum Sepolia with Starknet Sepolia, and Solana Mainnet with Starknet Mainnet. On Starknet Sepolia, the connected Solana wallet may be on either Solana Testnet or Solana Devnet — the right cluster depends on the route (see note below).
On Starknet Sepolia the two Solana routes target different clusters: Layerswap uses Solana Testnet (4uhcVJyU9pJkvQyS88uRDiswHXSCkY3z) and Hyperlane uses Solana Devnet (EtWTRABZaYq6iMfeYKouRu166VU2xqa1). Connect the Solana wallet to the cluster matching the route you intend to use. On Starknet Mainnet, both routes use Solana Mainnet.

Estimate and Deposit

On Ethereum a deposit can be two transactions: an ERC20 approve sized to the amount, then the deposit. Do not start a second deposit of the same token before the first has resolved. Both would read the same allowance and both would send an approve, and since approve sets rather than adds, the second deposit lands short and reverts. Serialize deposits per token, or set an allowance that covers them all before starting.

Withdraw from Starknet

Initiate (all protocols)

Complete (Canonical & CCTP only)

OFT, Hyperlane, and Layerswap are single-step — delivery on the destination chain happens automatically. For Canonical and CCTP, a second L1 transaction is required once the state becomes READY_TO_CLAIM.

Auto-withdraw (Canonical only)

Canonical supports an autoWithdraw option where a relayer handles L1 completion — no completeWithdraw call needed.

Monitor Bridge Transfers

WithdrawalState values:
  • PENDING — bridging in progress, no user action needed
  • READY_TO_CLAIM — ready to finalize on L1; call completeWithdraw (CCTP/Canonical)
  • COMPLETED — bridge flow fully complete
  • ERROR — unrecoverable error

Detailed status (advanced use)

Use monitorWithdrawal to get the full status snapshot including CCTP attestation data needed for completeWithdraw:
Similarly for deposits:

Protocol Notes

Common Errors

  • Chain mismatch: token source chain and connected external wallet chain must match.
  • Missing LayerZero key: OFT routes require bridging.layerZeroApiKey.
  • Missing Layerswap key: Layerswap routes and Layerswap token discovery require bridging.layerswapApiKey; the key must match the environment (Mainnet key for Starknet Mainnet, Testnet key for Starknet Sepolia).
  • Layerswap call not in bridging.layerswapAllowedContracts: the deposit action carried a call to a contract other than the bridge token. Nothing was signed. Inspect the call, and list the contract only if it is a Layerswap helper you have verified.
  • Unsupported chain pair: Ethereum mainnet must pair with Starknet mainnet; testnet pairings must match.
  • CCTP options missing: completeWithdraw requires options with attestation data for CCTP routes — the parameter is non-optional in practice.
  • Attestation expired: CCTP attestations have an expiration block; re-attestation is requested automatically during completeWithdraw.
For additional issues, see Troubleshooting.

Next Steps