CAPABILITY / C01 — L1 · L2

L1/L2 development
& infrastructure.

What we bring when chains have to ship to mainnet — and stay there.

§1 — What we ship.

What we ship.

Zpoken has shipped three chains to mainnet — Incentiv, an EVM-compatible L1 with custom Contribution-Scored Proof-of-Work consensus and native Account Abstraction; a second L1 under NDA; and the Mawari Network L3, an application-specific Arbitrum Nitro rollup for the Mawari DePIN. We also contribute to Gonka's Proof-of-Compute network, build infrastructure layers for chains that have already shipped — the Indexer for Canton Network — and run embedded chain engineering inside Alien Network's dev team across the Alien L1 and Solana.

L1/L2 work is the engagement type with the highest seniority requirement and the longest tail. Chains don't stop after launch. Most of our chain engagements are multi-month or multi-year. The work concentrates in three areas: shipping new chains to mainnet, maintaining live chains under load, and building the infrastructure layers (indexers, validators, bridges, RPC) that actual usage depends on.

§2 — What chain engineering actually requires.

What chain engineering actually requires.

Most "L1 development" sold by crypto agencies is forking. Take Cosmos SDK or OP Stack, change parameters, rebrand. The substance is in the parameters and the marketing. The engineering risk is low because most of the consensus, networking, and execution code is inherited from the upstream codebase. This is fine for projects that want to ship fast on a known design — but it isn't engineering takeover work and it isn't what we sell.

Real chain engineering is a different shape. Four things have to be true.

01.

Consensus design that isn't a fork.

When the chain has a novel consensus claim — Contribution-Scored PoW (Incentiv), Proof-of-Compute (Gonka), some other scoring or verification mechanism — the consensus has to be designed, not parameterized. Design means: the cryptographic primitives that make the scoring decisions verifiable, the game-theoretic analysis of what the consensus rewards and punishes, the engineering tradeoffs of latency and throughput against the new scoring overhead. None of this is in a Cosmos SDK fork. It has to be built.

02.

Native protocol features at genesis.

Account Abstraction, fee abstraction, multi-call, signature flexibility — these can be built as application-layer primitives on existing chains (ERC-4337 is the canonical example), or they can be built at the protocol level on chains shipping from scratch. Protocol-level versions are cheaper and faster but require chain-level engineering. The decision of which features to put in the protocol vs. the app layer is a long-term architecture call. We make those calls with founder-team buy-in and have shipped both patterns.

03.

Validator infrastructure that survives genesis.

New chains die at the validator layer more than they die at the consensus layer. Genesis-day instability — peer discovery failing under load, validator clients diverging from spec, mempool flooding — is what kills mainnet launches. Validator-side engineering is harder to demo and easier to skip in pre-mainnet planning. We don't skip it.

04.

Long-term maintenance.

Chains that ship to mainnet enter a maintenance phase that lasts as long as the chain does. Consensus upgrades, validator client patches, bridge security fixes, indexer adjustments — none of this is glamorous and all of it is the difference between a chain that's alive in two years and a chain that isn't. We maintain chains we shipped. We maintain chains we contribute to. The maintenance relationship is part of the engagement, not a separate contract.

§3 — Representative work.

Representative work.

01 / INCENTIV

EVM L1 with Contribution-Scored PoW.

EVM-compatible L1 shipped from genesis. Custom Contribution-Scored Proof-of-Work consensus. Native Account Abstraction at protocol level. The novelty is the consensus scoring layer — mining power weighted by contribution to network health, not raw hash rate. Most studios fork; we architected the scoring layer's cryptographic primitives from spec.

→ /work/incentiv
02 / GONKA

Proof-of-Compute consensus contributor.

Bitfury-backed L1 for AI compute. Network runs 11K+ GPUs, $50M raised. Zpoken contributes the Sprint mechanism, PoC v1→v2 migration with BLS slot-key precomputation, MMR off-chain artifact storage, vLLM-integrated PoC, and bridge security work — all public on the gonka-ai/gonka repository.

→ /ecosystem/gonka
03 / CANTON

Indexer for institutional finance.

Canton is Digital Asset's institutional finance chain — operated by regulated banks, asset managers, and market infrastructure providers, with privacy-by-default. Indexers built for public-DeFi norms fail Canton's regulatory question. Zpoken builds the Indexer infrastructure that holds the privacy boundary at the storage layer.

→ /work/canton
04 / MAWARI

The Immersive Compute Network.

A DePIN for real-time streaming of AI-powered 3D experiences. Zpoken builds the network's decentralized infrastructure: an application-specific L3 on Arbitrum Nitro (AnyTrust) settling to Arbitrum One, the Guardian node stack with license-gated operation and delegation, and the staking portal. Mainnet live. DePIN engineering sits between L1 work and DeFi work — on-chain primitives plus chain-aware off-chain coordination.

→ /work/mawari

§4 — Engineering tradeoffs we've converged on.

Engineering tradeoffs we've converged on.

The calls we keep arriving at across L1 engagements.

Custom consensus over fork-and-rebrand.

If the differentiation claim is "we're a faster Cosmos chain" or "we're an EVM chain with different gas pricing," the right answer is to fork the upstream codebase and ship. If the differentiation claim is "our consensus rewards a different thing than existing consensus does" — which is what Incentiv and Gonka both claim — forking is wrong. The consensus has to be designed. We've found the failure mode of "fork upstream and try to retrofit the new consensus claim into the existing scoring layer" leads to projects that ship slowly and ship buggy. Better to architect the consensus and inherit the parts that aren't novel (networking, RPC, execution).

Native protocol features at genesis, ERC-4337 after.

For chains shipping from genesis, native Account Abstraction is cheaper at runtime and architecturally cleaner than ERC-4337. ERC-4337 exists because Ethereum can't change its transaction model without a fork; chains that don't have that constraint shouldn't inherit it. The tradeoff is that native AA requires chain-level engineering and breaks bytecode-level compatibility with mainnet Ethereum tooling. For most non-Ethereum-clone chains, this tradeoff is favorable.

EVM compatibility for chains where the consensus is the novelty.

If the differentiation is at the consensus layer, EVM compatibility at the execution layer is the right call — it concentrates engineering on the actually-novel part and inherits the developer ecosystem for the parts that aren't. If the differentiation is at the execution layer (parallelism, new VM semantics, account model changes), then EVM compatibility is the wrong call. Chains that try to differentiate at both consensus and execution rarely ship.

Indexers are chain engineering, not application engineering.

We treat indexer work as part of the chain layer, not as part of the application layer. The reasoning: indexer correctness depends on chain-internal details — reorg handling, consistency model, native event semantics — that application engineers don't touch. Indexers built without chain-engineering input usually have to be rebuilt after the first chain upgrade.

§6 — How we engage.

How we engage.

Engagement model.

Engagements scale with scope. Some are 4–6 month focused builds — an indexer, a validator-layer rework, a chain-tooling buildout. Others are multi-year embedded chain partnerships. We discuss scope after we understand the problem.

What we'll take on.

[01]
New L1s with novel consensus or protocol-level features
[02]
Infrastructure layers (indexers, validators, bridges) for chains that have already shipped
[03]
Long-term chain maintenance for chains we know
[04]
Embedded chain engineering inside a client's existing dev team
[05]
Productized chain components with support contracts

What we won't take on.

[01]
Cosmos SDK / OP Stack forks where differentiation is parameterization, not engineering
[02]
"L2 launches" that are renamed RaaS deployments
[03]
Chain-as-marketing-vehicle work where engineering is downstream of token distribution
[04]
Chain projects without an in-house technical lead — we run alongside, not in place of
— CASE STUDYIncentiv→
— CASE STUDYCanton→
— INTERSECTIONL1/L2 × EVM→
— INTERSECTIONL1/L2 × Canton→
— ENGAGEMENT

If you're building an L1, talk to a founder.

If you're building an L1 with custom consensus, novel protocol-level features, or infrastructure layers that have to ship to institutional or DeAI standards, 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