Lightpaper

Version 1.1 — October 2026. Every claim here points at something running, tested, or measured. Anything planned is labelled as planned.

1. What JunoClaw is

JunoClaw is a Layer 1 blockchain for verifiable agents and DAOs, powered by Commonware consensus and CosmWasm execution. A DAO can command an agent, agents can form the DAO, or a single agent’s work is verified cryptographically — and every action in between is proven.

The question it answers: how do you verify that an agent did what it said it did, without re-running the whole computation on-chain? Agents are starting to hold funds, sign transactions and act for people, and most of that work happens off-chain because chains are too slow and too expensive to run it natively. Off-chain is also where trust breaks. An agent inside a laptop, a cloud VM or a robot can show you its answer, and you still have to take its word. “The AI decided” is the modern “the dog ate it.”

Agents and DAOs

The first two run through agent-company, where members are typed Agent | Human | SubDAO and weighted in basis points summing 10,000. The third needs none of it — verification is the base layer, and a DAO is structure on top.

Case	What it means	Where it lives
A DAO commands an agent	A DAO defines an agent, hires it, verifies its work, pays or slashes it. WavsPush carries the task, execution tier and escrow; WeightChange sets the roster.	agent-company → agent-registry, task-ledger, escrow, zk-verifier
Agents form the DAO	A body whose members are agents, whose decisions are produced by verifiable computation rather than show-of-hands.	agent-company members, truth-market, moultbook, sortition
A single agent, verified cryptographically	One agent and one payer who wants the work verified. task-ledger accepts a task with no proposal_id, escrow records the obligation against a plain payer, and zk-verifier gates the release.	task-ledger, escrow, zk-verifier, agent-registry

Ordinary proposals need 51% quorum; constitutional ones (WeightChange, CodeUpgrade) need 67%.

The loop

1. Define — a soulbound agent identity: capabilities, model, a running trust_score.
2. Bound — constraint pre/post-hooks declare what this agent is permitted to attempt.
3. Fund — non-custodial escrow. The contract records the obligation; the wallet signs the transfer; the contract never holds funds.
4. Execute — local hardware, a hired Akash GPU, or a robot in the field. Cross the compute boundary and the trust chain holds, because the identity stays on-chain.
5. Verify — four independent witnesses (§2).
6. Settle — escrow auto-releases on verified success and reputation ticks up; a bad result draws SlashAgent. The on-chain anchor outlives the payload.

2. The four witnesses

An agent that controls a wallet or moves a machine is a small sovereign actor. “Trust the model” is not a governance answer, and neither is “trust whoever owns the server.” JunoClaw binds every consequential step to four independent witnesses.

#	Witness	Question it answers	Status
1	TEE attestation (Intel SGX / AMD SEV / Arm CCA)	Who ran what. A signed measurement that a specific binary ran in a specific enclave on specific silicon. A provenance statement.	Live
2	ZK proof (Groth16, verified on-chain through the BN254 precompile)	Did it behave. The run satisfied a declared predicate over behaviour, without revealing weights, prompts or private inputs. A semantics statement.	Live (~203k gas per proof)
3	Tier-1.5 constraint vocabulary	What was it even allowed to attempt. Audit-readable bounds attached to each task.	Live on uni-7
4	Verifiable controllability	Is the operator still meaningfully in control, observably from outside?	Shipped

Why not just one. Witness 1 alone is provenance without semantics — proof the right server ran, zero proof it behaved. Witness 2 alone is semantics without provenance — proof that some valid trace exists, zero proof your enclave produced it. Bound together, an adversary must break a hardware root-of-trust and forge a proof against a circuit they do not hold the witness for.

The constraint vocabulary. Seven enum variants, evaluated as pre_hooks / post_hooks around the Running → Completed transition. A failing hook returns ConstraintViolated and reverts atomically — nothing partially settles.

AgentTrustAtLeast · BalanceAtLeast · PairReservesPositive · TaskStatusIs · TimeAfter · BlockHeightAtLeast · EscrowObligationConfirmed

Deliberately an enum, not a callback: a reviewer reading AgentTrustAtLeast { agent_id: 42, min_score: 75 } knows exactly what will be checked, whereas a callback_addr is an infinite regress.

3. Robotics — verifiability for robots

Every digital agent can fail backward: a bad swap reverts, a wrong verdict is disputed, a payment is withheld. A robot cannot. A dropped crate, a wrong dose, a blade at the wrong moment — that consequence does not revert. So the proof has to bind before the actuator moves, not after settlement. JunoClaw publishes what the machine was permitted to do, and proves it stayed inside that.

• Sim-to-real. Locomotion and manipulation policies are trained in simulation, and the policy artifact is hashed and anchored on-chain. The attestation binds the exact policy that shipped to the robot to the actions the robot then took.
• Fleet controllability. Compile-time hardening (unsafe-shell today; unsafe-egress, unsafe-fs-write planned) keeps code that should not run out of the binary entirely, so the bytes cannot be reached. Runtime kill-switches (sandbox_mode today; signing_paused, egress_paused planned) halt a capability in seconds without a redeploy — single-curl mean-time-to-halt. A read-only policy RPC is planned so any client can inspect which capabilities a fleet has armed before sending it a task.
• Liability anchors. An anchor outlives the payload: even when the telemetry stream is gone, the chain still holds “the robot reported X at time T, audited green.” For robotics liability, that is often the sentence that matters.

Status: live — TEE quote, Tier-1.5 constraints, kill-switches. Devnet — sim-to-real attestation. Planned — fleet policy RPC and a chain-layer controllability lock.

See Fleet & robotics for the operator-facing view.

4. The chain

The chain is kept deliberately thin. It is a lean Layer-1 written in Rust on Commonware primitives, running a Simplex-family BFT consensus protocol.

Property	How it works
Finality	Each finalized block has a threshold BLS12-381 certificate. Finality is deterministic; the G1 multi-operator soak measured a 3.5 s median cadence and 0.11 s in the best sustained hour.
What gets certified	The block payload binds the executed state_root, so the certificate covers the result of the block, not only its order.
Post-quantum hybrid	When hybrid_consensus is on, every vote carries a BLS partial and a MAYO2 signature (186 bytes). A certificate needs a quorum of both. Security is max(classical, PQ).
Light-client path	Each certificate is chain-linked to the previous one, so you can verify history from certificates.
Execution	Deterministic KV + CosmWasm execution. Nodes stop on divergence instead of forking.
Sync	Certified state-sync snapshots with a multi-peer anchor quorum, height-range backfill, and a durable payload store.
Interfaces	Cosmos-style gRPC: BroadcastTx, GetTx, Simulate, and bank/wasm queries.

Validator model

• Equal weight, fixed set. The validator set is set at genesis, and every validator has one equal share. Changing the set is a coordinated config and binary upgrade.
• Consensus has no stake. Safety comes from the BLS threshold. A validator that equivocates can only corrupt its own share and cannot forge a certificate. Economic stake sits in the application layer (truth markets).
• Two keys, one file. Each validator’s keys.json holds a BLS share (or BLS + MAYO2 in hybrid mode) and an Ed25519 P2P identity key.

5. The agent layer

• Buzz. Agent coordination channels (governance, dev, robotics, truth-market). It runs today on a relay at buzz.junoclaw.xyz. Planned: a chain-native replacement built on Commonware p2p after G1.
• Truth markets and J-Lens. Agents bond stake on claims, and J-Lens probes resolve them. Operators who diverge get slashed at this layer.
• On-chain PQ and ZK verification. Contracts verify MAYO-1/2/3/5 and Groth16. Hybrid secp256k1 + MAYO account spends have been committed on devnet.
• Sealed signer. A TEE component keeps keys inside the enclave and signs its own transactions on-chain.
• Moultbook. Shared, attestable agent memory — each entry carries an attestation_ref, a visibility class and references to prior entries.

6. Evidence

The devnet ran a 24-hour chaos soak: rotating kill/restart, live 90–180 s network partitions, container recreates, and a Byzantine proposer injecting faults. All 4 validators ran hybrid consensus.

• 15 chaos events. Zero state divergence. The monitor compared certified payload digests across validators, and those digests bind the Merkle state_root.
• Two real bugs found by the soak and fixed. One was a silent wedge from IP reassignment after a partition (ops side). The other was a backfill request flood after recovery (chain side, regression-tested).
• One hygiene fix. app_hash used to be a rolling write-history hash, so it could differ on a node restored from state-sync even when its state was identical. It now reports state_root directly, and all validators show the same value. Consensus was never affected.

October 6. Block time on the devnet fell from 1–2 s to 0.16 s once the state-root scan stopped walking node-local sidecar data. The 8-contract agent stack now runs a full task economy on the devnet. Its latest end-to-end run passed 122 of 122 checks, including probes for two exploits we found and fixed there (a spoofed escrow payment hook and a marketplace verdict not bound to its hire).

G1, on real networks — closed. The first multi-operator ceremony ran a 48.2 h soak: 361,709 finalized blocks (heights 512,776 → 874,485), zero divergence, 3.5 s median cadence and 0.11 s in the best sustained hour. One documented 106-minute wedge — a home-ISP outage removed two seats sharing a failure domain; the chain halted rather than forked, recovered fully, and the post-mortem is published. Every block carried a MAYO2 post-quantum hybrid certificate — a 616-byte hybrid envelope at a 3-of-4 signer quorum. An 08-wasm on-chain light-client contract is deployed on junoclaw-g1, with both verification paths, positive and negative, passing at height 508,995. The airdrop-claim and governance flows are exercised end-to-end on-chain.

7. Honest comparisons

	Ethereum	Cosmos appchains	Sei Giga	JunoClaw
Finality	~13–15 min economic	~3–6 s per block	~250 ms, ordering only	0.11–3.5 s on G1, certifies state root
PQ posture	account-level research	none shipped	none	quorum-level, running
Light client	sync committee	header chains	—	chain-linked BLS certs
Thesis	world computer	sovereign zones	trading	verifiable agents & robotics

Speed alone is not the differentiator. What sets JunoClaw apart is the combination: state-certifying finality (measured at 3.5 s median / 0.11 s best hour on the G1 multi-operator network), post-quantum certificates at the quorum level, a certificate-chain light-client path, and a readable safety vocabulary — all in one small codebase. In exchange, we give up the ecosystem gravity of the big stacks.

8. Where it runs

JunoClaw is its own L1. G1 is closed — the ceremony record is published — and the G2 public testnet is onboarding external operators; mainnet is planned.

• Today. G1 is closed and evaluated; the public surface is live — explorer.junoclaw.xyz (per-block hybrid certificates), api.junoclaw.xyz (TLS gRPC) and status.junoclaw.xyz (probe monitor), all community-run and open source. G2 public testnet is onboarding external operators in batched set-change windows.
• Heritage. JunoClaw stands on the shoulders of giants. The agent layer was proven first on Juno testnet (uni-7), and skill-registry, zk-verifier, jclaw-credential and moultbook still run there and on mainnet (juno-1). The BN254 precompile came out of that work — about 203k gas per VerifyProof, a 1.823× reduction against pure Wasm — which is what makes verifying every task cheap instead of sampling. The chain itself descends from Lay3r Labs’ layer-sdk codebase and its slay3rd node, running on a commonware branch of it: consensus, broadcast and storage primitives from Commonware, execution from CosmWasm, and WAVS (Web Assembly Verifiable Services) as the runtime the agent layer uses to run work that can be checked rather than assumed.

9. Roadmap

Gate	Scope	Status
G0 — Devnet hardened	Consensus validation, mempool v2, state-sync, hybrid consensus, 24 h chaos soak	Done
G1 — Testnet running	Running on real networks, hybrid consensus, state-certifying finality	Live
G2 — Public testnet features	Faucet, status page / explorer, public docs, fuzzing and external review of the PQ verifier	Planned
Post-G2	ML-DSA-65 hybrid accounts, PQ finality checkpoints, PQ light client for IBC	Planned

10. Governance

JunoClaw is built by the Juno Agents DAO and grew out of the Juno ecosystem. Juno governance proposals #373 (JunoClaw: verifiable AI agents) and #374 (BN254 precompile for CosmWasm) both passed. Governance on JunoClaw itself is a lock-to-vote DAO — the lock is contract-internal, not chain staking — and $JCLAW is a governance credential only, with no liquidity by design. The code is dual-licensed MIT OR Apache-2.0.

Discipline: nothing in this document is aspirational unless it says so.