ZetaChain

We express our gratitude to the ZetaChain team for the collaborative engagement that enabled the execution of this Security Assessment.

Zeta Migration supports the migration of ZETA balances to Solana. It combines a Go service that processes the source snapshot, verifies holder submissions, manages operational workflows, and prepares transactions with an Anchor program that records migration entries and pays eligible holders while preventing duplicate payments and enforcing the available token cap.

The final retest reviewed the client's latest remediation through commit 9eaefb57a3bc986bb3afc3f186231d52b945c6be. Six findings were retested. Three are Fixed and three are Mitigated. No new reportable security finding was identified in the remediation diff.

The system users should acknowledge all the risks summed up in the risks section of the report

{FindingsVulnSeverityStatusTable}

Documentation quality

• The main README provides detailed instructions for building, testing, launching, rehearsing, operating the manual claim path, and managing cold authority actions.

• The repository documents the boundary between the Go backend and the Anchor program, pinned toolchain versions, the committed interface checks, configuration fields, and local test requirements.

• Security-critical trust assumptions and cross-component invariants are spread across the README, command help, configuration, and source code. A single architecture and security model would make the database authority, RPC finality, deployment identity, key roles, and incident procedures easier to review and operate safely.

• Some safety properties depend on operator procedure instead of validation enforced by the system, as reflected by the reported deployment and operational findings.

Code quality

• The Go backend is divided into focused packages, and the Rust program uses instruction-specific modules with explicit account constraints.

• The Go and Anchor builds completed successfully. Formatting, static analysis, standard Go tests, Go race tests, Rust tests, and the committed interface compatibility check also passed.

• The code uses typed states, explicit errors, pinned tool versions, and reproducible build and test commands.

• The reported findings show weaknesses at component boundaries. Database rows, on-chain accounts, runtime configuration, RPC responses, worker leases, launch artifacts, and authority changes are not always bound or validated together.

Test coverage

No aggregate statement or branch coverage percentage and no mutation score were supplied or independently established during this review.

• The Go suite executed with a disposable PostgreSQL database recorded 1,786 passing tests and subtests and 76 skipped tests. The standard and race-enabled runs passed all executed packages.

• The Anchor program and local harness suites passed all executed tests, including 69 behavior tests in the harness and 7 unit and interface tests.

• The existing suites cover core claims, cap enforcement, authority checks, pause behavior, state transitions, database behavior, retry logic, launch checks, and negative program paths.

• Sixty-five end-to-end scenario tests and 11 additional Solana, Squads, identity, launch, and admin integration tests were skipped because the required local chain configuration was unavailable.

• Additional audit-written tests reproduced 66 security-relevant behaviors. These results show that important concurrency, RPC finality, deployment binding, fail-closed handling, and operational workflow cases were outside the original regression suite.

• Testing used disposable local services and synthetic inputs. No public network, production database, production wallet, or real holder data was used.

Zeta Migration moves ZETA entitlements recorded in a ZetaChain snapshot to recipients on Solana. The system combines a Go backend, a PostgreSQL database, an Anchor program, the Solana Token Program, and Squads based governance. The backend determines who is eligible and how much they may receive. The on-chain program enforces the payment limits and prevents the same migration entry from being claimed twice.

Core components

• Snapshot and PostgreSQL database: The snapshot contains source addresses and migration amounts. The backend imports those records and stores submissions, migration entries, transaction attempts, signatures, settlement state, and reconciliation data.

• Public and administrative APIs: The public API accepts holder signed claims and exposes eligibility and status information. The administrative API supports operator created claims, entry review, parking, and requeue operations.

• Submission worker and relay: The worker leases pending entries from PostgreSQL. The relay builds, signs, submits, and confirms Solana transactions, then records the resulting on-chain state.

• Solana program: The Anchor program creates one entry account for each source identifier, records the recipient, destination token account, amount, and claim status, and transfers tokens from the program vault.

• Squads and cold operations: Squads proposals are used for manual claims and privileged actions such as pausing the program, correcting an unclaimed amount, closing an unclaimed entry, and rotating authorities.

• Launch and monitoring tools: Operator commands initialize the program, fund the vault, validate configuration, compare Squads proposals, reconcile database and on-chain state, and expose operational alerts and metrics.

Claim flow

1. An approved snapshot is loaded into PostgreSQL and provides the amount associated with each eligible source address.

2. A holder signs a migration message that binds the claim to a Solana recipient. An authenticated operator can also create an administrative claim when required.

3. The backend recovers the source identity, reads the snapshot amount, derives the destination token account, and creates a durable migration entry.

4. The worker leases the entry. The relay checks the corresponding on-chain entry account and builds the required instructions. A new entry normally uses a create claim instruction followed by a claim instruction in the same transaction.

5. The program verifies the configured authorities, mint, vault, entry state, destination, pause state, and remaining population cap. It transfers the exact stored amount from the vault and marks the entry as claimed atomically.

6. The backend confirms the transaction, records the paid recipient, destination, amount, and signature, and exposes the result through status and reconciliation interfaces.

Onchain state and protections

• A single configuration account stores the mint, vault, hot entry authority, cold authority, pending authority nominees, pause status, population caps, and committed and claimed totals.

• Each migration entry is derived from the chain identifier and source key. Hot and manual claims share this account namespace, which provides the primary replay and duplicate payment protection.

• Claim execution is permissionless after an entry exists, but the caller cannot change the stored recipient, destination, or amount.

• The program uses checked accounting so that claimed value cannot exceed committed value and committed value cannot exceed the configured cap.

• The vault is a Solana token account controlled by a program derived authority. The program transfers tokens only through the claim instruction.

• The program does not verify ZetaChain identities or the off-chain snapshot. It trusts the backend, database, and authorized keys to create legitimate entries.

Authority and operational model

• Holder: Signs the migration message that selects the Solana recipient. The holder cannot independently choose the snapshot amount.

• Relay key: Pays transaction fees and signs outbound transactions as the Solana fee payer.

• Entry authority: Authorizes ordinary on-chain entry creation and is an online privileged key.

• Cold authority: Controls manual claims, pause operations, entry corrections, entry closure, and authority nominations. This role is intended to be operated through Squads.

• Mint authority: Funds the program vault during launch and remains responsible for supply control while the authority is active.

• Upgrade authority: Initializes the deployment and can replace the program while upgrade authority is retained.

• Administrative API key and database writer: Control important off-chain workflows and stored entitlement state. Their security is part of the effective payment authorization boundary.

The main security boundary lies between off-chain eligibility decisions and on-chain payment enforcement. PostgreSQL, runtime configuration, RPC responses, online signing keys, Squads proposals, and the Solana program must remain consistent for the migration to operate safely.

Assets in Scope