• Overview
• ZilCrossChainManager Contract Specification
  • Roles and Privileges
  • Data Types
  • Immutable Parameters
  • Mutable Fields
  • Transitions
    • Housekeeping Transitions
    • Crosschain Transitions
    • Upgrading Transitions
• ZilCrossChainManagerProxy Contract Specification
  • Roles and Privileges
  • Immutable Parameters
  • Mutable Fields
  • Transitions
    • Housekeeping Transitions
    • Relay Transitions
• LockProxy Contract Specification
  • Roles and Privileges
  • Immutable Parameters
  • Mutable Fields
  • Transitions
• LockProxySwitcheo Contract Specification
  • Roles and Privileges
  • Data Types
  • Immutable Parameters
  • Mutable Fields
  • Transitions
    • Housekeeping Transitions
    • Bridge Transitions
    • Admin Transitions
• Multi-signature Wallet Contract Specification
  • General Flow
  • Roles and Privileges
  • Immutable Parameters
  • Mutable Fields
  • Transitions
    • Submit Transitions
    • Action Transitions
• SwitcheoTokenZRC2 Contract Specification
• More on cross chain infrastructure

The table blow summarizes the purpose of the contracts that polynetwork will use:

The ZilCrossChainManager contract is the main contract of the cross chain infrastructure between Zilliqa and Poly chain.

The table below describes the roles and privileges that this contract defines:

The contract defines and uses several custom ADTs that we describe below:

1. Error Data Type:

type Error =
  | ContractFrozenFailure
  | ConPubKeysAlreadyInitialized
  | ErrorDeserializeHeader
  | NextBookersIllegal
  | SignatureVerificationFailed
  | HeaderLowerOrBookKeeperEmpty
  | InvalidMerkleProof
  | IncorrectMerkleProof
  | MerkleProofDeserializeFailed
  | AddressFormatMismatch
  | WrongTransaction
  | TransactionAlreadyExecuted
  | TransactionHashInvalid
  | AdminValidationFailed
  | ProxyValidationFailed
  | StagingAdminValidationFailed
  | StagingAdminNotExist
  | InvalidFromContract
  | InvalidToContract
  | InvalidMethod

The table below lists the parameters that are defined at the contract deployment time and hence cannot be changed later on.

The table below presents the mutable fields of the contract and their initial values.

Note that some of the transitions in the ZilCrossChainManager contract takes initiator as a parameter which as explained above is the caller that calls the ZilCrossChainManagerProxy contract which in turn calls the ZilCrossChainManager contract.

Note: No transition in the ZilCrossChainManager contract can be invoked directly. Any call to the ZilCrossChainManager contract must come from the ZilCrossChainManagerProxy contract.

All the transitions in the contract can be categorized into three categories:

• Housekeeping Transitions: Meant to facilitate basic admin-related tasks.
• Crosschain Transitions: The transitions that related to cross chain tasks.

ZilCrossChainManagerProxy contract is a relay contract that redirects calls to it to the ZilCrossChainManager contract.

The table below describes the roles and privileges that this contract defines:

The table below lists the parameters that are defined at the contract deployment time and hence cannot be changed later on.

The table below presents the mutable fields of the contract and their initial values.

All the transitions in the contract can be categorized into two categories:

• Housekeeping Transitions meant to facilitate basic admin related tasks.
• Relay Transitions to redirect calls to the ZilCrossChainManager contract.

These transitions are meant to redirect calls to the corresponding ZilCrossChainManager contract. While redirecting, the contract may prepare the initiator value that is the address of the caller of the ZilCrossChainManagerProxy contract. The signature of transitions in the two contracts is exactly the same expect the added last parameter initiator for the ZilCrossChainManager contract.

LockProxy is a contract that allows people to lock ZRC2 tokens and native zils to get corresponding tokens in target chain (e.g. ERC20 in ethereum) and vise versa.

The table below describes the roles and privileges that this contract defines:

The table below lists the parameters that are defined at the contract deployment time and hence cannot be changed later on.

The table below presents the mutable fields of the contract and their initial values.

LockProxySwitcheo is a Switcheo version contract that allows people to lock ZRC2 tokens and native zils to get corresponding tokens in target chain (e.g. ERC20 in ethereum) and vise versa.

The table below describes the roles and privileges that this contract defines:

The contract defines and uses several custom ADTs that we describe below:

1. Error Data Type:

type Error = 
  | AdminValidationFailed
  | AmountCannotBeZero
  | LockAmountMismatch
  | ManagerValidationFailed
  | IllegalAmount
  | EmptyFromProxy
  | IllegalFromChainId
  | IllegalRegisterAssetArgs
  | AssetAlreadyRegistered
  | AssetNotRegistered
  | EmptyHashStr
  | InvalidFeeAmount
  | InvalidFromChainId
  | InvalidUnlockArgs
  | DeserializeRegisterAssetArgsFail
  | StagingAdminValidationFailed
  | StagingAdminNotExist
  | ContractPaused
  | ContractNotPaused

2. Cross-Chain Transaction Data Type:

(* toAssetHash, toAddress, amount *)
type TxArgs = 
| TxArgs of ByStr ByStr Uint256

(* used for corss-chain registerAsset method *)
(* assetHash, nativeAssetHash *)
type RegisterAssetTxArgs = 
| RegisterAssetTxArgs of ByStr ByStr

(* used for cross-chain lock and unlock methods *)
(* fromAssetHash toAssetHash toAddress fromAddress amount feeAmount feeAddress nonce *)
type TransferTxArgs =
| TransferTxArgs of ByStr ByStr ByStr ByStr Uint256 Uint256 ByStr Uint256

The table below lists the parameters that are defined at the contract deployment time and hence cannot be changed later on.

The table below presents the mutable fields of the contract and their initial values.

This contract has two main roles. First, it holds funds that can be paid out to arbitrary users, provided that enough people from a pre-defined set of owners have signed off on the payout.

Second, and more generally, it also represents a group of users that can invoke a transition in another contract only if enough people in that group have signed off on it. In the staking context, it represents the admin in the SSNList contract. This provides added security for the privileged admin role.

Any transaction request (whether transfer of payments or invocation of a foreign transition) must be added to the contract before signatures can be collected. Once enough signatures are collected, the recipient (in case of payments) and/or any of the owners (in the general case) can ask for the transaction to be executed.

If an owner changes his mind about a transaction, the signature can be revoked until the transaction is executed.

This wallet does not allow adding or removing owners, or changing the number of required signatures. To do any of those, perform the following steps:

1. Deploy a new wallet with owners and required_signatures set to the new values. MAKE SURE THAT THE NEW WALLET HAS BEEN SUCCESFULLY DEPLOYED WITH THE CORRECT PARAMETERS BEFORE CONTINUING!
2. Invoke the SubmitTransaction transition on the old wallet with the following parameters:
   • recipient : The address of the new wallet
   • amount : The _balance of the old wallet
   • tag : AddFunds
3. Have (a sufficient number of) the owners of the old contract invoke the SignTransaction transition on the old wallet. The parameter transactionId should be set to the Id of the transaction created in step 2.
4. Have one of the owners of the old contract invoke the ExecuteTransaction transition on the old contract. This will cause the entire balance of the old contract to be transferred to the new wallet. Note that no un-executed transactions will be transferred to the new wallet along with the funds.

WARNING: If a sufficient number of owners lose their private keys, or for any other reason are unable or unwilling to sign for new transactions, the funds in the wallet will be locked forever. It is therefore a good idea to set required_signatures to a value strictly less than the number of owners, so that the remaining owners can retrieve the funds should such a scenario occur.

If an owner loses his private key, the remaining owners should move the funds to a new wallet (using the workflow described above) to ensure that funds are not locked if another owner loses his private key. The owner who originally lost his private key can generate a new key, and the corresponding address be added to the new wallet, so that the same set of people own the new wallet.

The table below list the different roles defined in the contract.

The table below lists the parameters that are defined at the contract deployment time and hence cannot be changed later on.

The table below presents the mutable fields of the contract and their initial values.

All the transitions in the contract can be categorized into three categories:

• Submit Transitions: Create transactions for future signoff.
• Action Transitions: Let owners sign, revoke or execute submitted transactions.
• The _balance field keeps the amount of funds held by the contract and can be freely read within the implementation. AddFunds transition are used for adding native funds(ZIL) to the wallet from incoming messages by using accept keyword.

The first transition is meant to submit request for transfer of native ZILs while the other are meant to submit a request to invoke transitions in the ZilCrossChainManagerProxy contract or LockProxySwitcheo contract.

Refer to https://github.com/Zilliqa/ZRC/blob/master/zrcs/zrc-2.md but only LockProxy can mint and burn tokens.

• polynetwork
• zilliqa-relayer