zkLink X Documentaion
HomeGitHubBlogExplorer
  • 🙂Welcome
    • Introduction
  • ⚖️Architecture
    • Overview
    • Settlement Layer
      • Working Principal of A Multi-Chain ZK-Rollup
      • Nexus: Settlement on ETH L2s
      • Origin: Settlement on ETH and Alt-L1s
      • Multi-Chain State Synchronization
        • In-Detail: Nexus Multi-Chain State Synchronization
      • Supported Networks of zkLink Nexus and Origin
      • Security Assumptions of zkLink Nexus and Origin
    • Execution Layer
      • TS-zkVM for App Rollup
    • Sequencing Layer
    • DA Layer
  • 🛠️Developer
    • Developer Overview
    • Get Started
    • Examples
      • Base Demo
    • JSON RPC & Websocket & Kafka
      • JSON-RPC API
      • JSON-RPC Errors
      • Websocket
      • Kafka
    • Transactions
      • Basic Types
      • State Update
      • Transaction
        • Deposit
        • FullExit
        • ChangePubKey
        • Withdraw
        • Transfer
        • ForcedExit
        • OrderMatching
        • AutoDeleveraging
        • ContractMatching
        • Funding
        • Liquidation
        • UpdateGlobalVar
      • Private Key & Signature
        • Algorithm
        • ChangePubKey
        • Withdraw
        • Transfer
        • ForcedExit
        • OrderMatching
        • ContractMatching
        • Funding
        • Liquidation
        • AutoDeleveraging
        • UpdateGlobalVar
    • SDK
      • Go
        • Types
        • Signature
        • Utils
        • Transactions
          • ChangePubKey
          • Withdraw
          • Transfer
          • ForcedExit
          • OrderMatching
          • ContractMatching
          • AutoDeleveraging
          • Funding
          • Liquidation
          • UpdateGlobalVar
      • Js
        • Signature
        • Utils
        • Transactions
          • ChangePubKey
          • Withdraw
          • Transfer
          • ForcedExit
          • OrderMatching
          • ContractMatching
          • AutoDeleveraging
          • Funding
          • Liquidation
          • UpdateGlobalVar
      • Dart
        • Signature
        • Utils
        • Transactions
          • ChangePubKey
          • Withdraw
          • Transfer
          • ForcedExit
          • OrderMatching
          • ContractMatching
          • AutoDeleveraging
          • Funding
          • Liquidation
          • UpdateGlobalVar
  • ⚙️Network Information
    • Connected Networks
      • Mainnet
      • Testnet
    • DApps & Deployment Addresses
      • Mainnet
      • Testnet
  • Wallet & User Fund Streamline
    • Withdraw
    • Wallet Integration & AA Wallet
    • Deposit
  • Integration Cases
    • Heavyweight Integration (Multi-Chain Derivatives & Spot Exchange)
    • Simple Integration (Multi-Chain Spot Exchange)
  • Appendix
    • Audits
    • FAQ
    • glossary
Powered by GitBook
On this page
  • Users can deposit to zkLink from the following address:
  • The scenarios of receiver address on zkLink are:
  • Deposit Functions
  • The accordingly call functions are as followed:
  • Exhaustive Scenarios
  • Example 1
  • Example 2

Was this helpful?

  1. Wallet & User Fund Streamline

Deposit

zkLink X supports account abstraction (AA) wallets and externally owned account (EOA) wallets, with either EVM addresses (20 bytes) or nonEVM addresses (currently Starknet address only, with 32 bytes).

Users can deposit to zkLink from the following address:

  1. EOA wallet on EVM

  2. EOA wallet on nonEVM

  3. Abstraction wallet on EVM

  4. Abstraction wallet on nonEVM

  5. CEX address on EVM (custodial, and usually only supports standard transfer contract calls)

  6. CEX address on nonEVM (custodial, and usually only supports standard transfer contract calls)

The scenarios of receiver address on zkLink are:

  1. EOA on EVM

  2. EOA on nonEVM

  3. AA wallet on EVM

  4. AA wallet on nonEVM

Deposit Functions

The accordingly call functions are as followed:

A: directly call zkLink deposit function

Note: supports both AA wallets and EOA wallets; it is required that the from_address can directly sign zkLink deposit transactions.

B: call transfer to user AA wallet

Note: supports AA wallets that adopt the zkLink auto transfer function only, such as UniPass.

C: call transfer to proxy deposit contract, and then automatically deposit to zkLink contract

Example scenarios:

  1. The from_address is not authorized to define the signature message. For example, a CEX user intends to withdraw directly from Binance to ZKEX.

  2. The address format of the to_address on zkLink and the from_address is different. For example, a user intends to deposit from a Starknet address to an EVM compatible AA wallet address.

Exhaustive Scenarios

AA Wallet - EVM (20 bytes)

AA Wallet - nonEVM (Starknet 32 bytes)

EOA EVM (20 bytes)

EOA nonEVM (32 bytes)

EOA - EVM

ABC

AC

AC

AC

EOA - nonEVM

AC

ABC

AC

AC

owned AA Wallet - EVM

ABC

AC

AC

AC

owned AA Wallet - nonEVM

AC

ABC

AC

AC

CEX - EVM

BC

C

C

C

CEX - nonEVM

C

BC

C

C

Example 1

A Unipass AA wallet user intends to deposit a Token (ABC) deployed on Ethereum from a CEX (such as Binance):

Step 1: On the ZKEX deposit page, locate ABC with the deposit address (0xabc...);

Step 2: Copy the address to the Binance withdrawal page and await approval from Binance;

Step 3: Wait for confirmation from ZKEX.

  1. Since the Unipass AA wallet is compatible with proxy deposit and is deployed on the EVM (the same network as ABC), the deposit address copied to Binance is actually the Unipass AA wallet address.

  2. If the token ABC is deployed on StarkNet, which differs from the network of the user's AA wallet, then a proxy deposit contract address would be generated on Starknet to assist the ABC deposit.

  3. Why not directly call deposit on zkLink? This is because in many cases, the withdrawal address does not support user-defined contract calls (zkLink deposit function), especially on CEXs, who generally only support the most basic transfer calls.

Example 2

A MetaMask user intends to deposit the token ABC on EVM from its MetaMask address:

Step 1: On the ZKEX deposit page, locate ABC and select "Personal Wallet" as the fund source (it may vary if it is a deposit from CEX). Enter the amount, sign in MetaMask, and call zkLink deposit function;

Step 2: Only wait for the deposit transaction to be submitted and confirmed on-chain (it required 36 blocks on Ethereum).

  1. A user may deposit to ZKEX from another MetaMask address. In this case, ZKEX can provide a separate deposit page to assist in signing the zkLink deposit with a third address.

  2. If the token is deployed on a non EVM-compatible network, the deposit will need to go through a proxy deposit contract.

PreviousWallet Integration & AA WalletNextHeavyweight Integration (Multi-Chain Derivatives & Spot Exchange)

Last updated 1 year ago

Was this helpful?

Below are 2 typical operational processes using as an example (the first dApp using zkLink infrastructure):

ZKEX.com
Proxy Deposit Flow