Smart contracts for ZetaChain's CCTX (Cross-Chain Transaction) functionality are going to be deployed on the following chains:

Currently Integrated & Deployed
ZetaChain (Universal Layer 1 – main deployment)
Ethereum
Binance Smart Chain (BSC)
Base
Solana
Bitcoin (via external interaction, not smart contracts)

Under Integration / Planned
TON (The Open Network) – under integration
Sui – under integration
Arbitrum – planned
Avalanche (Avax) – planned

ZetaChain primarily uses a whitelist approach for tokens integrated with its CCTX system:
-The Solidity codebase (e.g. ZetaConnector, Gateway, and ZRC20 contracts) checks against registered/whitelisted token addresses before allowing interaction.
-This is a security-first approach to avoid risks with malicious or non-standard tokens.

While ZetaChain is designed to interact with standardized tokens (ERC20, SPL, etc.), there are definitely assumptions:

• No reentrancy: The contracts often rely on non-reentrant behavior, especially around transfer and approve. Reentrancy protections (like OpenZeppelin’s nonReentrant) are used on critical entrypoints.
• Standard behavior: Tokens are assumed to:
• Return a boolean from transfer and transferFrom
• Not perform unexpected state changes or external calls
• Not have deflationary or fee-on-transfer mechanics (unless explicitly supported)

Owner is trusted
Keeper is not trusted
FeeManager is only trusted to collect the fees correctly

There are no enforced limitations on values set by admin roles in the codebase, including array lengths in access-restricted functions. This applies across all contracts, including any out-of-scope components.

Values such as protocol fees, connector addresses, TSS addresses, and whitelisted tokens are all admin-configurable without hardcoded caps or bounds in the smart contracts.

There are no limitations enforced by ZetaChain on values set by admins in integrated protocols, including restrictions on array lengths or config parameters in those external contracts.

ZetaChain assumes that the governance of integrated protocols is trusted and correctly manages their own access-controlled functions. This includes any contracts for token standards (e.g., ERC20), bridges, messaging layers, or chain-specific components (e.g., Sui Move modules, Solana programs).

he codebase sticks to a few key EIPs to stay compatible with the broader Ethereum and multi-chain ecosystem. Here’s what we follow and why:

EIP-20 (ERC20)
We use this for ZRC20 tokens so they behave just like regular ERC20s. It makes integration with wallets, DEXs, and other protocols super easy — important for cross-chain stuff.

EIP-165 (Interface Detection)
This helps other contracts know what our contracts support (like a “supports interface” check). Super useful when you’re interacting across chains or with unknown contracts.

EIP-712 (Typed Signing)
Used for secure off-chain signatures — great for things like meta-transactions or cross-chain messages where security matters.

The core off-chain mechanism in ZetaChain is the Threshold Signature Scheme (TSS) relayer, sometimes referred to as the Keeper. It plays a crucial role in:

• Watching multiple chains (EVM, Solana, TON, Sui, etc.)
• Reading events emitted from smart contracts (e.g. cross-chain transaction requests)
• Verifying the data and its source
• Signing the message (via TSS)
• Relaying it to the destination chain by calling the appropriate contract (e.g. ZetaConnector, ZetaReceiver, etc.)

• ZRC20 supply must match locked tokens 1:1
• Cross-chain messages should only be executed once
• Critical roles (e.g. TSS, connectors) must always point to valid addresses
• Protocol and gas fees must not exceed transferred value
• Paused contracts should block all state-changing operations

Simplified fee handling
Skips edge cases like fee-on-transfer tokens to avoid overcomplicating logic — only standard tokens are supported anyway.

One-time CCTX execution (nonce-based)
Uses nonces to prevent double execution of cross-chain messages — assumes relayers behave correctly.

Trusted roles (Owner, FeeManager)
Roles have broad permissions to simplify governance — trust is placed in proper key management.

ZRC20 token wrappers
Uses wrapped tokens instead of native bridging — allows consistent token handling across chains.

No array length restrictions in admin functions
Admin functions accept flexible input sizes — relies on trusted roles to avoid abuse.

Audit Reports & Security Programs
ZetaChain Audit Reports Repository
All formal audits are published here, including PDF reports and summaries:
https://github.com/zeta-chain/audit-reports

Bug Bounty on HackenProof
Ongoing bug bounty program inviting ethical hackers to identify vulnerabilities:
https://hackenproof.com/zetachain

Competitive Audits
Code4rena (November 2023)
Community audit covering core protocol logic and smart contracts:
https://code4rena.com/audits/2023-11-zetachain

Cantina (January 2024)
Competitive audit focused on ZetaChain’s cross-chain mechanics:
https://cantina.xyz/competitions/80a33cf0-ad69-4163-a269-d27756aacb5e

Documentation
Full technical and developer documentation:
https://docs.zetachain.com

Whitepaper
Detailed explanation of ZetaChain’s architecture and omnichain design:
https://www.zetachain.com/whitepaper.pdf

Website
Official website with protocol overview and ecosystem details:
https://www.zetachain.com

We’d like Watsons to focus on the following areas:

Cross-chain message execution logic
How CCTXs are processed across chains, with special attention to replay protection and data validation.

Token wrapping and unwrapping (ZRC20)
Focus on mint/burn logic, 1:1 backing assumptions, and any trust assumptions around whitelisted tokens.

Role-based access control and upgradeability
Verify that role permissions (Owner, Keeper, FeeManager, TSS) are scoped appropriately and can't be abused. Check any upgrade paths and emergency controls.

Fee handling and gas reimbursements
Inspect logic for calculating and distributing fees, including any assumptions about gas coin behavior (e.g., ZRC20-gas).

Threat Model: Solana Integration (withdrawAndCall)
This threat model focuses on the Solana integration for the withdrawAndCall functionality, which allows users to withdraw assets from ZetaChain and invoke a function on a target Solana contract. It involves both node-level logic and on-chain Solana programs.

Node PRs (Message validation, gas logic, and replay protection)
Validates Solana messages from ZetaChain
https://github.com/zeta-chain/node/pull/3450

Adjusts gas estimates for Solana transactions
https://github.com/zeta-chain/node/pull/3520

Handles Solana transaction construction
https://github.com/zeta-chain/node/pull/3638

Tracks and enforces nonces for Solana messages
https://github.com/zeta-chain/node/pull/3637

Adds pre-execution simulation for Solana transactions
https://github.com/zeta-chain/node/pull/3527

Protocol Contract PRs (Solana-side logic for withdrawAndCall)
Implements core withdrawAndCall instruction
https://github.com/zeta-chain/protocol-contracts-solana/pull/74

Secures Cross-Program Invocations (CPI)
https://github.com/zeta-chain/protocol-contracts-solana/pull/77

Clarification of how to consider a DOS to be >=7 days:
If the DOS requires a hard fork to be fixed, then it should be considered as a seven-day DOS that can be valid. If the DOS can be resolved in a simpler way, then it's considered less than seven days and invalid