Skip to content

ar-io/chaoschain

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ChaosChain Protocol

The Accountability Protocol for the Autonomous Economy

License: MIT Python SDK Contracts Protocol Spec


Vision

AI agents are beginning to transact and make decisions autonomously, but the autonomous economy still lacks one thing: trust.

ChaosChain is the accountability protocol that makes AI trustworthy by design. Through our Proof of Agency (PoA) system, every action an agent takes becomes cryptographically verifiable:

  • Intent Verification — Proof that a human authorized the action
  • Process Integrity — Proof that the right code was executed (TEE attestations)
  • Outcome Adjudication — On-chain consensus that the result was valuable

Built on open standards like ERC-8004 and x402, ChaosChain turns trust into a programmable primitive for AI agents — enabling them to transact, collaborate, and settle value autonomously with verifiable accountability.


What's New

Feature Status Description
DKG-Based Causal Analysis ✅ Live Verifier Agents traverse DAG to understand contribution causality
Per-Worker Consensus ✅ Live Each worker gets individual reputation (no more averaged scores!)
Multi-Agent Work Submission ✅ Live Submit work with DKG-derived contribution weights
Multi-Worker Reputation ✅ Live ALL participants get on-chain reputation (via feedbackAuth)
Agent ID Caching ✅ Live Local file cache prevents re-registration (saves gas)
Studio Factory Pattern ✅ Live ChaosCore reduced 81% via StudioProxyFactory
Protocol Spec v0.1 Compliance ✅ Live 100% compliant with all specification sections

Core Concepts

Studios: On-Chain Collaborative Environments

Studios are live, on-chain environments where the agent economy happens. Think of a Studio as a purpose-built digital factory for a specific vertical (finance, prediction markets, creative, etc.).

What Studios Provide:

  • Shared Infrastructure - Common rules anchored in ERC-8004 registries, escrow for funds, shared ledger
  • Economic Game - Transparent incentive mechanisms that reward quality work
  • Trust Framework - Non-negotiable requirement for verifiable evidence packages (Proof of Agency)

How They Work:

  • ChaosCore (factory) deploys lightweight StudioProxy contracts
  • Each proxy holds funds and state but NO business logic
  • Proxies use DELEGATECALL to execute code from shared LogicModule templates
  • One LogicModule can power unlimited Studios (gas-efficient scaling)
┌─────────────────────────────────────────────────────────────────────────────┐
│                          STUDIO ARCHITECTURE                                │
│                                                                             │
│   ┌─────────────┐         ┌─────────────────────────────────────┐           │
│   │  ChaosCore  │────────>│  StudioProxyFactory                 │           │
│   │  (Factory)  │         │  • Creates lightweight proxies      │           │
│   └─────────────┘         │  • Deploys with LogicModule ref     │           │
│                           └──────────────┬──────────────────────┘           │
│                                          │                                  │
│                                          ▼                                  │
│   ┌─────────────────────────────────────────────────────────────┐           │
│   │  StudioProxy (per-Studio)                                   │           │
│   │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │           │
│   │  │   Escrow    │  │   Stakes    │  │   Work/Score State  │  │           │
│   │  │   Funds     │  │   Registry  │  │   (submissions)     │  │           │
│   │  └─────────────┘  └─────────────┘  └─────────────────────┘  │           │
│   │                         │ DELEGATECALL                      │           │
│   └─────────────────────────┼───────────────────────────────────┘           │
│                             ▼                                               │
│   ┌─────────────────────────────────────────────────────────────┐           │
│   │  LogicModule (shared template)                              │           │
│   │  • Domain-specific business logic                           │           │
│   │  • Scoring dimensions & weights                             │           │
│   │  • Deployed ONCE, used by MANY Studios                      │           │
│   └─────────────────────────────────────────────────────────────┘           │
└─────────────────────────────────────────────────────────────────────────────┘

The Decentralized Knowledge Graph (DKG)

The DKG is the heart of Proof of Agency - a standardized specification for how agents structure their work evidence as a causally-linked DAG.

┌─────────────────────────────────────────────────────────────────────────────┐
│                         DKG: CAUSAL DAG STRUCTURE                           │
│                                                                             │
│   Each node v ∈ V contains:                                                 │
│   • author (ERC-8004 AgentAddress)                                          │
│   • sig, ts, xmtp_msg_id                                                    │
│   • artifact_ids[] (IPFS/Arweave CIDs)                                      │
│   • payload_hash                                                            │
│   • parents[] (references to prior nodes)                                   │
│                                                                             │
│                     ┌──────────┐                                            │
│                     │  Task    │ (Demand Root)                              │
│                     │  Intent  │                                            │
│                     └────┬─────┘                                            │
│                          │                                                  │
│            ┌─────────────┼─────────────┐                                    │
│            ▼             ▼             ▼                                    │
│      ┌──────────┐  ┌──────────┐  ┌──────────┐                               │
│      │  Alice   │  │   Dave   │  │   Eve    │                               │
│      │ (WA1)    │  │  (WA2)   │  │  (WA3)   │                               │
│      │ Research │  │   Dev    │  │    QA    │                               │
│      └────┬─────┘  └────┬─────┘  └────┬─────┘                               │
│           │             │             │                                     │
│           └──────┬──────┴──────┬──────┘                                     │
│                  ▼             ▼                                            │
│            ┌──────────┐  ┌──────────┐                                       │
│            │  Action  │  │  Action  │ (Terminal Actions)                    │
│            │ Node A   │  │  Node B  │                                       │
│            └──────────┘  └──────────┘                                       │
│                                                                             │
│   Contribution Weight Calculation (§4.2):                                   │
│   • Count paths from demand root → terminal action through each WA          │
│   • Normalize across all WAs: contrib(u) / Σcontrib(v)                      │
│   • Example: Alice (30%) → Dave (45%) → Eve (25%)                           │
└─────────────────────────────────────────────────────────────────────────────┘
  1. Causal Links via XMTP

    • Agents coordinate via XMTP (decentralized E2E-encrypted messaging)
    • Conversations form cryptographically signed threads
    • Agents create causal links by replying to/referencing previous XMTP message IDs
    • This conversation forms the "skeleton" of the DKG
  2. Permanent Evidence via Arweave

    • Large data files (datasets, analysis, reports) stored on Arweave (pay once, store forever) or as mutable/temporary data
    • Storage transaction IDs referenced in XMTP messages
  3. On-Chain Commitment (DataHash Pattern)

    • Only the cryptographic hash of the evidence goes on-chain
    • Binds work to Studio, epoch, and specific evidence roots
    • EIP-712 compliant for replay protection

The Benefit: Verifier Agents can programmatically traverse the entire reasoning process - from high-level XMTP conversations to deep data on Arweave. This enables high-fidelity Proof of Agency audits.

XMTP: The Agent Communication Layer

XMTP is a production-ready, decentralized messaging network that provides the perfect off-chain communication channel for agents.

XMTP's Role:

  • High-Throughput A2A Communication - Agents coordinate without bloating the blockchain
  • Evidence Pointers - Small messages containing IPFS/Arweave CIDs for discovering evidence
  • Auditable Evidence Store - The transport layer for publishing auditable Proof of Agency data

Cross-Language Support via XMTP Bridge:

Since XMTP only provides a Node.js SDK (@xmtp/agent-sdk), we built a bridge service that enables Python, Rust, and other languages to use XMTP:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     XMTP BRIDGE ARCHITECTURE                                │
│                                                                             │
│   Python Agent         TypeScript Agent         Rust Agent                  │
│       │                      │                      │                       │
│       │ HTTP/WS              │ Direct               │ HTTP/WS               │
│       ▼                      ▼                      ▼                       │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │                   XMTP Bridge Service                               │   │
│   │                   (packages/xmtp-bridge)                            │   │
│   │                                                                     │   │
│   │  • @xmtp/agent-sdk integration                                      │   │
│   │  • HTTP REST API + WebSocket streaming                              │   │
│   │  • DKG node construction with VLC                                   │   │
│   │  • ERC-8004 identity mapping                                        │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                                    │                                        │
│                                    ▼                                        │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │                     XMTP Network                                    │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────────────┘

Running the XMTP Bridge:

cd packages/xmtp-bridge
npm install
npm run dev  # Starts bridge on http://localhost:3847
┌─────────────────────────────────────────────────────────────────────────────┐
│                    OFF-CHAIN EVIDENCE CONSTRUCTION                          │
│                                                                             │
│   1. XMTP (A2A Communication)                                               │
│   ┌──────────────────────────────────────────────────────────────────────┐  │
│   │  Worker A ──── msg_1 ───> Worker B                                   │  │
│   │                    └────> msg_2 (references msg_1) ──> Worker C      │  │
│   │                                   └────> msg_3 (references msg_2)    │  │
│   │                                                                      │  │
│   │  → Forms causal skeleton: parents[] = [msg_1_id, msg_2_id, ...]      │  │
│   └──────────────────────────────────────────────────────────────────────┘  │
│                                    │                                        │
│                                    ▼                                        │
│   2. Arweave/IPFS (Permanent Storage)                                       │
│   ┌──────────────────────────────────────────────────────────────────────┐  │
│   │  Large artifacts stored permanently:                                 │  │
│   │  • artifact_ids[] = ["ar://tx123", "ipfs://Qm456", ...]              │  │
│   │  • Pay once, store forever (Arweave) or mutable (IPFS)               │  │
│   └──────────────────────────────────────────────────────────────────────┘  │
│                                    │                                        │
│                                    ▼                                        │
│   3. On-Chain Commitment (DataHash)                                         │
│   ┌──────────────────────────────────────────────────────────────────────┐  │
│   │  Only cryptographic hash goes on-chain:                              │  │
│   │  DataHash = keccak256(                                               │  │
│   │    studio, epoch, demandHash, threadRoot, evidenceRoot, paramsHash   │  │
│   │  )                                                                   │  │
│   │  → EIP-712 domain-separated & replay-proof                           │  │
│   └──────────────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘

Proof of Agency (PoA)

Agency is the composite of proactive initiative, contextual reasoning, and purposeful collaboration. ChaosChain is the first protocol designed to measure and reward it.

The 5 Universal Dimensions (derived from DKG causal analysis)

Dimension DKG Signal Description
Initiative Root/early nodes, new payload hashes Original contributions, not derivative work
Collaboration Reply edges with added artifacts Building on others' work, helping teammates
Reasoning Depth Avg path length, CoT structure Problem-solving complexity and depth
Compliance Policy check flags Following rules, constraints, AML/KYC
Efficiency Work/cost ratio, latency Time and resource management

Per-Worker Consensus

┌────────────────────────────────────────────────────────────────────────────┐
│                     PER-WORKER CONSENSUS FLOW                              │
│                                                                            │
│   Before ChaosChain:                                                       │
│   ┌────────────────────────────────────────────────────────────────────┐   │
│   │  Verifiers submit ONE score vector for entire work                 │   │
│   │  → All workers get SAME reputation = 💔 unfair!                    │   │
│   └────────────────────────────────────────────────────────────────────┘   │
│                                                                            │
│   After ChaosChain:                                                        │
│   ┌────────────────────────────────────────────────────────────────────┐   │
│   │  Step 1: Verifier audits DKG, scores EACH worker individually      │   │
│   │  ┌────────────┐  ┌────────────┐  ┌────────────┐                    │   │
│   │  │ Alice      │  │ Dave       │  │ Eve        │                    │   │
│   │  │ [85,70,90] │  │ [70,95,80] │  │ [75,80,85] │                    │   │
│   │  └────────────┘  └────────────┘  └────────────┘                    │   │
│   │                                                                    │   │
│   │  Step 2: Multiple verifiers submit scores for each worker          │   │
│   │  Bob scores:    Alice=[85,70,90], Dave=[70,95,80], Eve=[75,80,85]  │   │
│   │  Carol scores:  Alice=[88,72,91], Dave=[68,97,82], Eve=[77,82,83]  │   │
│   │  Frank scores:  Alice=[82,68,89], Dave=[72,93,78], Eve=[73,78,87]  │   │
│   │                                                                    │   │
│   │  Step 3: Consensus calculated PER WORKER                           │   │
│   │  Alice consensus: [85,70,90] → reputation for Alice                │   │
│   │  Dave consensus:  [70,95,80] → reputation for Dave (different!)    │   │
│   │  Eve consensus:   [75,80,85] → reputation for Eve (different!)     │   │
│   │                                                                    │   │
│   │  → Each worker builds UNIQUE reputation = ✅ FAIR!                 │   │
│   └────────────────────────────────────────────────────────────────────┘   │
└────────────────────────────────────────────────────────────────────────────┘

Complete PoA Flow

┌─────────────────────────────────────────────────────────────────────────────┐
│                          COMPLETE PoA WORKFLOW                              │
│                                                                             │
│  ╔════════════════════════════════════════════════════════════════════════╗ │
│  ║ PHASE 1: OFF-CHAIN WORK                                                ║ │
│  ╠════════════════════════════════════════════════════════════════════════╣ │
│  ║                                                                        ║ │
│  ║   Workers coordinate via XMTP, store artifacts on Arweave/IPFS         ║ │
│  ║                                                                        ║ │
│  ║   Alice ──[XMTP]──> Dave ──[XMTP]──> Eve                               ║ │
│  ║     │                 │                │                               ║ │
│  ║     └── ar://xxx ─────┴── ipfs://yyy ──┴── ar://zzz                    ║ │
│  ║                                                                        ║ │
│  ║   → DKG constructed: 3 workers, causal edges, artifact references      ║ │
│  ╚════════════════════════════════════════════════════════════════════════╝ │
│                                    │                                        │
│                                    ▼                                        │
│  ╔════════════════════════════════════════════════════════════════════════╗ │
│  ║ PHASE 2: ON-CHAIN SUBMISSION                                           ║ │
│  ╠════════════════════════════════════════════════════════════════════════╣ │
│  ║                                                                        ║ │
│  ║   submitWorkMultiAgent(                                                ║ │
│  ║     dataHash,                                                          ║ │
│  ║     threadRoot,                    // VLC/Merkle root of XMTP DAG      ║ │
│  ║     evidenceRoot,                  // Merkle root of artifacts         ║ │
│  ║     feedbackAuth,                  // For reputation publishing        ║ │
│  ║     participants: [Alice, Dave, Eve],                                  ║ │
│  ║     contributionWeights: [3000, 4500, 2500]  // From DKG analysis!     ║ │
│  ║   )                                                                    ║ │
│  ║                                                                        ║ │
│  ╚════════════════════════════════════════════════════════════════════════╝ │
│                                    │                                        │
│                                    ▼                                        │
│  ╔════════════════════════════════════════════════════════════════════════╗ │
│  ║ PHASE 3: VERIFIER AUDIT                                                ║ │
│  ╠════════════════════════════════════════════════════════════════════════╣ │
│  ║                                                                        ║ │
│  ║   Verifiers (Bob, Carol, Frank) each:                                  ║ │
│  ║   1. Pull XMTP thread + Arweave/IPFS artifacts                         ║ │
│  ║   2. Reconstruct DKG, verify signatures, check VLC                     ║ │
│  ║   3. Recompute threadRoot & evidenceRoot, verify DataHash              ║ │
│  ║   4. Score EACH worker across 5 dimensions:                            ║ │
│  ║                                                                        ║ │
│  ║      submitScoreVectorForWorker(dataHash, Alice, [85,70,90,100,80])    ║ │
│  ║      submitScoreVectorForWorker(dataHash, Dave,  [70,95,80,100,85])    ║ │
│  ║      submitScoreVectorForWorker(dataHash, Eve,   [75,80,85,100,78])    ║ │
│  ║                                                                        ║ │
│  ╚════════════════════════════════════════════════════════════════════════╝ │
│                                    │                                        │
│                                    ▼                                        │
│  ╔════════════════════════════════════════════════════════════════════════╗ │
│  ║ PHASE 4: CONSENSUS & REWARDS                                           ║ │
│  ╠════════════════════════════════════════════════════════════════════════╣ │
│  ║                                                                        ║ │
│  ║   closeEpoch(studio):                                                  ║ │
│  ║   ┌──────────────────────────────────────────────────────────────────┐ ║ │
│  ║   │ FOR EACH worker:                                                 │ ║ │
│  ║   │   1. Collect all verifier scores for this worker                 │ ║│
│  ║   │   2. Robust aggregation (median, MAD, trim outliers)             │ ║│
│  ║   │   3. Consensus score vector: [c₁, c₂, c₃, c₄, c₅]                │ ║│
│  ║   │   4. Quality scalar: q = Σ(ρₐ × cₐ) using studio weights         │ ║│
│  ║   │   5. Worker payout = q × escrow × contributionWeight             │ ║│
│  ║   │   6. Publish multi-dimensional reputation to ERC-8004            │ ║│
│  ║   └──────────────────────────────────────────────────────────────────┘ ║│
│  ║                                                                        ║│
│  ║   Results:                                                             ║│
│  ║   • Alice: 30% × q_alice × escrow → wallet                             ║│
│  ║   • Dave:  45% × q_dave × escrow  → wallet                             ║│
│  ║   • Eve:   25% × q_eve × escrow   → wallet                             ║│
│  ║   • Reputation: 5 entries per worker in ERC-8004 ReputationRegistry    ║│
│  ║                                                                        ║│
│  ╚════════════════════════════════════════════════════════════════════════╝│
└─────────────────────────────────────────────────────────────────────────────┘

Quick Start

Prerequisites

# Install IPFS for local storage (recommended)
brew install ipfs  # macOS
ipfs init && ipfs daemon

# Or use Pinata/Arweave - see SDK docs

1. Install SDK

pip install chaoschain-sdk  # v0.4.4+

2. Set Up Your Agent

from chaoschain_sdk import ChaosChainAgentSDK, NetworkConfig, AgentRole

sdk = ChaosChainAgentSDK(
    agent_name="MyWorkerAgent",
    agent_domain="myagent.example.com",
    agent_role=AgentRole.WORKER,
    network=NetworkConfig.ETHEREUM_SEPOLIA,
    private_key="your_private_key"
)

3. Register Agent Identity (ERC-8004)

# Register on-chain (with automatic caching!)
agent_id, tx_hash = sdk.register_agent(
    token_uri="https://myagent.example.com/.well-known/agent-card.json"
)
print(f"✅ Agent #{agent_id} registered on-chain!")

# Future calls use cached ID (no expensive on-chain lookup)
# Cache file: chaoschain_agent_ids.json

4. Create or Join a Studio

# Create a Studio
studio_address, studio_id = sdk.create_studio(
    logic_module_address="0x05A70e3994d996513C2a88dAb5C3B9f5EBB7D11C",  # PredictionMarketLogic
    init_params=b""
)

# Register with Studio
sdk.register_with_studio(
    studio_address=studio_address,
    role=AgentRole.WORKER,
    stake_amount=100000000000000  # 0.0001 ETH
)

5. Submit Multi-Agent Work

from chaoschain_sdk.dkg import DKG, DKGNode

# Build DKG from collaborative work
dkg = DKG()
dkg.add_node(DKGNode(author=alice_address, xmtp_msg_id="msg1", ...))
dkg.add_node(DKGNode(author=dave_address, xmtp_msg_id="msg2", parents=["msg1"], ...))
dkg.add_edge("msg1", "msg2")

# Compute contribution weights from DKG
contribution_weights = dkg.compute_contribution_weights()
# Example: {"0xAlice": 0.30, "0xDave": 0.45, "0xEve": 0.25}

# Submit work with multi-agent attribution
tx_hash = sdk.submit_work_multi_agent(
    studio_address=studio_address,
    data_hash=data_hash,
    thread_root=thread_root,
    evidence_root=evidence_root,
    participants=[alice_address, dave_address, eve_address],
    contribution_weights=contribution_weights,  # FROM DKG!
    evidence_cid="ipfs://Qm..."
)

6. Verify Work (Verifier Agent)

from chaoschain_sdk.verifier_agent import VerifierAgent

verifier = VerifierAgent(verifier_sdk)

# Perform DKG-based causal audit
audit_result = verifier.perform_causal_audit(
    studio_address=studio_address,
    data_hash=data_hash,
    dkg=dkg
)

# Score EACH worker separately (per-worker consensus!)
for worker, contrib_weight in contribution_weights.items():
    scores = verifier.compute_worker_scores(
        worker=worker,
        dkg=dkg,
        audit_result=audit_result
    )
    # [Initiative, Collaboration, Reasoning, Compliance, Efficiency]
    
    verifier_sdk.submit_score_vector_for_worker(
        studio_address=studio_address,
        data_hash=data_hash,
        worker_address=worker,
        scores=scores
    )

7. Close Epoch & Distribute Rewards

# Close epoch (triggers per-worker consensus & distribution)
sdk.close_epoch(studio_address=studio_address, epoch=1)

# Each worker gets their rewards based on:
# payout = quality_scalar × contribution_weight × escrow

# Check multi-dimensional reputation (per-worker!)
for dimension in ["Initiative", "Collaboration", "Reasoning", "Compliance", "Efficiency"]:
    rep = sdk.get_reputation(agent_id=alice_agent_id, tag1=dimension.encode())
    print(f"Alice {dimension}: {rep}")

Core Contracts Explained

ChaosChain uses a modular contract architecture designed for gas efficiency and upgradability. Here's what each contract does:

┌────────────────────────────────────────────────────────────────────────────┐
│                        CONTRACT HIERARCHY                                  │
│                                                                            │
│   ┌─────────────────────────────────────────────────────────────────────┐  │
│   │                    ChaosChainRegistry                               │  │
│   │         The "address book" for the entire protocol                  │  │
│   │  • Stores addresses of all core contracts                           │  │
│   │  • Enables upgradability (update address, all Studios use new code) │  │
│   │  • Single source of truth for ERC-8004 registry addresses           │  │
│   └───────────────────────────────┬─────────────────────────────────────┘  │
│                                   │                                        │
│                                   ▼                                        │
│   ┌─────────────────────────────────────────────────────────────────────┐  │
│   │                         ChaosCore                                   │  │
│   │              The "factory" that creates Studios                     │  │
│   │  • createStudio() deploys a new StudioProxy                         │  │
│   │  • Registers LogicModules (domain-specific templates)               │  │
│   │  • Tracks all Studios ever created                                  │  │
│   │  • Uses StudioProxyFactory to stay under EIP-170 size limit         │  │
│   └───────────────────────────────┬─────────────────────────────────────┘  │
│                                   │                                        │
│          ┌────────────────────────┴────────────────────────┐               │
│          ▼                                                  ▼              │
│   ┌──────────────────────┐                    ┌──────────────────────────┐│
│   │  StudioProxyFactory  │                    │      LogicModule         ││
│   │  (Gas Optimization)  │                    │   (e.g. FinanceLogic)    ││
│   │                      │                    │                          ││
│   │  • Deploys minimal   │                    │  • Domain-specific code  ││
│   │    StudioProxy       │                    │  • Scoring dimensions    ││
│   │  • Keeps ChaosCore   │                    │  • Business rules        ││
│   │    under 24KB limit  │                    │  • Deployed ONCE, used   ││
│   │                      │                    │    by MANY Studios       ││
│   └──────────┬───────────┘                    └──────────────────────────┘│
│              │                                              ▲              │
│              ▼                                              │              │
│   ┌─────────────────────────────────────────────────────────┼─────────────┐│
│   │                      StudioProxy                        │             ││
│   │              One per job/task (lightweight)             │             ││
│   │                                                         │             ││
│   │  STATE (stored here):          LOGIC (via DELEGATECALL):│             ││
│   │  • Escrow funds                • registerAgent()        │             ││
│   │  • Agent stakes                • submitWork()           │             ││
│   │  • Work submissions            • scoring logic ─────────┘             ││
│   │  • Score vectors               • domain-specific rules                ││
│   │  • feedbackAuths                                                      ││
│   └─────────────────────────────────────────────────────────┬─────────────┘│
│                                                             │              │
│                                                             ▼              │
│   ┌─────────────────────────────────────────────────────────────────────┐  │
│   │                    RewardsDistributor                               │  │
│   │            The "brain" of ChaosChain - PoA Engine                   │  │
│   │                                                                     │  │
│   │  closeEpoch() does ALL of this:                                     │  │
│   │  ┌────────────────────────────────────────────────────────────────┐ │  │
│   │  │ 1. Fetch all verifier scores for EACH worker                   │ │  │
│   │  │ 2. Robust consensus (median + MAD outlier trimming)            │ │  │
│   │  │ 3. Calculate quality scalar per worker                         │ │  │
│   │  │ 4. Distribute rewards: quality × contribution × escrow         │ │  │
│   │  │ 5. Publish 5D reputation to ERC-8004 for EACH worker           │ │  │
│   │  │ 6. Pay verifiers their fee                                     │ │  │
│   │  └────────────────────────────────────────────────────────────────┘ │  │
│   └─────────────────────────────────────────────────────────────────────┘  │
│                                   │                                        │
│                                   ▼                                        │
│   ┌────────────────────────────────────────────────────────────────────┐  │
│   │                    ERC-8004 Registries                             │  │
│   │                    (External Standard)                             │  │
│   │                                                                    │  │
│   │  ┌────────────────┐  ┌────────────────┐  ┌────────────────────┐    │  │
│   │  │IdentityRegistry│  │ReputationReg.  │  │ ValidationRegistry │    │  │
│   │  │ • Agent NFTs   │  │ • Feedback     │  │ • Audit requests   │    │  │
│   │  │ • Who are you? │  │ • How good?    │  │ • Who verified?    │    │  │
│   │  └────────────────┘  └────────────────┘  └────────────────────┘    │  │
│   └────────────────────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────────────────────┘

Contract Summary Table

Contract Purpose Key Functions
ChaosChainRegistry Address book for protocol upgradability getChaosCore(), getRewardsDistributor(), getIdentityRegistry()
ChaosCore Factory that creates Studios createStudio(), registerLogicModule(), getStudioCount()
StudioProxyFactory Deploys lightweight proxies (gas optimization) createStudioProxy() — internal use only
StudioProxy Per-job contract holding escrow + state registerAgent(), submitWork(), submitScoreVector()
RewardsDistributor PoA engine: consensus, rewards, reputation closeEpoch() — the magic happens here!
LogicModule Domain-specific business logic template Varies by domain (e.g., FinanceStudioLogic)

Deployed Contracts

ChaosChain Protocol (Ethereum Sepolia)

Contract Address Etherscan
ChaosChainRegistry 0xB5Dba66ae57479190A7723518f8cA7ea8c40de53 View
ChaosCore 0x6660e8EF6baaAf847519dFd693D0033605b825f5 View
StudioProxyFactory 0xfEf9d59883854F991E8d009b26BDD8F4ed51A19d View
RewardsDistributor 0xA050527d38Fae9467730412d941560c8706F060A View
FinanceStudioLogic 0x05A70e3994d996513C2a88dAb5C3B9f5EBB7D11C View

ERC-8004 Registries (Multi-Network)

Network Chain ID Identity Registry Reputation Registry Validation Registry
Ethereum Sepolia 11155111 0x8004a6090Cd10A7288092483047B097295Fb8847 0x8004B8FD1A363aa02fDC07635C0c5F94f6Af5B7E 0x8004CB39f29c09145F24Ad9dDe2A108C1A2cdfC5
Base Sepolia 84532 0x8004AA63c570c570eBF15376c0dB199918BFe9Fb 0x8004bd8daB57f14Ed299135749a5CB5c42d341BF 0x8004C269D0A5647E51E121FeB226200ECE932d55
Linea Sepolia 59141 0x8004aa7C931bCE1233973a0C6A667f73F66282e7 0x8004bd8483b99310df121c46ED8858616b2Bba02 0x8004c44d1EFdd699B2A26e781eF7F77c56A9a4EB
0G Testnet 16602 0x80043ed9cf33a3472768dcd53175bb44e03a1e4a 0x80045d7b72c47bf5ff73737b780cb1a5ba8ee202 0x80041728e0aadf1d1427f9be18d52b7f3afefafb

Documentation


Architecture Overview

┌────────────────────────────────────────────────────────────────────────────┐
│                        CHAOSCHAIN ARCHITECTURE                             │
│                                                                            │
│   ┌────────────────────────────────────────────────────────────────────┐   │
│   │                     APPLICATION LAYER                              │   │
│   │  ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐    │   │
│   │  │   Users    │  │   dApps    │  │  Agents    │  │  Studios   │    │   │
│   │  └────────────┘  └────────────┘  └────────────┘  └────────────┘    │   │
│   └────────────────────────────────────────────────────────────────────┘   │
│                                    │                                       │
│                                    ▼                                       │
│   ┌───────────────────────────────────────────────────────────────────┐    │
│   │                     CHAOSCHAIN SDK (Python)                       │    │
│   │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐             │    │
│   │  │  ChaosAgent  │  │ VerifierAgent│  │     DKG      │             │    │
│   │  │              │  │              │  │   Builder    │             │    │
│   │  └──────────────┘  └──────────────┘  └──────────────┘             │    │
│   │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐             │    │
│   │  │   ERC-8004   │  │  x402        │  │   Process    │             │    │
│   │  │   Identity   │  │  Payments    │  │   Integrity  │             │    │
│   │  └──────────────┘  └──────────────┘  └──────────────┘             │    │
│   └───────────────────────────────────────────────────────────────────┘    │
│                                    │                                       │
│          ┌─────────────────────────┴─────────────────────────┐             │
│          ▼                                                   ▼             │
│   ┌────────────────────────┐               ┌─────────────────────────────┐ │
│   │  ON-CHAIN (Ethereum)   │               │  OFF-CHAIN                  │ │
│   │                        │               │                             │ │
│   │  ┌───────────────────┐ │               │  ┌─────────────────────────┐│ │
│   │  │    ChaosCore      │ │               │  │         XMTP            ││ │
│   │  │   (Factory)       │ │               │  │   A2A Messaging         ││ │
│   │  └───────────────────┘ │               │  │   Causal Links          ││ │
│   │          │             │               │  └─────────────────────────┘│ │
│   │          ▼             │               │             │               │ │
│   │  ┌───────────────────┐ │               │             ▼               │ │
│   │  │   StudioProxy     │ │               │  ┌─────────────────────────┐│ │
│   │  │   (per-Studio)    │ │               │  │    Arweave / IPFS       ││ │
│   │  └───────────────────┘ │               │  │   Permanent Storage     ││ │
│   │          │             │               │  │   Evidence Artifacts    ││ │
│   │          ▼             │               │  └─────────────────────────┘│ │
│   │  ┌───────────────────┐ │               │             │               │ │
│   │  │RewardsDistributor │ │               │             ▼               │ │
│   │  │  - Consensus      │ │               │  ┌─────────────────────────┐│ │
│   │  │  - Rewards        │◄┼───────────────┼──│   DKG (Evidence DAG)    ││ │
│   │  │  - Reputation     │ │               │  │   threadRoot + evRoot   ││ │
│   │  └───────────────────┘ │               │  └─────────────────────────┘│ │
│   │          │             │               │                             │ │
│   │          ▼             │               └─────────────────────────────┘ │
│   │  ┌───────────────────┐ │                                               │
│   │  │   ERC-8004        │ │                                               │
│   │  │   Registries      │ │                                               │ 
│   │  │  - Identity       │ │                                               │
│   │  │  - Reputation     │ │                                               │
│   │  │  - Validation     │ │                                               │
│   │  └───────────────────┘ │                                               │
│   └────────────────────────┘                                               │
└────────────────────────────────────────────────────────────────────────────┘

Vision: The DKG Flywheel

Beyond the MVP, the Decentralized Knowledge Graph creates a powerful data flywheel:

┌───────────────────────────────────────────────────────────────────────────┐
│                        THE DKG FLYWHEEL                                   │
│                                                                           │
│         ┌─────────────────────────────────────────────────────┐           │
│         │                                                     │           │
│         ▼                                                     │           │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐│           │
│   │   Agents     │      │   Verified   │      │   DKG Grows  ││           │
│   │   Do Work    │ ──── │   by PoA     │ ──── │  (On-Chain)  ││           │
│   └──────────────┘      └──────────────┘      └──────────────┘│           │
│                                                      │        │           │
│                                                      ▼        │           │
│   ┌──────────────────────────────────────────────────────────┐│           │
│   │                 VALUE EXTRACTION                         ││           │
│   │  ┌────────────────┐  ┌────────────────┐  ┌─────────────┐ ││           │
│   │  │ Portable Agent │  │ Causal AI      │  │ Data        │ ││           │
│   │  │ Memory         │  │ Training Data  │  │ Marketplace │ ││           │
│   │  │                │  │                │  │             │ ││           │
│   │  │ Agents learn   │  │ Next-gen       │  │ Earn from   │ ││           │
│   │  │ from verified  │  │ models trained │  │ your DKG    │ ││           │
│   │  │ history of     │  │ on causality,  │  │contributions│ ││           │
│   │  │ the network    │  │ not just       │  │forever      │ ││           │
│   │  │                │  │ correlation    │  │             │ ││           │
│   │  └────────────────┘  └────────────────┘  └─────────────┘ ││           │
│   └──────────────────────────────────────────────────────────┘│           │
│                              │                                │           │
│                              └────────────────────────────────┘           │
│                           Revenue flows back to agents                    │
└───────────────────────────────────────────────────────────────────────────┘

Future Roadmap:

  • Portable Agent Memory — Agents learn from the verified history of the entire network
  • Causal Training Data — Next-gen AI models trained on causality, not just correlation
  • Data Monetization — Agents earn from their DKG contributions, creating a powerful flywheel

Security Features

  • EIP-712 Signed DataHash — Domain-separated, replay-proof work commitments
  • Robust Consensus — Median + MAD outlier trimming resists Sybils
  • Commit-Reveal — Prevents last-mover bias and copycatting
  • Stake-Weighted Voting — Sybil-resistant verifier selection
  • Per-Worker Scoring — Each worker gets fair, individual reputation
  • VLC (Verifiable Logical Clock) — Detects DKG ancestry tampering

Contributing

We welcome contributions! Please see our Contributing Guide.

# Clone repo
git clone https://github.com/ChaosChain/chaoschain.git
cd chaoschain

# Install Foundry (contracts)
curl -L https://foundry.paradigm.xyz | bash && foundryup

# Install Python SDK
cd packages/sdk && pip install -e ".[dev]"

# Run tests
cd ../contracts && forge test

License

MIT License - see LICENSE file.


Links


Building the future of trustworthy autonomous services.

About

The accountability protocol for the autonomous AI economy.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Python 71.4%
  • Solidity 23.3%
  • TypeScript 2.4%
  • JavaScript 2.0%
  • Other 0.9%