juno

Prop 374: BN254 Precompile for CosmWasm — Cheap On-chain Groth16 Verification (post-#373)

This proposal asks Juno governance to signal support for adding a small piece of standard cryptographic plumbing — a BN254 pairing precompile — to the CosmWasm virtual machine that Juno uses. The precompile makes on-chain zero-knowledge-proof verification on Juno roughly twice as fast and twice as cheap.

No funds are requested. No code executes on-chain from this vote. This is a signaling proposal only. If it passes, the code change is proposed upstream to CosmWasm — the shared VM used by dozens of Cosmos chains — with a Juno community mandate behind it. A separate future proposal would then ask validators to approve the actual software upgrade that carries it.

Full proposal write-up (readable version): https://hackmd.io/@WHsRy8ndRX6AWEQtE4AQiw/SyHB-GZ0Zl

Technical deep-dive (cases, risks, reproduction): https://github.com/Dragonmonk111/junoclaw/blob/main/docs/BN254_PRECOMPILE_CASE.md

Benchmark results (5 devnet samples): https://github.com/Dragonmonk111/junoclaw/blob/main/docs/BN254_BENCHMARK_RESULTS.md

Upstream CosmWasm PR: being opened in parallel — see source repo for latest.

Medium synthesis (post-#373 engineering diary): https://medium.com/@tj.yamlajatt/hardening-after-a-91-71-yes-on-proposal-373-b46d2939461f

Three Ordeals — TEE, ZK, scalability architecture: https://medium.com/@tj.yamlajatt/three-ordeals-on-the-juno-shore-a4662514ed44

Ffern audit retrospective: https://medium.com/@tj.yamlajatt/when-the-abbot-came-5dda4f22a5b1

Source (Apache-2.0): https://github.com/Dragonmonk111/junoclaw

Why this matters, beyond the numbers

Cheap on-chain zero-knowledge verification is a precondition for three directions the Juno community is actively discussing:

  1. Secure cross-chain bridges. If JUNO tokens flow to Base and Ethereum — as the recently proposed 10M JUNO liquidity incentive envisages — the bridges securing those flows are either multi-signature (historically fragile: Ronin, Wormhole, and Nomad together lost over a billion dollars) or zero-knowledge-verified (provably secure). Cheap BN254 makes the secure option affordable. Without it, Juno defaults to the fragile kind.

  2. AI agents that can prove what they did without leaking data. Today, agent attestation is all-or-nothing: publish prompts, model weights, and outputs — or trust the operator. With cheap ZK verification, an agent can prove on-chain that its output complies with policy, without revealing the private inputs that produced it.

  3. The agent-company suite — deterministic agents with pre-intent tools. JunoClaw is building a full agent-company stack on top of CosmWasm and DAODAO: task ledgers, escrow, registries, and a zk-verifier — all governed by on-chain DAOs. When an agent moves with a pre-defined intent (route a swap, verify a credential, triage a service request), it carries that intent as a deterministic, auditable program. BN254 is the piece that makes the proof of correct execution cheap enough to require on every task, not just sampled ones. The agent's TEE workbox produces the attestation; the chain's BN254 precompile verifies it. Together they guarantee that every agentic action — every meaningful service exchange between a person and a machine — is auditable, true, and fair. Compute is preserved because the agent doesn't re-execute on-chain; it proves it already executed correctly off-chain, and the chain checks the proof in a fraction of the time. That is the scalability unlock: verifiable deterministic agents doing real work, with the full composability of CosmWasm and the governance scaffolding of DAODAO as home base for expansion.

At 370,719 gas today, zero-knowledge verification on Juno consumes about 3.7 % of a whole block. That is too expensive to require on every important action. At ~187,000 gas it becomes affordable to require on every one. Cheap enough to be mandatory is the security property; the 2× speed-up is its shadow.

Scope relative to Proposal #373

Proposal #373 (91.71 % YES, 24 March 2026) recognised JunoClaw as Juno ecosystem infrastructure on the strength of TEE-attested verifiable agents, the Junoswap revival, and the validator-sidecar track. #373 did not explicitly ratify on-chain zero-knowledge verification as a second supervisory layer over agent behaviour. That frame has been built out since, and is what this proposal asks Juno governance to endorse next.

#373 said yes to the TEE half. The ZK half is new, and is properly put to a separate vote.

The gas delta — measured baseline, projected precompile

Path Gas per proof verification Source
Pure-CosmWasm (live on junoclaw-bn254-1 devnet) 370 719 gas MEASURED (5 samples, tx 87ECC0…0358488, code_id 1)
BN254 precompile — 3-pair canonical (EIP-1108) ~187 000 gas PROJECTED (EIP-1108 schedule)
BN254 precompile — 4-pair (as coded) ~223 300 gas PROJECTED (BN254_BENCHMARK_PROJECTED.md)
Reduction ~1.66–1.99× —

Pure-Wasm baseline is measured on the junoclaw-bn254-1 devnet (5 identical samples, 2026-04-30) and corroborated by the earlier uni-7 deployment (371,486 gas, code_id 64). Precompile projection is grounded in the EIP-1108 gas schedule plus a 30k SDK contract-overhead ceiling; the per-primitive wall-clock sanity check shows 3.4× – 13.5× headroom between scheduled and observed gas (see BN254_BENCHMARK_PROJECTED.md for the algebra). Every number above reproduces from a clean checkout with the benchmark harness in the source repository.

Precedent — this is not new technology

Chain BN254 precompile Since
Ethereum Yes (0x06 / 0x07 / 0x08) 2017 Byzantium, repriced 2019
Sui Yes (sui::groth16) 2023 launch
CosmWasm Not yet —

BN254 has 12+ years of cryptanalysis, is the curve every Ethereum zk-rollup and privacy protocol uses, and its reference library ark-bn254 is audited upstream.

What is already shipped (origin/main, commit ffa6545, 29 April 2026)

  • Host-function crate in Rust — 22 of 22 tests passing (unit + EIP-196/197 conformance vectors).
  • Guest-side shim so contracts can call the host functions without a cosmwasm-std fork.
  • Five unified diffs against CosmWasm/cosmwasm v2.2.0 and wasmvm v2.2.0, feature-gated behind a new cosmwasm_2_3 flag — no major version bump, existing contracts compile unchanged.
  • Feature-gated variant of the live zk-verifier contract (code_id 64) for A/B comparison.
  • Ephemeral single-validator devnet (Dockerfile) that applies the patches and builds junod v29.
  • Reproducible benchmark harness writing to docs/BN254_BENCHMARK_RESULTS.md — hardened post-Ffern with path canonicalisation, allow-roots, and proof-size caps.
  • Standalone gas-projection tool (cargo run --example gas_projection) producing docs/BN254_BENCHMARK_PROJECTED.md — interim projection while devnet measurement is in flight.
  • Devnet image-transfer helper (devnet/scripts/transfer-image-from-windows.sh) — bypasses patch-corruption issues when building from source on non-Windows hosts.
  • Independent operator-side audit by Ffern Institute (April 2026): five findings, five advisories, all remediated in v0.x.y-security-1.
  • Upstream PR body drafted and ready at docs/WASMVM_BN254_PR_DESCRIPTION.md.

Plan of record if this passes

  1. Open the upstream PR against CosmWasm/cosmwasm and CosmWasm/wasmvm.
  2. CosmWasm maintainer review (weeks, not days).
  3. On merge, a separate MsgSoftwareUpgrade proposal asks validators to adopt a junod build carrying the patch.
  4. Post-upgrade, one MsgMigrateContract swaps the live zk-verifier from its current backend to the precompile variant. Same contract address, same interface, same admin, same verification key — only the internal dispatch changes.

What this proposal does not ask for

  • No community-pool funds — the work is done.
  • No on-chain code execution from this vote.
  • No CosmWasm major-version bump.
  • No new trust assumptions.
  • No validator coordination today — that is the separate software-upgrade step, gated on both this vote and the upstream merge.

Risks and mitigations

  • Consensus break on upgrade — host functions are new imports; existing contracts unchanged; standard upgrade-review gate applies.
  • Denial-of-service via malicious pairing input — input capped at 64 pairs (~2.2M SDK gas) at the VM boundary.
  • Pure-Wasm vs precompile divergence — differential test over 1,000 random proofs asserts identical accept/reject behaviour.
  • Upstream rejects the PR — the host crate is vendorable into a Juno-specific wasmd fork; upstream merge is preferred, not required.

Audit scope and cost estimate

Effective audit surface is small by design: ~400 lines (host-function glue + upstream patches). The reference crate is ~90 % tests and documentation. The cryptographic library beneath (ark-bn254) is audited upstream. Realistic audit estimate: $30–45k, 3–5 weeks with Oak Security, Halborn, or Informal Systems (revised up from an earlier $15–25k pre-Ffern line; multi-platform validation, differential-test review, and re-audit-after-operator-hardening were the missing line items). To be funded via DAO treasury post-mainnet, per #373's plan.

Voting guide

  • YES — ship native BN254, in line with Ethereum precedent and the #373-endorsed ZK track.
  • NO — prefer a different curve. Please comment so the alternative can be addressed before any resubmission.
  • ABSTAIN — counted for quorum, no view.
  • VETO — harmful to Juno's direction. Please leave an on-chain comment so it can be addressed.

Bottom line for non-developer voters: A YES vote tells the Juno community "yes, go pursue the upstream code change." Nothing happens on-chain from this vote itself. If accepted upstream, a separate future proposal asks validators to approve the actual software upgrade.

Authorship

Proposed by VairagyaNodes — Juno staker since December 2021, validator candidate (unbonded). Reference implementation, patches, and documentation written by Cascade (pair-programming AI agent) at the proposer's direction.

Solo submission — signaling proposals do not require cosignatories. Jake Hartnell (Juno co-founder, WAVS architect) gave informal direction to pursue this work on 17 March 2026; he is welcome to co-sign on the Commonwealth thread if he chooses.

License — Apache-2.0 throughout.