ZetaChain

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

zeta-migration is a Solana migration program that pays ZETA holders a new SPL token in place of the token they hold, according to an off chain snapshot. The program only enforces that no entry is paid twice and that total payouts stay within fixed caps, while an off chain Go service decides who is paid. The audit covered the zeta_migration Anchor program.

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

Documentation quality

• The README describes the launch sequence, the cold key operations, the incident flow, key rotation, and the pinned toolchain versions in detail.

• A formal specification or whitepaper is not present.

• Rustdoc and inline comments cover every instruction handler and the state types.

• The README matches the implemented instruction set and role model. Some safety properties rely on off chain procedures that are documented only as operator guidance.

• A small number of code comments diverge from the implemented behavior.

Code quality

• The code follows Anchor practice: account constraints, has_one checks, stored PDA bumps, and typed program accounts are used consistently.

• The program is small and split into one module per instruction, with named custom errors and checked arithmetic on all value fields.

• Dependency versions are pinned with = and the lockfile is committed.

• Issues in business logic, input validation, and code hygiene were identified and reported.

Test coverage

The code coverage of the project cannot be measured, because neither cargo llvm-cov nor cargo tarpaulin is available in the audit environment, however:

• The tests live in a separate harness workspace and run the built program in litesvm.

• Test files exist for initialization, claim creation, manual claims, claiming, amount updates, entry closing, pausing, authority rotation, and guard conditions.

• A mutation score was not produced.

The zeta-migration system moves the holdings of ZETA holders onto Solana as a new SPL token. It has two parts: an off chain Go service that reads the ZetaChain snapshot, verifies holder signatures, and submits transactions, and the on chain zeta_migration program, which is the only component in the audit scope. The program verifies no identity and mints nothing. Its two jobs are that no entry is paid twice and that total payouts never exceed the configured caps.

The program keeps three kinds of state. A single Config account at a fixed PDA stores the token mint, the vault address, the two authorities with their pending nominees, the pause flag, and two populations of counters, each with an immutable cap and running committed and claimed totals. One Entry account per source key, derived from the chain id and a 32 byte source key, records the recipient, the destination token account, the amount, a claimed flag, and a manual flag. A vault is an SPL token account PDA owned by a vault authority PDA, and it is funded by an external mint, since the program has no funding instruction. The token is a classic SPL Token mint with 9 decimals, no freeze authority, and a mint authority held outside the program. Amounts are u64 base units, and the supply is set by the snapshot total, with no fixed value in the code.

The initialize instruction runs once and is gated on the program upgrade authority. It creates Config and the vault, and takes the mint, both caps, and both authorities as arguments. The entry authority, a hot key held by the relay, calls create_claim, which writes an Entry paying the recipient associated token account and commits the amount against the cap. The cold authority, a Squads multisig vault, calls create_manual_claim to write an Entry with a named destination token account, update_entry_amount to correct an amount, close_unclaimed_entry to release a commitment and free the address, pause and unpause, and set_authorities to nominate new keys. A nominee confirms a role change through accept_authority. Any signer may call claim, which checks the entry, the destination, the mint, and the recipient, creates the associated token account if needed, records the claim against the cap, transfers tokens from the vault with transfer_checked signed by the vault authority PDA, and marks the entry claimed. The program depends on the SPL Token, Associated Token, System, and BPF upgradeable loader programs. Token-2022 is not supported.

Privileged roles

• Upgrade authority (zeta_migration): The BPF loader upgrade authority is handed to a Squads multisig after deployment. It is the only signer able to call initialize, which sets the mint, both caps, and the initial authorities with no on chain validation of those values. It can also upgrade the program, which is the only way to change the caps or any immutable configuration. A compromised or misused upgrade authority can replace the program logic and redirect vault funds. The role is protected by a multisig, and no timelock is described.

• Entry authority (zeta_migration): A hot key held in a key file by the relay service. It can call create_claim to write an entry for any recipient and any amount up to the remaining cap, while the program is not paused. It cannot update or close entries. Compromise of this key allows false entries that any caller can then claim, bounded by the cap. Pausing, voiding, and rotation are the available mitigations, and all of them depend on the cold authority. The key is a single key file with no multisig or timelock.

• Cold authority (zeta_migration): A Squads multisig vault. It can call create_manual_claim with an arbitrary destination token account and amount, update_entry_amount, close_unclaimed_entry with an arbitrary rent receiver, pause, unpause, and set_authorities. Update, close, and rotation calls remain available while the program is paused. Misuse could redirect payouts through manual entries, void entries, or take over both roles through nominations. The role sits behind the Squads multisig threshold, with no timelock. The program does not prevent the entry and cold authorities from being the same key.

• Nominee (zeta_migration): Any key named as a pending entry or cold authority by set_authorities. The nominee calls accept_authority to take the role, which clears the pending nomination. Accepting the cold role also clears a pending entry nomination. The role grants no power until the cold authority nominates the key.

• Mint authority holder (external to zeta_migration): The mint authority is an SPL token multisig with threshold 1, whose signers are the issuer bridge and the migration minter. It is not part of the program, but it controls the vault funding and can mint further tokens after launch. The program never compares the vault balance with the caps.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope