CAPABILITY / C02 — CRYPTOGRAPHY · ZK

Applied cryptography
& ZK.

What we bring when protocols need ZK circuits, light clients, or privacy primitives the in-house team can't ship alone.

§1 — What we ship.

What we ship.

Zpoken's cryptography practice shipped ZK light clients to Wormhole (NEAR↔Ethereum, under the Foundation contributor grant) and built the Solana implementation of MultiGov — Wormhole's multichain governance system — under contract engineering for the Wormhole Foundation. The practice also ships cryptography work for zkSync (under NDA), the initial Penumbra Web Wallet (Prax browser extension) plus gRPC services for browser-based interaction with the private DEX, identity infrastructure with Privado/PolygonID, privacy-protocol work with Panther (Base deployment, DAO grant) and Hinkal — cryptography review and support on Hinkal's core contracts (HinkalBase, the Merkle layer, CircomDataBuilder, VerifierFacade).

The cryptography bench is the practice with the highest in-house specialization requirement. ZK and applied cryptography work is where the gap between "team that's built one circuit" and "team that's shipped multiple to mainnet" is widest, because the production failure modes only show up at mainnet load. We hire and retain in-house cryptographers; we don't subcontract this work, and we don't take engagements where the cryptography is downstream of someone else's design we haven't reviewed.

§2 — What ZK and applied cryptography work actually requires.

What ZK and applied cryptography work actually requires.

01.

Circuit design that survives the prover.

Most ZK demos work because the circuit is small and the prover runs on a laptop. Mainnet circuits face a different problem: the prover has to be efficient enough that the circuit can be proven economically at scale, and the verifier has to be cheap enough that on-chain verification doesn't dominate the gas cost of the operation. Circuit design choices that look fine in a notebook — high constraint counts, deep witness trees, complex hash schemes inside the circuit — can make the prover slow enough to be uneconomic and the verifier expensive enough to break the use case. We design with the prover and verifier costs in mind from the first iteration.

02.

Light client engineering for cross-chain ZK.

When the use case is cross-chain — proving on chain B that something happened on chain A — the work isn't just the circuit. It's the light client: the on-chain contract that verifies the proof against chain A's consensus state, the bridge protocol that gets the right state to chain B, the relayer infrastructure that runs reliably, and the mechanism for handling the edge cases (reorgs on chain A, finality differences, validator set updates). The Wormhole NEAR↔Ethereum light client is this kind of work. Most of the engineering is in the light client and the bridge mechanism, not in the circuit.

03.

Privacy primitives that don't fail under composition.

Privacy protocols (Penumbra, Panther, Hinkal) compose multiple cryptographic primitives — commitments, range proofs, set membership proofs, encryption — into a single user-visible flow. Each primitive can be correct in isolation and the composition can still leak. The failure modes are: trace correlation across transactions, statistical privacy loss from public metadata, and timing attacks at the relayer layer. Composition analysis is what separates privacy work that holds up to adversarial review from privacy work that doesn't.

04.

Verification that's cheap enough to use.

ZK rollup verification, identity proof verification, privacy proof verification — all of these have on-chain costs that determine whether the use case is economically viable. Reducing verifier costs means choosing the right proof system (Groth16, PLONK, Nova, STARK variants) for the use case, not the most cited one in recent papers.

§3 — Representative work.

Representative work.

01 / WORMHOLE NEAR↔ETH

ZK light client under Foundation grant.

Trustless ZK transfers between NEAR and Ethereum. Selected through the Wormhole Foundation contributor grant. The substantive work is the light client: an on-chain verifier that proves NEAR consensus state on Ethereum without trusting any intermediate party. Also: Zpoken built the Solana implementation of MultiGov, Wormhole's multichain governance system, and engineered on its EVM side alongside ScopeLift — contract engineering for the Wormhole Foundation, with the Solana commit record public in the official repository. Public via the Wormhole Foundation blog and Wormhole's ZK roadmap.

→ /ecosystem/wormhole

02 / PENUMBRA

Initial Web Wallet + gRPC services.

Open-source contribution to Penumbra, a private cross-chain PoS network. Zpoken developed the initial Penumbra Web Wallet (the Chrome extension that became Prax Wallet) and the gRPC services that support browser-based blockchain interaction with the protocol. Repo: github.com/zpoken/penumbra-web-grpc.

→ /ecosystem/penumbra

03 / EVIDENTIA

Cross-chain consistency primitives.

Zpoken's internal bond-backed stablecoin protocol, deployed across 3 chains with LayerZero omnichain messaging. The cross-chain consistency primitives for total supply tracking and per-batch redemption flows draw on the same cross-chain ZK practice — though the production protocol uses LayerZero rather than light clients.

→ /work/evidentia

04 / zkSYNC

Cryptography work · NDA-bounded.

Paid client engagement under NDA. Cryptography work supporting zkSync's ZK rollup infrastructure. Scope and disclosures bounded by NDA. Listed here because the engagement demonstrates the practice spans both ecosystem-contribution work (Wormhole, Penumbra) and rollup-scale client work (zkSync).

→ /capabilities/zk-crypto/zksync

05 / PANTHER

Panther Protocol's deployment on Base, carried by Zpoken.

The work ran as a DAO-approved grant — accepted unanimously by PantherDAO (PIP-29, Nov 2025) — covering deployment enablement, verification scripts, runbook, and dApp work; PantherPoolV1 was deployed and source-verified on Base in December 2025 and has been live since PIP-30 activation (January 2026). Panther's blog names Zpoken a development partner, and the DAO's own dev planning tracks "Supporting ZPOKEN on Base Deployment." Core repo public: github.com/ZpokenWeb3/panther. 2025–2026, ongoing.

→ /work/panther

§4 — Engineering tradeoffs we've converged on.

Engineering tradeoffs we've converged on.

The calls we keep arriving at across cryptography engagements.

Choose the proof system for the use case, not for the citation count.

Groth16, PLONK, Nova, STARKs — each has tradeoffs. Groth16 has the cheapest on-chain verifier cost for many use cases but requires per-circuit trusted setup. PLONK has universal setup but heavier verification. STARKs have no trusted setup and post-quantum security but larger proofs. We've found teams default to whichever proof system is most cited in recent papers; the right call is to start from the on-chain verification cost budget and the trust assumptions the protocol can tolerate, then pick the system.

In-circuit vs. out-of-circuit decisions matter more than circuit size.

The first instinct on circuit work is "minimize constraints." The better instinct is "minimize prover time × verifier cost × developer iteration speed." Sometimes that means more constraints in exchange for a simpler circuit that's faster to prove or cheaper to verify. We move computation out of the circuit when the witness can be reconstructed cheaply off-chain and verified by the circuit at lower cost than computing it in-circuit.

Light client work is the bulk of cross-chain ZK engagements.

On cross-chain ZK projects, founder teams often scope the work around "the circuit" because that's the part with the cryptography papers attached. In our experience the circuit is 20–30% of the engineering effort. Light client design, bridge protocol, relayer infrastructure, and edge-case handling (reorgs, finality differences, validator set updates) are the rest. We scope cross-chain ZK engagements around the light client, not the circuit.

Privacy protocols need composition analysis from the start.

Composition analysis — what does the protocol leak when its primitives are used together — has to be in the design phase, not a post-implementation review. We've found protocols that compose primitives correctly in isolation and leak in composition because the metadata at the protocol layer (timing, transaction sizes, relayer behavior) reveals more than the primitives' formal privacy guarantees suggest. We do composition analysis at design time and test it adversarially before mainnet.

§5 — Bench.

Bench.

Engagements led by Mike Yezhov and Anton Yezhov. The cryptography practice is in-house — we don't subcontract ZK or applied cryptography work. See /founders.

↗github.com/ZpokenWeb3Public repositories ↗github.com/zpoken/penumbra-web-grpcPenumbra Web Wallet + gRPC ↗Efficient and Universal Merkle Tree Inclusion Proofs via OR AggregationMDPI Cryptography · 2024 ↗Enhanced Security and Efficiency in Blockchain With Aggregated Zero-Knowledge Proof MechanismsIEEE Access · 2024 ↗wormhole.foundation/blogFoundation grant announcement ↗github.com/ZpokenWeb3/pantherPanther core repository — Base config + dApp workspace ↗blog.pantherprotocol.ioZpoken named development partner

§6 — How we engage.

How we engage.

Engagement model.

Cryptography engagements rarely run small — circuit and light-client work has high fixed cost regardless of project size. Typical scope is 3–6 months for a focused ZK circuit + light client; 6–12 months for privacy protocol work that includes composition analysis and adversarial review. Maintenance relationships continue past the initial engagement.

What we'll take on.

[01]

ZK circuits that have to ship to mainnet under real prover/verifier cost constraints

[02]

Cross-chain ZK light clients

[03]

Privacy protocol design and composition analysis

[04]

Identity protocol cryptography

[05]

Cryptography support for ZK rollups

What we won't take on.

[01]

ZK proofs-of-concept where the goal is a demo, not mainnet

[02]

Circuit work where someone else has already designed the protocol without cryptographer review and we're being brought in to "implement"

[03]

Privacy work where the threat model is undefined

[04]

ZK marketing material (whitepapers, post-hoc justifications for design choices we didn't make)

— ENGAGEMENT

If your protocol needs ZK or applied cryptography, talk to a founder.

If your protocol needs ZK circuits, light client engineering, or privacy primitives that have to hold up under adversarial review, the engagement starts with a 30-minute call.

That call is with a founder. Shapes, discovery, and terms → /engagement

Book a call→ Open the form