§1 — Wormhole in one paragraph.
Wormhole in one paragraph.
Wormhole is cross-chain messaging infrastructure — the verified delivery of state and asset transfers across heterogeneous chains. The Foundation runs a decentralized contributor set rather than a single core team; contributor grants fund specific cryptographic and infrastructure work that advances Wormhole's roadmap. Wormhole's ZK roadmap is the Foundation's publicly signalled direction: replacing trusted validators with zero-knowledge proofs of source-chain consensus state.
§2 — What Zpoken contributed.
What Zpoken contributed.
The Wormhole Foundation awarded Zpoken a contributor grant to advance trustless ZK transfers — ZK light clients for NEAR and Ethereum that verify source-chain consensus state on the destination chain without trusted intermediaries. Separately, under contract engineering for the Wormhole Foundation, Zpoken built MultiGov's Solana implementation — the spoke-voting, staking, and vesting programs of Wormhole's multichain governance system — and engineered on the EVM side alongside ScopeLift. The light-client work and the Solana commit record are public.
[01]
ZK light client · NEAR → Ethereum
─ GRANT SCOPE
[02]
ZK light client · Ethereum → NEAR
─ GRANT SCOPE
[03]
MultiGov · Solana implementation
─ CONTRACT ENGINEERING
[04]
MultiGov · EVM engineering alongside ScopeLift
─ CONTRACT ENGINEERING
The substantive work in cross-chain ZK is not the circuit alone — it is the light client. The on-chain verifier must prove that consensus state on the source chain is what the client says it is, without trusting any intermediate party. The bridge protocol must get the right state to the destination chain. The relayer infrastructure must run reliably. Edge cases — reorgs on the source chain, finality differences, validator-set updates — must be handled correctly. Zpoken's contribution covers the light-client design, the on-chain verifier in Rust, and the integration with Wormhole's existing bridge protocol so the ZK light client can replace the trusted-validator model on the NEAR↔Ethereum path.
§3 — What this work actually involves.
What this work actually involves.
Proof-system selection for cross-chain verification.
Cross-chain ZK light clients need a proof system whose on-chain verifier cost fits the destination chain's gas budget and whose proving cost fits the relayer's economics. The choice space includes Groth16, PLONK, Nova, and STARK variants. The right call is downstream of the destination chain's gas profile and the trust assumptions Wormhole's contributor model can absorb. Zpoken's grant scope includes that selection and its consequences for prover and verifier engineering.
Light client over circuit-as-product.
Founder teams approaching cross-chain ZK often scope the work around "the circuit," because that is the part with the cryptography papers attached. In production cross-chain ZK, the circuit is 20–30% of the engineering effort. Light-client design, bridge integration, relayer infrastructure, and edge-case handling are the rest. The Foundation grant scopes the work around the light client end-to-end, which is the right scope for production ZK transfers.
MultiGov.
MultiGov handles proposals, voting, parameter changes, and protocol-upgrade coordination across the heterogeneous chains Wormhole spans, hub-and-spoke. Zpoken built the Solana implementation — the spoke-voting, staking, and vesting programs that carry Wormhole DAO governance on Solana — an implementation now through mainnet deployment (June 2025) and audit (July 2025) — and engineered on the EVM side alongside ScopeLift, which authored the initial EVM contracts. The Solana commit record is public: the zpoken account is the second-largest contributor to the official codebase.
§4 — Public surface.
Public surface.