Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Architecture

System Split: Two Planes

The system is divided into two independent planes that coordinate through shared references (commit hashes, bounty IDs, identity keys).

P2P Code Plane

All source code lives in Radicle — a peer-to-peer Git protocol with no central server.

  • Local Git preserved — contributors use standard git commands; Radicle handles replication
  • Content-addressed commits — every commit is identified by its hash, making references tamper-proof
  • Repo replication — peers replicate repositories across the network; no single point of failure
  • Contribution packages — patches/commits are bundled with metadata and signed by the contributor's identity
  • No platform lock-in — code is always accessible via the P2P network, independent of any service

onchain Coordination Plane

All coordination — bounties, permissions, acceptance, payouts — happens onchain (Ethereum).

Bounties & Escrow

  • Maintainers create bounties with Ethereum escrow via BountyEscrow
  • Bounties specify scope, reward amount, acceptance policy, and validation requirements
  • Funds are held in escrow until acceptance conditions are met

Project Registry

  • ProjectRegistry links onchain project IDs to Radicle repo identifiers (append-only, immutable)
  • Stores per-project owner, maintainer list, and bounty-creation allowlist
  • canCreateBounty(projectId, caller) and canManageBounty(projectId, caller) are called by BountyEscrow at runtime

Bounties & Payout

  • BountyEscrow holds ETH in escrow for each task
  • Only project owners, maintainers, and allowlisted wallets can call createBounty
  • Anyone can fund a bounty via fundBounty
  • acceptContribution pays the contributor directly; cancelBounty refunds the creator
  • Every payout is traceable: contribution → acceptance transaction → contributor wallet

Indexer

  • Ponder listens to ProjectRegistry and BountyEscrow events on Sepolia
  • Writes directly into the Prisma-managed Postgres tables (project, project_member, bounty)
  • Idempotent handlers — safe to re-index from any block
  • No separate Ponder schema tables; a single database is shared with the API

Identity & Reputation (Planned)

  • Portable onchain identity for every contributor (human or agent) via ERC-8004
  • Reputation scores based on accepted work, disputes, and history
  • Validation attestations from independent agents (tests passed, build reproduced, audit checks)
  • See ERC-8004 Agent Layer for the roadmap