Transaction types

Transaction Categories

We divide the transactions into two groups:

  • L1 transactions, initiated by an Ethereum account on the L1 chain.

  • L2 transactions, initiated by a shard chain account on the L2 chain.

We support several different circuit block sizes to reduce proof time without filling too much no-op work (or long delays until the circuit block can be fully filled).

  • L1 Transactions

    • Deposit

    • FullWithdraw

    • DepositNFT (In Development)

    • FullWithdrawNFT

  • L2 Transactions

    • UpdatePublicKey

    • Transfer

    • TransferToNewAddr

    • Swap

    • Withdraw

    • ForcedWithdraw

    • MintNFT

    • TransferNFT

    • TransferToNewAddrNFT

    • SwapNFT

    • WithdrawNFT

NO-OP transaction is an empty transaction that does not perform any action. It is used in circuit input when there are not enough transactions to fill the maximum number of transactions in a batch. This type of transaction does nothing and sets the availability data for available data to all zeros.

L1 Transactions

All Beacon chain data transactions are concatenated together and hashed in order for the collator to process them. These transactions must satisfy certain rules in order to be processed by the circuit. If any of these rules is not satisfied, the transaction is treated as a NULL transaction.

If any user tries to flood the beacon chain transactions with invalid transactions, they will have to pay the fees associated with beacon chain transactions.

Deposit

Depositing tokens from a beacon chain account to a shard chain account. If depositing ERC-20 tokens, the user first needs to approve the deposit contract so that the contract can be transferred to it using transferFrom. Native tokens for beacon chains are supported without additional packaging. If the account does not exist, a new account will be created.

  • Data-availability

- tx_type: 8 bits
- address: 32 bits
- token: 32 bits
- amount: 128 bits
- eth_address: 160 bits

  • 360 bits/deposit

  • 6 chips (80bits/chip)

FullWithdraw

FullWithdraw operation is initiated by the smart contract of the beacon chain and is guaranteed by the smart contract. This request needs to be processed within a reasonable time, otherwise the shard chain will be considered to have a critical problem and the contract will enter SafeExit mode. The process of entering the SafeExit mode is as follows:

The user can directly call the smart contract function requestFullWithdraw on the beacon chain to withdraw funds from the contract. requestFullWithdraw is a priority operation, and if the priority operation is not processed within the time specified in the contract (default is 5 days), anyone can call the activateSafeExitMode function to activate the SafeExit mode. During SafeExit mode, all transactions on the shard chain will be stopped and all users can withdraw funds by calling performSafeExit.

SafeExit mode ensures beacon chain level security for the DTX network. Users can always permissionlessly reconstruct state data and withdraw funds.

  • Data-availability

- tx_type: 8 bits
- address: 32 bits
- eth_address: 160 bits
- token: 32 bits
- full_amount: 128 bits
- special_accounts 32 bits
- special_eth_addresses 160 bits
- special_serial_id 32 bits
- special_content_hash .length bits

  • 880 bits/fullWithdraw(in the most common case)

  • 11 chips (80bits/chip)

FullWithdrawNFT

The FullWithdrawNFT operation is similar to the FullWithdraw mechanism we introduced above, it is initiated by the smart contract of the beacon chain and is guaranteed by the smart contract.

  • Data-availability

- tx_type: 8 bits
- address: 32 bits
- eth_address: 160 bits
- token: 32 bits
- full_amount: 128 bits
- special_accounts 32 bits
- special_eth_addresses 160 bits
- special_serial_id 32 bits
- special_content_hash .length bits

  • 880 bits/fullWithdrawNFT(in the most common case)

  • 11 chips (80bits/chip)

Layer-2 Transactions

All transactions of the shard chain are sent by the user to the collator. The collator collects them into a batch to be sent to the beacon chain. The collator must check the valid transactions it has collected and must not perform invalid transition states. Otherwise, the proof computed by the collator will be invalid. The user can submit any transaction data to the collator, but if the transaction cannot be processed, it will be rejected.

UpdatePublicKey

UpadtePublicKey - Change the public key of the shard chain account, which is used to authorize transactions in the shard chain. UpdatePublicKey is authorized with an ethereum private key whose address is the same as the address of the shard chain account.

UpdatePublicKey{
  account_id AccountId(u32)
  account Address(H160)
  new_pk_hash PubKeyHash(u8)
  fee_token TokenId(u32)
  fee BigUint
  nonce Nonce(u32)
  time_range TimeRange<valid_form,valid_until>(u64)
}

  • Data-availability

- tx_type: 8 bits
- address: 32 bits
- new_pub_key_hash: 160 bits
- eth_address: 160 bits
- nonce: 32 bits
- token: 32 bits
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)

  • 440 bits/updatePublicKey (in the most common case)

  • 6 chips (80bits/chip)

Transfer

Transfers tokens between two accounts inside the shard chain.

Transfer {
  account_id AccountId(u32)
  from Address(H160)
  to Address(H160)
  token TokenId(u32)
  amount BigUint
  fee BigUint
  nonce Nonce(u32)
  time_range TimeRange<valid_form,valid_until>(u64)
}

Not all features available for transfers using EdDSA signatures are available using on-chain authorization methods (like dual author transfers).

  • Data-availability

- tx_type: 8 bits
- from: 32 bits
- token: 32 bits
- to: 32 bits
- amount: 40 bits(35 bits for the mantissa part and 5 for the exponent part)
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)

  • 160 bits/transfer (in the most common case)

  • 2 chips (80bits/chip)

TransferToNewAddr

If the recipient account does not exist yet on the shard chain, it will be created and a numeric ID will be assigned to the provided address.

TransferToNewAddr {
  account_id AccountId(u32)
  from Address(H160)
  to Address(H160)
  token TokenId(u32)
  amount BigUint
  fee BigUint
  new_address Address(H160)
  nonce Nonce(u32)
  time_range TimeRange<valid_form,valid_until>(u64)
}

  • Data-availability

- tx_type: 8 bits
- from: 32 bits
- token: 32 bits
- amount: 40 bits(35 bits for the mantissa part and 5 for the exponent part)
- new_address: 160 bits
- to: 32 bits
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)

  • 320 bits/transferToNewAddr (in the most common case)

  • 6 chips (80bits/chip)

Withdraw

A withdrawal is used to transfer tokens from a shard chain to a beacon chain.

Withdraw {
  account_id AccountId(u32)
  from Address(H160)
  to Address(H160)
  token TokenId(u32)
  amount BigUint
  fee BigUint
  nonce Nonce(u32)
  fast bool
  time_range TimeRange<valid_form,valid_until>(u64)
}

  • Data-availability

- tx_type: 8 bits
- address: 32 bits
- token: 32 bits
- amount: 128 bits
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- eth_address: 160 bits

  • 376 bits/withdraw (in the most common case)

  • 6 chips (80bits/chip)

Swap

Atomic Swap lets you swap tokens with an existing account safely and cheaply.

Order {
  account_id AccountId(u32)
  recipient_address Address(H160)
  nonce Nonce(u32)
  token_buy TokenId(u32)
  token_sell TokenId(u32)
  price BigUint
  amount BigUint
  tolerance BigUint
  gas_fee BigUint
  transacion_fee BigUint
  order_amount BigUint
  direction BigUint
  total BigUint
  time_range TimeRange<valid_form,valid_until>(u64)
}
Swap {
  submitter_id AccountId(u32)
  submitter_address Address(H160)
  nonce Nonce(u32)
  orders (Order,Order)
  amounts (BigUint,BigUint)
  fee BigUint
  fee_token TokenId(u32)
  swap_fees (BigUint,BigUint)
}

  • Data-availability

- tx_type: 8 bits
- accounts.0[0].address: 32 bits
- recipients.1[0].address: 32 bits
- accounts.1[0].address: 32 bits
- recipients.0[0].address: 32 bits
- submitter.address: 32 bits
- accounts.0[0]token: 32 bits
- accounts.1[0]token: 32 bits
- submitter.token: 32 bits
- amount: 40 bits (35 bits for the mantissa part and 5 for the exponent part)
- second_amount: 40 bits (35 bits for the mantissa part and 5 for the exponent part)
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- swap_fees[0]: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- swap_fees[1]: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- nonce: 8 bits

  • 400 bits/swap (in the most common case)

  • 5 chips (80bits/chip)

ForcedWithdraw

Withdraw tokens from an inactive shard chain account to the Ethereum address corresponding to a shard chain account. An inactive shard chain account is an account with no shard chain signature key set.

ForcedWithdraw {
  initiator_account_id AccountId(u32)
  target Address(H160)
  token TokenId(u32)
  fee BigUint
  nonce Nonce(u32)
  time_range TimeRange<valid_form,valid_until>(u64)
}

  • Data-availability

- tx_type: 8 bits
- initiator_before.address: 32 bits
- target_before.address: 32 bits
- initator_before.token: 32 bits
- full_amount: 128 bits
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- eth_address: 160 bits

  • 408 bits/forcedWithdraw (in the most common case)

  • 6 chips (80bits/chip)

MintNFT

This transaction is used to generate NFT directly on shard chain. We allow the creator to choose whether to generate it to himself or directly to others.

MintNFT {
  creator_id AccountId(u32)
  creator_address Address(H160)
  content_hash H256
  recipient Address(H160)
  fee BigUint
  fee_token TokenId(u32)
  nonce Nonce(u32)
}

  • Data-availability

- tx_type: 8 bits
- creator_before_first_chunk.address: 32 bits
- recipient_account_before_fifth_chunk.address: 32 bits
- special_content_hash: 256 bits
- creator_before_first_chunk.token: 32 bits
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)

  • 376 bits/mintNFT (in the most common case)

  • 5 chips (80bits/chip)

TransferNFT

Transfers NTF between two accounts inside the shard chain.

TransferNFT {
  account_id AccountId(u32)
  from Address(H160)
  to Address(H160)
  token TokenId(u32)
  amount BigUint
  fee BigUint
  nonce Nonce(u32)
  time_range TimeRange<valid_form,valid_until>(u64)
}

Not all features available for transfers using EdDSA signatures are available using on-chain authorization methods (like dual author transfers).

  • Data-availability

- tx_type: 8 bits
- from: 32 bits
- token: 32 bits
- to: 32 bits
- amount: 40 bits(35 bits for the mantissa part and 5 for the exponent part)
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)

  • 160 bits/transferNFT (in the most common case)

  • 2 chips (80bits/chip)

TransferToNewAddrNFT

If the recipient account does not exist yet on the shard chain, it will be created and a numeric ID will be assigned to the provided address.

TransferToNewAddrNFT {
  account_id AccountId(u32)
  from Address(H160)
  to Address(H160)
  token TokenId(u32)
  amount BigUint
  fee BigUint
  new_address Address(H160)
  nonce Nonce(u32)
  time_range TimeRange<valid_form,valid_until>(u64)
}

  • Data-availability

- tx_type: 8 bits
- from: 32 bits
- token: 32 bits
- amount: 40 bits(35 bits for the mantissa part and 5 for the exponent part)
- new_address: 160 bits
- to: 32 bits
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)

  • 320 bits/transferToNewAddrNFT (in the most common case)

  • 6 chips (80bits/chip)

SwapNFT

Atomic swap allows you to exchange with existing accounts safely and cheaply. It supports not only the exchange between NFT and NFT, but also the exchange between NTF and fungible tokens.

Order {
  account_id AccountId(u32)
  recipient_address Address(H160)
  nonce Nonce(u32)
  token_buy TokenId(u32)
  token_sell TokenId(u32)
  price BigUint
  amount BigUint
  tolerance BigUint
  gas_fee BigUint
  transacion_fee BigUint
  order_amount BigUint
  direction BigUint
  total BigUint
  time_range TimeRange<valid_form,valid_until>(u64)
}
SwapNFT {
  submitter_id AccountId(u32)
  submitter_address Address(H160)
  nonce Nonce(u32)
  orders (Order,Order)
  amounts (BigUint,BigUint)
  fee BigUint
  fee_token TokenId(u32)
  swap_fees (BigUint,BigUint)
}

  • Data-availability

- tx_type: 8 bits
- accounts.0[0].address: 32 bits
- recipients.1[0].address: 32 bits
- accounts.1[0].address: 32 bits
- recipients.0[0].address: 32 bits
- submitter.address: 32 bits
- accounts.0[0]token: 32 bits
- accounts.1[0]token: 32 bits
- submitter.token: 32 bits
- amount: 40 bits (35 bits for the mantissa part and 5 for the exponent part)
- second_amount: 40 bits (35 bits for the mantissa part and 5 for the exponent part)
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- swap_fees[0]: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- swap_fees[1]: 16 bits (11 bits for the mantissa part and 5 for the exponent part)
- nonce: 8 bits

  • 400 bits/swapNFT (in the most common case)

  • 5 chips (80bits/chip)

WithdrawNFT

Withdraws NFT from a shard chain to a beacon chain.

WithdrawNFT {
  account_id AccountId(u32)
  from Address(H160)
  to Address(H160)
  token TokenId(u32)
  fee_token TokenId(u32)
  fee BigUint
  nonce Nonce(u32)
  fast bool
  time_range TimeRange<valid_form,valid_until>(u64)
}

  • Data-availability

- tx_type: 8 bits
- special_accounts[1]: 32 bits
- special_accounts[0]: 32 bits
- special_eth_addresses[0]: 160 bits
- special_serial_id: 32 bits
- special_content_hash: 256 bits
- eth_address: 160 bits
- special_tokens[1]: 32 bits
- special_tokens[0]: 32 bits
- fee: 16 bits (11 bits for the mantissa part and 5 for the exponent part)

  • 760 bits/withdrawNFT (in the most common case)

  • 10 chips (80bits/chip)

PreviousShard chainNextRollup data restore

Last updated