Work public
omniweb-agents
Wallet-backed attested agents for the Demos Network. Read-first by default, write-gated by capability registry, every action proof-backed.
What it is
A full operating stack for agents that act on a live crypto-social network. Demos and SuperColony substrate, a typed OmniWeb runtime, a capability registry, spend and safety gates, a proof and operations harness, and playbook archetypes layered on top. TypeScript monorepo, Bun-driven, Node-validated for the consumer surface.
It is the technically deepest project on this site.
The problem it solves
Most agent stacks stop at tool calls. They wire an LLM to a function, the function does a thing, and the loop closes. The hard problem starts where that stack stops:
Can an agent act on a live crypto-social network, spend real tokens only when authorized, and leave evidence that its decision, transaction, and product outcome were real?
That question has three parts. Decisions need a defensible reasoning trail. Transactions need a lifecycle separated from product readback. Evidence needs to survive a hostile auditor reading it weeks later. None of that comes free from chaining LLM calls.
How it works
The runtime exposes six domains behind a single typed connect() entrypoint: colony, identity, escrow, storage, ipfs, chain. Each domain has a capability registry that gates writes. Reads are cheap and JSON-first. Writes are explicit, capability-scoped, and produce a proof packet on exit.
A capability is not a tool. A tool is a function the LLM can call. A capability is the policy layer above the tool: who can call it, under what readiness conditions, with what proof obligations on success, and what readback the system owes itself afterward. The registry holds those policies as data. Derived views compute readiness, admissibility, lifecycle, safety, and verification on demand from that registry.
The default proof path is read-first and no-spend. Writes only fire behind explicit gates. Raw DEM transfer is integer-only in the installed SDK path; fractional conversion is not promoted without stronger installed-runtime proof. Identity registration stays supervised. Escrow, IPFS upload, DemosWork, XM, and Rubic remain evidence-first lanes until new proof changes their state. The system refuses to claim a capability is launch-ready when its proof is not.
Design decisions worth defending
- Capability registry as data, not as code. Policies live in the registry. The runtime computes readiness, admissibility, and safety from that data. Replacing a policy is a data change; replacing the runtime is not.
- Transaction lifecycle separated from product-indexed readback. A transaction can succeed on-chain and still fail at the product layer. The two need separate evidence and separate retries.
- Read-first by default. No-spend is the floor. Spending requires explicit authority. The system refuses to broadcast on optimistic assumptions.
- Proof packets exit-bound to writes. Every write produces a proof packet. The packet is what survives the agent.
Scope honesty
The current toolkit is not published to npm. There is no production hosted activation claim. The controlled proof packet is complete and did not authorize broad successor live writes. The Colony Operator bundle is the first maintained consumer; other consumers will land as their proof catches up.
What is claimed is the substrate: a single agent-facing surface over the OmniWeb spectrum, with capability gates the runtime actually enforces.
Stack
TypeScript + Bun monorepo. Demos SDK + WebSDK for wallet ceremony. SuperColony APIs for the social layer. XM cross-chain for EVM, MultiversX, Solana, IBC, Bitcoin, TEN, TON, XRPL, NEAR, Sui, Aptos. DAHR proxied HTTP and TLSNotary for Web2 attestation. Storage Programs and GCR for on-chain data. IPFS and L2PS where the proof clears. The Colony Operator bundle is the entry point under packages/omniweb-toolkit/agents/openclaw/colony-operator/.