CAPABILITY / C03 — DEAI

Decentralized AI.

What we bring when networks need Proof-of-Compute consensus, inference verification, or on-chain agent infrastructure.

§1 — What we ship.

What we ship.

Zpoken's decentralized AI practice builds Y.AI end to end (Layer-1 blockchain where mining is real AI inference — verification, routing, and settlement as protocol operations, with privacy-aware execution paths), contributed to Gonka's Proof-of-Compute consensus (Bitfury-backed, 11K+ GPUs, single network model: Qwen3-235B-A22B) and built app.gonka.ai, and shipped agent-layer work including OpenBet Claw (permissionless prediction-market AI agent) and Kaja AI. Our in-house cryptography research includes peer-reviewed work on ZK proof systems and Merkle tree cryptography that informs verifiable-compute design choices.

DeAI is the youngest of our four practices but the one with the most velocity in the market. The work splits into three categories: compute layer (PoC consensus, GPU verification, decentralized training infrastructure), inference layer (verification of model inference on-chain, model marketplaces, attestation systems), and agent layer (on-chain agents that take action with verifiable behavior).

§2 — What DeAI engineering actually requires.

What DeAI engineering actually requires.

DeAI looks like a mash-up of ML and crypto, but the engineering reality is closer to "consensus design with new verification primitives." Three things matter.

01.

Verifiable compute, not just compute.

A decentralized training network where any node can claim it's training is worthless. The hard problem in DeAI compute layers — Gonka, Bittensor, Akash, and the rest — is proving that a node did the work it claims to have done. Approaches include sampling (verify a fraction of work and challenge mismatches), redundant computation (multiple nodes do the same work and consensus picks the answer), and zero-knowledge proofs of computation (the node proves it ran the model). Each has different cost and trust tradeoffs. Picking the right one for the use case is the consensus design problem; implementing it is the cryptography problem.

02.

Inference verification under real model sizes.

ZK-of-inference is a real research direction but the primitives don't yet make 70B-parameter inference economical to verify on-chain — let alone 235B. The pragmatic path for current DeAI inference networks is sampling + slashing + reputation, sometimes augmented with TEE attestation. Knowing where the boundary is between "verifiable now" and "verifiable in two years when the prover cost drops" is the engineering call that separates DeAI projects that ship from DeAI projects that wait for the cryptography.

03.

Agent infrastructure with on-chain accountability.

Agent-layer work (OpenBet Claw is the example we know best) has to balance two pressures: agents need autonomy to be useful, and on-chain action needs verifiable correctness to be safe. The engineering question is how much agent reasoning is on-chain (cheap verification, expensive computation) versus off-chain with on-chain commitments (cheap computation, harder verification).

§3 — Representative work.

Representative work.

01 / Y.AI

DeAI infrastructure, built end to end.

Layer-1 blockchain where mining is real AI inference: score-weighted proof-of-useful-work consensus, three-layer inference verification (structural · loss-integrity · log-probability fingerprint), private execution, on-chain settlement, and an OpenAI-compatible platform API. Zpoken builds the protocol and the platform end to end. Devnet live; public mainnet on the published 2026 roadmap.

→ /work/y-ai

02 / GONKA

Proof-of-Compute consensus contributor.

Bitfury-backed L1 for AI compute. $50M raised, 11K+ GPUs. Zpoken contributes to PoC consensus development — Sprint mechanism + statistical validation, PoC v1→v2 migration with BLS slot-key precomputation, MMR off-chain artifact storage, vLLM-integrated PoC, bridge security (CertiK audit closure). Public on github.com/gonka-ai/gonka. Single network model: Qwen3-235B-A22B.

→ /ecosystem/gonka

03 / OPENBET CLAW

Permissionless prediction-market AI agent.

On-chain AI agent that creates and prices custom prediction markets, pooling funds against the user. The engineering challenge is hybrid: agent reasoning is off-chain (LLM inference), market creation and pricing is on-chain, and the agent's behavior has to be verifiable enough that users will fund pools against it.

→ /work

04 / KAJA AI

Autonomous on-chain trading agent.

Built in Rust with the code public (github.com/ZpokenWeb3/ai-agent-rust-backend). A character agent with its own smart wallet: users pitch it any token — memecoins to majors — and the agent evaluates each pitch through an LLM function-calling loop against quantitative criteria — holder distribution, dev allocation, FDV, token age, transaction volume — then executes its own buys on Raydium on Solana. Ships with an LLM price-forecasting service and Twitter/Telegram surfaces. The engineering shape: agent reasoning off-chain, funds and execution on-chain.

→ /work

§4 — Engineering tradeoffs we've converged on.

Engineering tradeoffs we've converged on.

The calls we keep arriving at across DeAI engagements.

Pragmatic verification beats research-grade verification, for now.

ZK-of-inference is the most theoretically clean verification primitive for DeAI, and it isn't economical for production model sizes yet. We've converged on hybrid verification — sampling, slashing, redundant computation, sometimes TEE attestation — for current production use cases, with the explicit acknowledgment that ZK-of-inference will replace pieces of this stack as prover costs drop. We architect DeAI consensus layers so the verification primitive can be swapped without changing the consensus mechanism above it.

Off-chain agent reasoning, on-chain commitment.

For agent-layer work, putting all the agent reasoning on-chain is too expensive and too slow. Putting all of it off-chain breaks the verifiability claim that makes the agent valuable on-chain. The pattern that works: agent reasoning runs off-chain (LLM inference, decision logic), and the agent commits to its actions on-chain through a verifiable interface (signed commitments, attestation, sometimes ZK proofs of state transitions). The split has to be designed; agents that put the wrong work on the wrong side either don't ship or don't hold up under adversarial use.

DeAI consensus is consensus first, AI second.

The hardest engineering in DeAI compute layers isn't the AI part — it's the consensus part with new verification primitives. We've found teams hire ML researchers to build DeAI consensus and ship slowly because the consensus mechanism design isn't an ML problem. We staff DeAI consensus engagements with consensus engineers who can read ML literature, not the other way around.

§5 — Bench.

Bench.

Engagements led by Mike Yezhov and Anton Yezhov. The DeAI practice draws on our cryptography practice for verification primitives — the same in-house cryptographers who shipped Wormhole ZK and zkSync work also do the verifiable-compute work for DeAI. See /founders.

↗github.com/ZpokenWeb3Public repositories ↗github.com/gonka-ai/gonkaContributor commits on Gonka L1 ↗github.com/ZpokenWeb3/ai-agent-rust-backendKaja AI agent — public code ↗Efficient and Universal Merkle Tree Inclusion Proofs via OR AggregationMDPI Cryptography · 2024 · informs verifiable compute ↗Enhanced Security and Efficiency in Blockchain With Aggregated Zero-Knowledge Proof MechanismsIEEE Access · 2024

§6 — How we engage.

How we engage.

Engagement model.

DeAI engagements run 4–8 months for a focused consensus or verification layer, 3–5 months for agent-layer infrastructure, multi-year for ongoing compute-network maintenance.

What we'll take on.

[01]

Proof-of-Compute consensus design and implementation

[02]

Inference verification primitives for production-scale models

[03]

On-chain AI agent infrastructure with verifiable behavior

[04]

Decentralized training network engineering

[05]

DeAI infrastructure takeovers where the in-house team needs cryptography depth

What we won't take on.

[01]

DeAI projects where the AI claim is a marketing layer over a non-AI architecture

[02]

Agent projects where the threat model around adversarial use is undefined

[03]

Compute network claims that don't have a clear verification primitive

[04]

"AI x crypto" projects that don't have a defensible reason to be on-chain at all

— ENGAGEMENT

If you're building a DeAI compute or inference layer, talk to a founder.

If you're building a DeAI compute layer, inference verification system, or on-chain agent infrastructure that has to hold up under adversarial use, 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