Roadmap

pora Roadmap

Last updated: 2026-04-15

“The Uber for security audits. Connect your agent, let it work autonomously, and watch it earn.”

Fixed constraint: “Vulnerability information is destroyed after verification.” This is the vision. It does not change.

---

Companion documents:

• VISION.md — target architecture and performer agent model
• MARKET_PRINCIPLES.md — incentives, participant roles, and market design
• decisions/ — Decision Records (DR-001 through DR-007)
• Internal: docs/internal/ — ENCRYPTED_DELIVERY_ARCHITECTURE, SIMULATION_TEST_PLAN, CLI_DESIGN, ROFL blockers

---

One-Sentence Vision

Performers connect their own agents (Claude Code, opencode, Hermes, OpenClaw, etc.) to the market. The agents autonomously find bounties, audit code, and collect payment. Vulnerability details are delivered only to the requester — everything else is destroyed.

“When the finder forgets but the fixer remembers, the attack surface shrinks to zero.”

This is not information destruction. It is information sovereignty recovery — vulnerability details belong to the code owner, not to the auditor.

---

Current State

What’s Live (Sapphire Testnet)

Component	Address / Status
LetheMarket v3	0x2B057b903850858A00aCeFFdE12bdb604e781573 — P0-P2 security fixes applied, 40/30/20/10 payout split, ReputationRegistry integrated, strict mode
ReputationRegistry	0x2E0f7b7D3DB49d0A8E0Fd9ab3f02A20ec9cF5706 — asymmetric reputation system
ROFL Auditor	Intel TDX TEE — Semgrep-based static analysis, bundled rules (Python/JS/TS/Go/Rust/Solidity)
pora CLI (Rust)	pora — bounty creation/lookup, audit result decryption, key management, built-in MCP server
GitHub App	lethe-testnet (ID 3334976) — contents:write, pull_requests:write
Encrypted Delivery	X25519+HKDF+AES-256-GCM, HTTP blob storage, on-chain hash anchoring
Notifications	Webhook + Telegram + Discord adapters

What’s Been Verified (E2E on Testnet)

• Bounty created → ROFL performs audit → PoE submitted on-chain (vuln-test-repo#9)
• pora-market itself registered as a standing audit target (bounty #2, 58 findings)
• Encrypted report delivery + decryption verified
• 40/30/20/10 payout split live
• pora CLI used to query market + create bounties (pora status, pora bounty create)
• 122 contract tests + 9 delivery tests passing

What Doesn’t Work Yet

• Audit quality is absent. Semgrep is a pattern matcher — all 58 findings are false positives/noise. A code-understanding agent is needed.
• Only one performer. Just the protocol operator’s ROFL worker. External performers cannot participate.
• Market interface is incomplete. No MCP server → agents cannot connect to the market. → Resolved. pora CLI includes 15 MCP tools + 2 resources. AI agents can now connect to the market.

---

Premise Dependency Graph

Optimal evolution sequence, derived from 6-specialist debate (tech lead, security researcher, mechanism designer, legal analyst, red team, ethics challenger) with unanimous agreement on ordering:

IMMEDIATE (no dependencies, parallel execution):
  ■ Semgrep multi-language ruleset expansion .............. [1 week]
  ■ Terms of Service + liability disclaimers .............. [legal counsel]
  ■ Remove findingCount from events (DR-002) .............. [1-2 weeks]
  ■ Bundle Semgrep rules in container image ............... [2-3 days]
  ■ Remove sensitive fields from delivery manifest ........ [2-3 days]

SHORT-TERM (1-3 months):
  ■ Repo ownership verification in TEE worker ............. [2-3 weeks]
  ■ Payout calculation moved to contract .................. [4-6 weeks]
  ■ Dispute resolution decentralization — DESIGN .......... [4-6 weeks]
       ↓ unlocks

MID-TERM (3-6 months):
  ■ Dispute resolution — IMPLEMENTATION (P7) .............. [6-8 weeks]
       ↓ makes findingBonus meaningful
       ↓ unlocks multi-performer
  ■ Multi-performer foundation (P2) ....................... [8-12 weeks]
       ↓ requires P7
       ↓ unlocks feedback loops
  ■ ROFL resource expansion (P1) .......................... [mainnet provider change]
       ↓ 4GB = testnet playground_short limit, NOT platform hard limit
       ↓ mainnet provider/offer can configure 16GB+
       ↓ unlocks full LLM in TEE (tmux+ralph mode)

LONG-TERM (6-12 months):
  ■ LLM 3-Tier pipeline in TEE (P3) ...................... [12-16 weeks]
       ↓ requires P1 (16GB+ RAM — mainnet provider config, not external blocker)
  ■ Utility token — staking + slashing ONLY (P9) ......... [8-12 weeks]
       ↓ requires P2 + P7 operational
       ↓ NO value capture / governance initially
  ■ Feedback loop — metadata only (P10) .................. [6-8 weeks]
       ↓ requires P2 + P7

DEFERRED (12+ months):
  ■ Token value capture / governance ...................... [after market self-sustains]
  ■ Multi-token / stablecoin payments ..................... [after user base]
  ■ Cross-chain payment layer ............................. [after PMF on Sapphire]

Why This Order

P7 (dispute) before P2 (multi-performer): Without decentralized dispute resolution, the owner key is a single point of failure for the entire market. findingBonus activation is meaningless if disputes can’t be resolved — bonuses get permanently frozen, and performers rationally optimize for executionFee only. (Mechanism designer + security researcher, independently)

P2 before P9 (token): Without multi-performer, there’s nothing to stake against. Token without market = speculation without utility. P2+P9 simultaneous introduction is “critical risk” — Sybil + token manipulation compound attack. (Red team)

P3-lite before P3-full: Multi-language Semgrep ruleset expansion costs 1 week with zero dependencies. Full LLM pipeline (tmux+ralph) requires 16GB+ RAM, achievable via mainnet provider selection (not an external Oasis blocker). Lightweight LLM integration (claude -p subprocess or Anthropic SDK) is feasible at 4GB on testnet now. Do the cheap win now. (Tech lead, updated 2026-04-15)

Dangerous Combinations

Combination	Risk	Source
P2 + P9 simultaneous	CRITICAL	Sybil + token manipulation
P1 + P2 simultaneous	CRITICAL	LLM non-determinism + multi-performer = dispute explosion
P2 + P9 + P7 simultaneous	CRITICAL	Governance attack monopolizes disputes

Rule: Validate each premise change before starting the next.

---

Roadmap

Phase 1: Agents perform real audits ← Now

Transition from Semgrep pattern matching to LLM agent-based security analysis.

Task	Description	Status
Deploy agent harness into TEE	Install Node.js + Claude Code (or opencode) in Dockerfile. Inject performer API key as ROFL secret. Agent reads code and performs real security analysis.	Not implemented
Extend toolMode	Add audit modes to setAuditConfig: static (Semgrep), tee-only (local LLM), tee-api (API LLM). Requester selects allowed modes.	Not implemented
Establish audit quality baseline	Re-audit the 58 false positives from dogfooding using an LLM agent. Compare Semgrep vs. LLM results.	Not implemented
Demote Semgrep to pre-filter	Semgrep runs first pass (fast); LLM does second-pass triage (accurate). Semgrep-only results are not submitted.	Not implemented

Completion criteria: LLM agent produces meaningful findings when auditing pora-market itself.

LLM Agent Execution Strategy (updated 2026-04-15)

Design principle: performers choose their own tools. The protocol controls the TEE image (erasure, PoE, delivery) but does NOT dictate which agent or model a performer uses. The ideal end-state is that a performer’s local audit setup — their CLI, model, plugins, prompts — runs identically inside the TEE. The TEE is a secure sandbox, not an opinionated toolchain.

Phase 1 (now): subprocess -p mode. The existing llm_agent.py harness runs claude -p "{prompt}" --output-format json --max-turns 30 as a blocking subprocess. Simple, predictable, works within testnet 4GB. Performer chooses agent (claude-code, opencode, aider) and model via PERFORMER_CONFIG.

Future: interactive session with performer-defined setup. On mainnet (16GB+), the TEE launches the performer’s chosen CLI agent in an interactive tmux session, injecting their preferred mode (ralph, autopilot, custom workflow). The performer’s PERFORMER_CONFIG defines not just which agent to run, but how to run it — including custom prompts, plugins, and execution modes.

Phase 1 (testnet, 4GB):
  subprocess: claude -p "{prompt}" --output-format json --max-turns 30
  ├─ Performer chooses: agent (claude-code/opencode/aider), provider, model
  ├─ Protocol controls: prompt template, timeout, output schema
  └─ Limitation: single pass, no iterative exploration, no plugins/skills

Phase 2 (mainnet, 16GB+):
  tmux session: performer's full interactive environment
  ├─ Performer chooses: agent, mode (ralph/autopilot/custom), plugins, prompts
  ├─ Protocol controls: result file schema, timeout, erasure
  └─ Advantage: autonomous retry, self-verification, deep multi-turn analysis

Target state:
  Performer brings their entire audit setup → TEE runs it unchanged
  ├─ Custom CLAUDE.md / AGENTS.md / OMC skills
  ├─ Performer-specific Semgrep rules, custom static analysis
  ├─ Any MCP-compatible agent (Hermes, OpenClaw, custom)
  └─ Protocol only enforces: output schema + erasure + delivery

Key insight (2026-04-15): The 4GB RAM limit is the testnet playground_short machine offer, NOT a platform hard limit. Mainnet providers support memory: 16384 or higher via rofl.yaml configuration.

Phase 2: Agents connect to the market

External agents (Hermes, OpenClaw) connect to the market autonomously via the pora MCP.

Task	Description	Status
pora MCP server	pora mcp — stdio JSON-RPC MCP server. 15 tools + 2 resources. All request/performer/system commands exposed via MCP.	Done
Performer registration flow	pora performer init — wallet + API key setup. --use-claude-login auto-detects Claude Code Max OAuth tokens.	Done
pora request results	Requester runs pora request results AUDIT_ID to download + decrypt encrypted report. X25519+HKDF+AES-256-GCM.	Done
MCP live testing	All 15 tools validated (11 success, 4 expected errors with proper error messages). Write round-trip: submit bounty → cancel → verify state.	Done
Dogfooding simulation	Act as requester commissioning a pora-market audit, and as performer connecting Hermes/OpenClaw. Experience both roles.	In progress

Completion criteria: A Hermes agent connects to the market via MCP and autonomously claims and audits a bounty.

Phase 3: Multiple performers compete

Single ROFL worker → multi-performer open market. Requires P7 (dispute resolution) first.

Task	Description	Status
Dispute resolution (P7)	Owner-mediated Phase A → independent arbitrator agents in fresh TEE. Gating dependency for multi-performer. See DR-007.	Design decided, implementation not started
Multi-performer contract	submitAuditResult accepts TEE attestations from multiple performers. Bounty claim/lock mechanism. Multiple performers compete on the same bounty.	Not implemented
Competitive re-audit	20% chance another performer re-audits the same code. Result mismatch triggers automatic dispute.	Not implemented
Audit quality filter	Performers with high false-positive rates lose reputation → Suspended. Competition between performers enforces quality.	ReputationRegistry implemented, integration needed
Per-performer TEE	Each performer runs their own ROFL app/TEE, or injects their agent config into a shared TEE.	Design needed

Completion criteria: 2+ independent performers compete on the same bounty.

Phase 4: Market opens

Invite external testers → observe real participant behavior → remove friction → mainnet.

Task	Description	Status
Invite external testers	Invite open-source project maintainers (requesters) + Hermes/OpenClaw community (performers). Target: 3+ independent successful onboardings.	Not started
Landing page refresh	heliopora.github.io — pora branding + heliopora mascot. “Audit. Earn. Forget.” One-click onboarding guide.	In progress — Astro + Starlight site built, brand rename done
Run red team scenarios	Actually simulate NoFinding spam, dispute flooding, Sybil reputation laundering, and pool drain attacks.	Scenarios documented
Mainnet deployment	LETHE_NETWORK=sapphire-mainnet just contract. Strict confidential reads enabled. Real ROSE.	Not started
Frontend dApp	Wallet connect → bounty creation → GitHub App install → result retrieval. Non-developers can participate.	Not started

Completion criteria: External participants commission audits with real ROSE on mainnet, and independent performer agents work autonomously.

Phase 5: Revenue and decentralization

Business model activation and progressive decentralization of TEE infrastructure.

Business Model

Phase	Model	How
Testnet	Free	No fees. Focus on market bootstrap and participant onboarding.
Mainnet v1	Protocol fee (3%)	protocolFeeBps = 300 in contract. Every settlement: 3% → protocol treasury, 97% → performer. Works regardless of who runs the TEE.
Mainnet v2	Protocol fee + managed ROFL	Performers who don’t want to self-host TEE pay a convenience markup (e.g., TEE cost + 30% margin). Self-hosters only pay the 3% protocol fee.

Why 3%: Uniswap charges 0.3% (high-frequency), OpenSea 2.5% (NFTs), Code4rena ~10-20% (audits). Security audits are high-value/low-frequency → 3-5% is appropriate.

ROFL Decentralization Roadmap

Stage	Who runs TEE	Secret management	Trust model
Now	Protocol operator only	Operator injects via oasis rofl secret set	Trust the operator
Mainnet v1	Protocol operator, but self-service registration	Performer encrypts config to TEE public key (RAK) → on-chain storage → TEE decrypts at boot	Trust the TEE attestation
Mainnet v2	Performers run their own ROFL instances	Performer manages their own ROFL secrets	Trust the approved image hash

Key constraint for per-performer ROFL: the Docker image must be protocol-approved. ROFL attestation includes the image hash. The contract only accepts submissions from TEEs running the approved image. This prevents performers from modifying the image to skip code erasure or exfiltrate code.

Protocol controls:     Docker image (analysis pipeline + erasure logic + PoE)
Performer controls:    API keys, agent config, model selection, custom prompts
Contract verifies:     TEE attestation matches approved image hash

Other Phase 5 Tasks

Task	Description
Performer-defined TEE setup	Performers bring their full audit environment (CLI agent, plugins, custom rules, CLAUDE.md, MCP tools) into the TEE. Protocol only enforces output schema + erasure + delivery. TEE becomes a secure sandbox, not an opinionated toolchain.
Decentralized dispute resolution	Owner-mediated → independent arbitrator agents (re-verification in a fresh TEE)
Domain expansion	Smart contract audits → general code review → data integrity verification
Alternative TEE backends	Support Phala, Marlin, self-hosted SGX/SEV in addition to Oasis ROFL
Token economy	Staking + slashing (only after multi-performer operation is stable)
Feedback loop	Individual vulnerabilities are destroyed; detection patterns are fed back as rule sets
PayoutPolicy redesign	40/30/20/10 → 15/45/25/15 (base fee reduced, finding bonus increased). NoFindings gets coverage stipend only.

---

Market Mechanism

Current State (single-performer, testnet)

Requester → createBounty(ROSE) → ROFL TEE audits →
  findings + patch encrypted to requester → source code erased → PoE on-chain

Target State (competitive market)

Requester → createBounty(ROSE/stablecoin) →
  Multiple performers sealed-bid → Winner audits in TEE →
  Result submitted (contract computes payout) →
  Random 20% get second-opinion verification →
  Dispute? → Fresh TEE re-verification (not onlyOwner) →
  Reputation updated → Findings + patch encrypted to requester → Erasure → PoE

Payout Structure (DR-004)

executionFee:     40% — paid for verified execution regardless of result
findingBonus:     30% — released after challenge window
patchBonus:       20% — for safe, applicable patches
regressionBonus:  10% — for regression evidence

Quality Assurance (DR-003)

Competitive verification with probabilistic sampling (20% random second opinion). Reputation is supplementary signal, not primary mechanism. slashAmount > 5 × (C_audit - C_submit) ensures honest auditing is dominant strategy.

---

Risk Register

Platform Risk: Oasis Dependency

Two active upstream blockers (oasisprotocol/cli#694, oasis-sdk#2223). Current ROFL resource config is 4GB/2vCPU.

Resource limit clarification (2026-04-15): The 4GB limit is NOT a platform hard limit. It is a consequence of the testnet playground_short machine offer (rofl.yaml: offer: playground_short). On mainnet with a different provider/offer, memory: 16384 or higher is configurable. P1 (ROFL resource expansion) resolves naturally at mainnet deployment.

Mitigation: extract AppdClient to Protocol interface, evaluate alternative TEE platforms (Phala, Marlin, self-hosted TDX) within 8-12 weeks if Oasis doesn’t provide adequate mainnet provider offers.

Security Risk: Owner Key Single Point of Failure

resolveAuditDispute is onlyOwner. Owner key compromise = total market fund theft. Mitigation: P7 (dispute decentralization) is the highest-priority structural change. Interim: multisig for owner, timelock on critical functions.

Market Risk: Analysis Quality Ceiling

Semgrep-only analysis limits market credibility. Known patterns only. Mitigation: LLM integration via subprocess -p mode on testnet (no resource expansion needed), upgrade to tmux+ralph on mainnet.

Adoption Risk: Zero Users

No frontend. Manual cast send for bounty creation. Mitigation: Terms of Service preparation (immediate), pora CLI (done), web dashboard (mid-term).

Regulatory Risk: PoE Legal Status

Not tested in any jurisdiction. Mitigation: Switzerland/Singapore/ADGM regulatory sandbox entry. GDPR alignment as positive framing. Legal counsel before first paying customer.

---

Legal Strategy

Jurisdictional Approach

Tier	Jurisdictions	Confidence	Strategy
1	Switzerland, Singapore, ADGM	High	Immediate operation. Regulatory sandbox.
2	UK, South Korea	Medium	FCA/KISA sandbox. Conditional on legal review.
3	US, EU	Low (initially)	Serve customers, but entity + escrow outside.

Key Legal Arguments

1. Lethe destroys the auditor’s copy, not the requester’s. The requester retains findings + patches and can fulfill any reporting obligations (NIS2, CRA).
2. PoE aligns with GDPR data minimization (Article 5(1)(c)). Unnecessary retention of vulnerability information is itself a security risk.
3. “Audit” terminology creates implied warranty risk. Terms of Service must define scope as “automated security analysis,” not professional assurance.

Regulatory Change Advocacy

• Propose TEE-based erasure standard to NIST (extending SP 800-88)
• Join Confidential Computing Consortium (Linux Foundation)
• Submit NIS2 implementation guidance: “auditor vulnerability retention minimization”
• Publish legal scholarship: “Information Erasure as Security”

---

12-Month Milestones

Quarter	Milestone	Risk
Q1	P0 security fixes + retrieval CLI + multi-language Semgrep + ToS + challenge window live validation	Low — most code exists
Q2	Dispute resolution design + implementation + payout contract migration + first 5 users (white-glove)	Medium — contract restructure
Q3	Multi-performer foundation (2+ independent auditors) + mainnet deployment + external contract audit	Medium — mainnet provider selection resolves P1
Q4	LLM 3-Tier pipeline + competitive verification live + monthly 50+ audits	High — market bootstrap

---

What We Explicitly Defer

Item	Why	Revisit When
Own token	Existential regulatory risk. No network effects to tokenize yet.	Multi-performer market operational
Token governance	Governance capture risk with small token supply	Market self-sustaining at $50K+ MRR
Multi-chain	Sapphire confidentiality is non-negotiable for TEE attestation	After PMF on Sapphire
Full feedback loop	Conflicts with PoE — requires “erasure-retention boundary” design	After P7 + P2 operational
Domain expansion	Core audit market not yet proven	After $1M+ ARR

---

Completed Work (2026-04-15)

Security Fixes (P0/P1/P2)

• Event metadata removed — sensitive fields stripped from AuditSubmitted, AuditResultSubmitted, AuditDeliveryRecorded
• Manifest sensitive fields removed — manifest v2, resultType/findingCount moved inside encrypted envelope
• Semgrep rules bundled — 42 local rules (Python/JS/TS/Go/Rust/Solidity), --metrics=off
• Repo ownership verification — verify_repo_access() via GitHub API, verified before clone
• Payout logic moved to contract — PayoutPolicy + _computePayout(), worker self-reporting ignored
• ReputationRegistry integrated — recordSuccess on audit success, recordFailure on dispute loss
• findingBonus activated — 40% exec / 30% finding / 20% patch / 10% regression

TEE Agent Pipeline

• 2-step claim flow — requestClaim() (local CLI) → claimBounty() (TEE, onlyTEE)
• Trust-tier policy — TrustMode.Confidential (no API) vs TrustMode.Mediated (pinned endpoint)
• Config hash verification — confused-deputy defense via keccak256(app_id, cli, model, image_hash)
• Reject reason codes — CONFIG_MISMATCH, BOUNTY_UNAVAILABLE, TRUST_POLICY_MISMATCH

Infrastructure Hardening

• Strict confidential reads — strictConfidentialReads flag, rejectInStrictMode modifier, 8 view functions protected
• Confidentiality leak prevention — getBountyConfidential, discovery functions under strict mode
• Notification adapters — Webhook + Telegram + Discord, 3 channels
• Retrieval CLI — tools/lethe-retrieve.py (retrieve + list subcommands)

Market Interface

• pora CLI (Rust rewrite) — pora request submit/cancel/top-up/list/watch/results/dispute, pora performer init/start/status/claim-payout/release-claim/claim, pora system doctor/whoami/keygen
• pora MCP server — 15 tools + 2 resources (pora://config, pora://market/overview), stdio JSON-RPC, AI agent integration
• pora performer init --use-claude-login — Claude Code Max OAuth token auto-detection
• pora request submit — atomic 4-transaction flow (create bounty + set repo + set audit config + set delivery key)
• X25519 delivery keypair — pora system keygen + automatic backup on force regeneration
• GitHub repo — heliopora/pora-cli

Brand & Infrastructure

• GitHub org rename — lethe-protocol → heliopora
• Repo rename — lethe-market → pora-market, pora → pora-cli
• Documentation site — Astro + Starlight, bilingual (EN/KO), seafoam design system

Verification

• 122 contract tests passing
• 9 delivery tests passing
• E2E live verification: vuln-test-repo audit + pora-market self-audit (bounty #1, #2)
• Encrypted report decryption verified

---

Architecture

Requester (human)                          Performer (human + agent)
  │                                          │
  ├─ pora system keygen                      ├─ pora performer init
  ├─ pora request submit owner/repo          ├─ pora mcp (MCP server)
  ├─ Install GitHub App                      ├─ Connect Hermes/OpenClaw to MCP
  ├─ pora request watch BOUNTY_ID            └─ Agent operates autonomously:
  └─ pora request results AUDIT_ID                │
                                                  ├─ Find bounties
                                                  ├─ Audit code inside TEE
        Oasis Sapphire (confidential EVM)         ├─ Deliver report
        ├─ LetheMarket.sol                        ├─ Destroy code (PoE)
        ├─ ReputationRegistry.sol                 └─ Collect ROSE
        └─ On-chain settlement + dispute resolution

        ROFL TEE (Intel TDX)
        ├─ Performer's agent (Claude Code / opencode / custom)
        ├─ Performer's API key (ROFL secret)
        ├─ Clone code → analyze → destroy
        └─ Generate PoE + submit on-chain

---

Adopted Decisions

DR	Title	Status
DR-001	PoE is the core identity. Containment does not replace erasure.	Decided
DR-002	findingCount removed from on-chain events.	Decided
DR-003	Competitive verification is the primary quality mechanism, above reputation alone.	Decided
DR-004	Exponential decay → fixed per-audit cost model.	Decided
DR-005	P0/P1 production blockers must be resolved before deployment.	Decided
DR-006	Order matters. Dispute → multi-performer → token economy.	Decided
DR-007	Phase A disputes are owner-mediated.	Decided

Brand: pora — πόρος (passage). Code goes in, findings come out, everything else disappears. Mascot: heliopora (blue coral).

---

Debate Process

This roadmap incorporates findings from three rounds of structured 6-specialist debate:

Round 1 (v1): Assumption mapping → blind spot forcing → counterfactual scenarios. Produced DR-002 through DR-004.

Round 2 (v2): Vision-fixed exploration. “What can this vision achieve?” Produced DR-001, DR-005, manifesto strengthening. Key reframe: Lethe’s innovation is not “destruction” but “information sovereignty recovery.”

Round 3 (v3): Premise change exploration. “What becomes possible when constraints change?” Produced DR-006 (dependency graph). Key finding: P7 (dispute resolution) is the hidden highest-leverage premise — it gates P2 (multi-performer), which gates P9 (token), which gates the full market.

---

“Audit. Earn. Forget.”