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.

Proxy Deposit Flow

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

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

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.