Conclave

Conclave is an open protocol where a swarm of adversarial agents manages user capital through onchain deliberation. Five distinct LLM personas — each with its own ENS identity (<persona>.conclavee.eth) — independently propose strategies, challenge each other’s reasoning, score feasibility in a deterministic way, and ultimately vote on the best path forward.

An arbiter then bundles the result into a signed verdict. This verdict is executed by a vault on Base Sepolia, which replays the decision against Uniswap with built-in replay protection — only then does USDC actually move.

All communication between agents happens over Gensyn AXL, a peer-to-peer mesh built on Yggdrasil — no central broker, no message bus. Inference runs on 0G Compute, while the entire debate — proposals, critiques, votes, and signatures — is permanently stored on 0G Storage as a content-addressed record.

KeeperHub initiates each round and triggers execution, so once funds are deposited, the system runs fully autonomously without human intervention.

Architecture

At its core, Conclave runs five Node.js agent processes — one per persona — each connected to its own AXL node bridge.

The orchestrator handles all setup. It generates ed25519 keypairs, writes them as PKCS#8 PEM files for AXL, spins up five AXL nodes (with node-1 as the seed and nodes 2–5 peering into it), waits for the network’s spanning tree to converge, and only then launches the agents.

Agents communicate through AXL’s local HTTP bridge:

• POST /send (with X-Destination-Peer-Id) to send messages
• GET /recv (long-polling) to receive them

Every message is wrapped in a SignedEnvelope:

{ message, signature, signerEnsName, signerPeerId }

Messages are signed with ed25519 at the source and verified on receipt. If anything doesn’t check out, it’s dropped silently — no retries, no noise.

---

Round Protocol (Deterministic FSM)

Each round follows a strict, deterministic flow:

ROUND_START (broadcast by orchestrator)
  │
  ├─ rsi      ──▶ PROPOSAL
  ├─ macro    ──▶ PROPOSAL
  └─ meanrev  ──▶ PROPOSAL
                                          ┐
  value (critic) ──▶ CRITIQUE             ├─ parallel phase
  quant          ──▶ QUANT_REPORT         │   (deterministic, no LLM)
                                          ┘
  all non-arbiter agents ──▶ VOTE
  arbiter ──▶ VERDICT (signed + broadcast + stored)

Arbiter selection is deterministic: hash the roundId against the participant list. No randomness, no coordinator, no race conditions. In the MVP, all non-quant agents rotate evenly; VRF-based selection is planned later.

---

Sponsor Integrations (What Each Piece Actually Does)

Gensyn AXL A thin client (axl-client.ts) wraps AXL’s /topology, /send, and /recv endpoints. The orchestrator waits for full peer visibility before starting — this avoids the notorious 502 /send errors caused by premature messaging. Every message in the system travels exclusively over AXL. Delivery is validated via a cross-node smoke test script.

0G Compute Each persona runs inference through 0G Compute. Prompts are intentionally minimal and opinionated (e.g., “you are a momentum trader; oversold = buy”), and all outputs must conform to strict JSON schemas. The runtime extracts JSON even from messy responses, then clamps and validates every field. If inference fails, the agent falls back to a deterministic stub so the round never stalls.

0G Storage Before broadcasting a verdict, the arbiter serializes the full round — proposals, critiques, votes, context — and uploads it via the 0G SDK. The resulting Merkle root becomes the transcript ID and is embedded in the verdict.

If storage fails (which can happen on testnet), the system falls back to a local, content-addressed file. Same structure, same hash — just not globally anchored.

ENS Each persona owns a subname like <persona>.conclavee.eth. The AXL peer ID (ed25519 public key) is stored as a text record (axl.peerId).

This isn’t cosmetic — ENS acts as the routing layer. To message an agent, you resolve its ENS name to a peer ID, then send via AXL. Human-readable names mapped directly to P2P identities.

Uniswap Trading API The keeper fetches quotes and swap calldata, then passes that calldata directly into the vault. The vault executes it blindly via a low-level call.

For reliability on Base Sepolia (where liquidity can be thin), there’s also a fallback path using Uniswap V3’s SwapRouter02. From the vault’s perspective, it’s the same: just calldata in, execution out.

KeeperHub Two jobs:

• Trigger a new round on a schedule
• Execute a verdict once it’s available

Execution is idempotent thanks to onchain replay protection, so duplicate triggers are harmless.

---

The Vault Contract

ConclaveVault.sol (on Base) is intentionally minimal. It exposes just three functions:

• deposit(amount) Pulls USDC into the vault

• executeVerdict(...) Verifies the verdict hasn’t been used before, approves USDC, and executes the provided Uniswap calldata Emits an event with the result

• setExecutor(addr, enabled) Lets the owner authorize KeeperHub

The vault doesn’t know about agents, ENS, or storage. It only enforces two things:

1. This verdict hasn’t been executed before
2. The calldata is executed as-is

Everything else lives off-chain.

What Was Actually Hard

• AXL convergence — messaging before the network stabilized caused flaky failures. Fixed by explicitly waiting for topology readiness and running a warm-up round.
• Uniswap Trading API — designed for EOAs, not contracts. Required reverse-engineering request formats from examples.
• 0G Storage reliability — intermittent timeouts made a fallback path necessary.
• Architecture honesty — resisting the temptation to claim “fully on 0G” and instead documenting the real multi-chain setup.