Contracts of official protocol contracts deployed by the core ZetaChain team.
This repository is under active development and is not yet ready for production use.
The project is built using Blueprint.
contracts
- source code of all the smart contracts of the project and their dependencies.wrappers
- wrapper classes (implementingContract
from ton-core) for the contracts, including any [de] serialization primitives and compilation functions.tests
- tests for the contracts.scripts
- scripts used by the project, mainly the deployment scripts.
- Compile FunC:
make compile
- Run tests:
make test
- Run Blueprint scripts:
make run
All deposits are represented as internal messages that have the following structure:
- uint32
op_code
- operation code. Standard for TON - uint64
query_id
- not used right now. Standard for TON - ... the rest of the message is the operation-specific data
op_code:uint32 query_id:uint64 evm_recipient:slice (160 bits)
Deposits funds to the contract (subtracting a small deposit fee to cover the gas costs).
ZetaChain will observe this tx and execute cross-chain deposit to evm_recipient
on Zeta.
op_code:uint32 query_id:uint64 evm_recipient:slice (160 bits) call_data:cell
Deposits funds to the contract (subtracting a small deposit fee to cover the gas costs).
ZetaChain will observe this tx and execute cross-chain deposit to evm_recipient
on Zeta
AND call the contract with call_data
.
Note that call_data
should be
encoded as snakeCell
These "admin" operations are used to manage the contract. In the future, they will be fully managed by TSS.
Currently, a dedicated authority address is used state::authority_address
set_deposits_enabled
- toggle depositsupdate_tss
- update TSS public keyupdate_code
- upgrade the contract codeupdate_authority
- update authority TON address
ZetaChain uses MPC (Multi Party Computation) to sign all outbound transactions using TSS (Threshold Signature Scheme). Due to the technical implementation TSS uses ECDSA cryptography in opposite to EdDSA in TON. Thus, we need to check ECDSA signatures in the contract on-chain.
All TSS commands are represented as external messages that have the following structure:
uint32 op_code
- operation code. Standard for TON[65]byte signature
- ECDSA signature of the message hash (v, r, s)[32]byte hash
- hash of the payloadref cell payload
- the actual payload
By having this structure we can sign arbitrary messages using ECDSA, recover signature, then ensure sender and proceed with the operation.
The payload for op withdrawal (200)
is the following:
recipient:MsgAddr amount:Coins seqno:uint32
Let’s simplify the input as ["signature", "payload_hash", "payload_data"]
:
- With
signature + payload_hash
, we can derive the signer's public key -> check that the message comes from TSS. - By having
payload_hash + payload_data
, we can check that the payload is exactly the same as the one that was signed. - Otherwise, the sender could take any valid
signature + payload_hash
, append an arbitrary payload, and execute the contract on behalf of TSS (e.g. "withdraw 1000 TON to address X").