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
  • Encode
  • Example

Was this helpful?

  1. Developer
  2. Transactions
  3. Private Key & Signature

Funding

Encode

Name
Rule

type

1 byte, 0x0d

accountId

4 bytes

subAccountId

1 byte

accountIdNonce

4 bytes

fundingAccountIds

4 bytes(when length is 1) or 31 bytes(when length > 1)

fee

feeToken

2 bytes

The encoding process of fundingAccountIds is as blew:

  • If the length is 1, encode the item directly in big endian;

  • If the length > 1, encode the item in big endian into a bytes list in order;

  • Pass the bytes list to the rescue_hash function in Rust SDK, and get the 31 bytes result.

Example

For the fundingAccountIds length is 1:

{
  "type": "Funding",
  "accountId": 1,
  "subAccountId": 2,
  "subAccountNonce": 3,
  "fundingAccountIds": [ 1 ],
  "fee": "0",
  "feeToken": 0,
  "signature": {
    "pubKey": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "signature": "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  }
}

the encode result is:

[13, 0, 0, 0, 1, 2, 0, 0, 0, 3, 0, 0, 0, 1, 0, 0, 0, 0]

For the fundingAccountIds length is larger than 1:

{
  "type": "Funding",
  "accountId": 1,
  "subAccountId": 2,
  "subAccountNonce": 3,
  "fundingAccountIds": [ 1, 2, 3 ],
  "fee": "0",
  "feeToken": 0,
  "signature": {
    "pubKey": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "signature": "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  }
}
encode_bytes = [13, 0, 0, 0, 1, 2, 0, 0, 0, 3, 229, 21, 12, 161, 198, 143, 182, 230, 55, 168, 20, 44, 52, 201, 150, 10, 189, 128, 111, 32, 198, 206, 155, 157, 175, 56, 77, 76, 234, 70, 83, 0, 0, 0, 0]
PreviousContractMatchingNextLiquidation

Last updated 1 year ago

Was this helpful?

2 bytes, refer to fee pack method in

🛠️
BigUint pack algorithm