What I Built
I built Opacus.
It’s live in production: an AI agent orchestration platform with on-chain escrow-gated task execution, a Base ↔ 0G bridge, 0G Storage and 0G Compute integration, and something I built on top of all of that — what I believe is the first H3 geospatial agent routing standard deployed on 0G.
I spent months building on the 0G stack before writing this post. I want to explain exactly what I built, why I built it, and why 0G isn’t just one option for this architecture — it’s the only one that makes sense.
The Real Problem
AI agents can actually do things in 2026. They write code, call APIs, process data, delegate work to other agents.
But none of them have an economic layer.
When Agent A wants to delegate a task to Agent B:
- A cannot verify that B can actually do the job
- A cannot make payment conditional on the outcome
- If B fails, A has no on-chain mechanism to recover funds
- If there’s a dispute, there’s no neutral arbiter
Centralized platforms “solve” this by putting everything on their own servers — trust belongs to the company. If an agent loses a million dollars, accountability is ambiguous and transparency is zero.
That’s an unacceptable architecture. Especially for institutional use cases — finance, research, healthcare — an untrusted agent economy doesn’t work.
What I Built and Which 0G Primitives Made It Possible
1. Escrow V2 — Deployed 0G
Mainnet Escrow Contract: 0x884B4296727A89Ef703A89ccCCed5d59F7884B08 (deployed: 2026-04-21)
Before an agent starts a task, the budget is locked in USDC to this contract. When the task completes and proof is submitted, funds are released. If the task fails, the USDC is returned. No human intervention required at any step. Any external observer can verify every state transition on the block explorer.
The reason this runs on 0G is straightforward: bridging cost stays on Base, real agent work runs on 0G’s low-gas environment.
2. Base ↔ 0G Bridge
Bidirectional bridge for USDC and ETH is live. Users deposit USDC on Base, it enters escrow on 0G for agent task funding. After task completion, funds can be withdrawn back to Base. 1% protocol fee.
3. 0G Storage Integration
Every agent registration, task result, and reputation update is written to 0G Storage via https://evmrpc.0g.ai. The location of data and proof that it hasn’t been tampered with is verifiable by anyone. Nothing requires trusting a centralized database.
4. 0G Compute Integration
AI inference requests are routed to 0G Compute — 300 chat calls, 500 embedding calls, and 200 storage uploads per day on the sponsor tier. Instead of routing everything through OpenRouter or Groq, inference runs on 0G’s own compute layer. Better unit economics, real data sovereignty.
H3 Geospatial Routing — The Standard I Wrote for 0G
This is Opacus’s most original contribution to the ecosystem.
The 0G network originally had no concept of where an agent lives. Agent addresses were flat and unordered — no topology, no proximity. Finding the lowest-latency node for a time-sensitive swap required brute-force polling. There was no mechanism for regional infrastructure providers to earn a verifiable share of the activity flowing through their zone.
I fixed all three.
H3 Resolution 5 — ~253 km² Cells
Uber’s open-source H3 geospatial grid. I derive a deterministic H3 cell from every wallet address. Cell assignment is fully decentralized — no governance key, no upgrade proxy, just a deterministic hash:
var _H3_RESOLUTION = 5; // city/metro level, ~253 km²
function _assignH3FromWallet(addr) {
var seed = addr.toLowerCase();
var h1 = _fnv1a(seed).toString(16).padStart(8, '0');
var h2 = _fnv1a(seed + 'h3').toString(16).padStart(8, '0');
return '85' + h1 + h2.slice(0, 6) + 'ff';
}
Any wallet can derive its own cell. Any node can verify it.
Spatial DID — Geographic Identity on 0G
Every registered agent carries a Spatial DID in this format:
did:opacus:v1:h3:<h3Index>:<wallet>
Example: did:opacus:v1:h3:85264523fffffff:0xabc... → an agent in the Singapore region. This DID is written to 0G, is immutable, and is permanently tied to the wallet address.
Execution vs. Interactive Anchor Modes
Routing runs in two modes:
- Execution anchor: for swap, bridge, MEV, and orderbook operations — routes to the chain’s physical infrastructure H3 cell. For 0G that’s
85264523fffffff(Singapore). Task is forwarded to the nearest QUIC Nitro node to that cell. - Interactive anchor: for chat, analytics, and storage — routes to the nearest node relative to the agent’s own geographic cell.
// 0G infrastructure H3 anchor
'0g': { h3: '85264523fffffff', label: '0G Network (Singapore)', region: 'ap-southeast' }
QUIC Nitro Relay Network
Six globally distributed relay nodes, each mapped to a 0G RPC cluster:
| Node | Region | Infrastructure |
|---|---|---|
| sg-sin-1.0g.network:4433 | Singapore | 0G RPC + Jaine DEX |
| de-fra-1.0g.network:4433 | Frankfurt | Ethereum infra |
| us-iad-1.0g.network:4433 | Virginia | Base / Coinbase |
| jp-nrt-1.0g.network:4433 | Tokyo | Binance infrastructure |
| in-bom-1.0g.network:4433 | Mumbai | South Asia |
| ie-dub-1.0g.network:4433 | Dublin | Coinbase EU |
Router scoring formula: latencyScore = w1·rtt_rpc_p95 + w2·rtt_data_p95 + w3·queue_depth with mode-tunable weights across fast, cheap, balanced, and safe profiles.
Discovery and Routing API
POST /api/v1/discovery/agents — H3 proximity + capability + policy filtering
POST /api/v1/router/execute — full pipeline: shortlist → scoring → route → fallback
GET /api/v1/routing/anchors — chain and exchange infrastructure anchor map
GET /api/v1/zones/heatmap — zone revenue tracking at the H3 cell level
POST /api/v1/zones/record-fee — on-chain micro-fee recording per zone transaction
GET /api/v1/capabilities — standard capability registry
GET /.well-known/opacus.json — v1.2 discovery document, live
iNFT Land Economy — Geographic Ownership on 0G
This is the newest piece and the most interesting.
H3 cells can be claimed as iNFT land parcels. A wallet calls POST /v1/land/register with a target H3 cell index and an inft_token_id. Ownership is recorded in the on-chain land registry, permanently associated with that H3 cell.
What happens after that?
Every agent transaction routed through that cell automatically triggers a micro-fee:
var _INFT_LAND_MICRO_FEE_BPS = 25; // 0.25% to the land owner
Revenue distribution is hardcoded in contract constants — no governance can modify it:
| Recipient | Share |
|---|---|
| Protocol | 20% |
| Zone Royalty Pool | 80% |
| -> Land Owner | 70% of zone pool |
| -> Node Sponsor | 30% of zone pool |
Latency Pinback Challenge
Claiming land requires proof of physical proximity. The flow is GET /v1/challenge → POST /v1/register — the system issues a ping challenge, and the claimant must demonstrate they are physically close to the Nitro node serving that H3 cell. Paper land grabs are not possible.
Query endpoints
GET /api/v1/land/:h3Index — owner, token ID, micro_fee_bps for any cell
GET /api/v1/land/fees — accumulated fee records by cell
V1 Token System — Scope Control Without Governance
I didn’t issue an on-chain token. Revenue flows in USDC through Escrow V2.
But every API operation runs through a scope-based JWT system:
| Token | Scopes | TTL |
|---|---|---|
obr_agent_ |
nitro.execute, h3.routing, 0g.compute |
24 hours |
obr_data_ |
0g.upload, 0g.download, bridge.execute |
24 hours |
obr_pay_ |
pay.escrow_lock, pay.gas_subsidy |
1 hour |
Bootstrap flow: POST /v1/bootstrap/challenge → POST /v1/bootstrap/register — latency proof + wallet signature. Returns three tokens with access to 30+ V1 API endpoints. Backward-compatible with legacy opak_ API keys.
OpenClaw MCP — 0G Agent Operations from Any IDE
A full Model Context Protocol server exposing 40+ tools directly to Claude, Cursor, and Continue. Developers never need to leave their IDE:
kineti_h3_register_agent → register agent on H3 grid, receive Spatial DID
kineti_h3_discover_agents → proximity-ranked agent discovery
kineti_bridge_base_to_og → bridge USDC from Base to 0G
kineti_execute_cross_chain_intent → cross-chain task execution
kineti_buy_data_from_agent → purchase data from another agent
kineti_estimate_task_cost → cost estimate before committing
You type: “Launch a Discovery Agent with 0.5 USDC” — escrow locks, agent is found via H3 proximity routing, task executes. One prompt.
Kinetic Score — On-Chain Agent Reputation
Every agent that operates on Opacus accumulates a Kinetic Score stored on 0G Storage. Derived from:
- Task completion rate
- Escrow dispute rate
- Average response latency
- 0G Compute job quality
Agents with low scores cannot be assigned high-budget tasks. The ecosystem audits itself — no moderation team required.
Why 0G — The Honest Answer
I looked at other chains and AI infra stacks. Most are either pure infrastructure with no real applications on top, or applications that use a wallet for sign-in and nothing else.
0G is the only stack where the component list — Storage, Compute, Chain, Agent ID, TEE — maps directly and cleanly onto problems I already had in production before I ever thought about crypto:
- Storage → permanent, verifiable storage for agent state, task proofs, and reputation records
- Compute → AI inference without centralized provider dependency
- Chain → low-gas escrow and micro-fee transactions at scale
- TEE → confidentiality guarantees for institutional use cases that no centralized provider can match
- H3 + Agent ID → geographic identity and proximity-based routing that the ecosystem was missing entirely
Current State
- opacus.xyz — production, live
- Agentboard V1 — control plane live at opacus.xyz/agentboard
- opacus-sdk — public npm package,
npm install opacus-sdk - OpenClaw MCP — active, installable from opacus.xyz
- 0G Aristotle Mainnet — two escrow contracts deployed
/.well-known/opacus.json— v1.2 discovery document, live
Discord: opacus_xyz
Twitter: @OpacusAI
Docs: opacus.xyz/docs
SDK: npmjs.com/package/opacus-sdk