Skip to content

ROADMAP.md

Latest commit

 

History

History
148 lines (124 loc) · 7.69 KB

ROADMAP.md

File metadata and controls

148 lines (124 loc) · 7.69 KB
Raw

VerBnb Roadmap

Last updated: 2026-07-18 · Live on the GenLayer Studio Network · ver-bnb.vercel.app

This roadmap tracks where VerBnb is and where it is going. Shipped phases are facts; future phases are intent and may be reordered as GenLayer's own roadmap (mainnet, validator set growth) firms up.

Status legend: ✅ Shipped · 🔨 In progress · 🔜 Planned · 💡 Exploring

Phase 1 — Core Dispute Resolution ✅

The foundation: AI-consensus arbitration for four marketplace dispute categories, settled on-chain.

  • ✅ Registry pattern — single entry point (verBnb_registry) routing to four specialist contracts, discovered at runtime via get_contract_for_category
  • ✅ RENTAL — listing_accuracy_judge (Airbnb-style listing accuracy)
  • ✅ PRODUCT — not_as_described (marketplace arbitration)
  • ✅ SOURCING — ethical_sourcing (brand claim validation)
  • ✅ DELIVERY — delivery_adjudicator (courier proof adjudication)
  • ✅ Leader/validator consensus via gl.vm.run_nondet with ±15 refund-percentage agreement bands (exact verdict match for DELIVERY)
  • ✅ Evidence pinned to IPFS via Pinata
  • ✅ Frontend dispute flows with live consensus tracker (Submitted → Proposing → Committing → Revealing → Finalized)

Phase 2 — Trust & Platform Layer ✅

Standalone tracker contracts orchestrated off-chain at dispute lifecycle points.

  • ✅ Appeal Manager — 7-day appeal window measured from the decision being appealed, escalation under a strictly tighter agreement bar, capped at 3 rounds per dispute
  • ✅ On-chain appeal consensus in all four specialist judges — each judge re-runs gl.vm.run_nondet over its own stored evidence with a stricter agreement bar per round (resolve_appeal), and the appeal manager finalizes by reading that outcome cross-contract (finalize_appeal_from_state); the verdict is never supplied off-chain
  • ✅ Round-bound appeal outcomes — every outcome is stored under its consensus round, rounds are strictly monotonic, the appeal manager only accepts the outcome recorded for the appeal's exact round, and the legacy owner-written finalize_appeal path is removed; validated reproducibly in tests/sim/ (glsim, no network or LLM keys) and surfaced in the UI as a full round history with per-round escalation
  • ✅ Registry-bound judges — the appeal manager's registry address is a constructor argument with no setter; create_appeal resolves the specialist (and the original verdict, refund, parties and appeal window) through registry.get_dispute, and finalize_appeal_from_state takes only an appeal id. There is no argument anywhere in the appeal lifecycle through which an owner could name a contract, so finalization can never consume an arbitrary contract's response — and, having no discretion left, needs no owner gate
  • ⏳ Two-party disputes on-chain — only the dispute's submitter is recorded, so only they can appeal. Recording the counterparty at raise_dispute time would give them authenticated standing too (today an unauthenticated caller cannot be allowed to consume a dispute's capped appeal rounds)
  • ✅ Pinned evidence — every judge stores the page TEXT its original consensus round judged, and resolve_appeal re-runs the LLM over that stored text with no second web fetch. An appeal can no longer be steered by editing the live page, nor blocked by deleting it (which previously made resolve_appeal revert forever)
  • ⏳ Appellant evidence in the re-run — create_appeal records the appellant's evidence URL for audit, but resolve_appeal deliberately re-adjudicates over the judge's own stored evidence. Feeding new evidence into the re-run needs the judge to read it back from the appeal manager, so it stays authenticated
  • ✅ Reputation Tracker — per-user reputation from dispute history, derived: record_verdict(dispute_id) / record_appeal_outcome(appeal_id) read who filed and how it went from the judge and the appeal manager. Validator agreement is not observable from a contract, so it is kept as a labelled operator attestation and excluded from the credibility score
  • ✅ Fraud Detector — pattern detection across disputes, derived: check_and_flag_patterns(dispute_id) takes the address, verdict direction and (critically, for the sliding rapid-cycling window) the timestamp from chain state, so a pattern can be neither hidden nor manufactured
  • ✅ Analytics Tracker — platform statistics powering /analytics, derived: category, verdict, refund, appeal-round count and resolution time all come from the registry, the bound judge and the appeal manager
  • ✅ Idempotent tracker writes — every record is counted once per dispute or appeal, so re-running the orchestrator cannot inflate reputation or fabricate a fraud flag
  • ✅ Frontend surfaces: /appeals, /leaderboard, /analytics, /explorer, /activity, /user, /validator, /simulator, in-app /docs

Phase 3 — Curation (Product Suggester) 🔨

Turning the same validator consensus into a curation feed: validators independently LLM-extract top product picks from trusted review sites and publish the agreed list on-chain.

  • ✅ product_suggester contract — owner-managed trusted-domain allowlist, refresh_suggestions(topic, source_url), ≥50 % product-name overlap consensus
  • ✅ /suggestions page reading via /api/suggestions
  • ✅ Home-page suggestions surface (HomeSuggestions) — first curated topic's top picks on the home page; hidden entirely until validators publish a non-empty topic
  • 🔜 Scheduled auto-refresh so topics never go stale (cron-driven refresh_suggestions runs)
  • 🔜 Broader trusted-domain allowlist beyond the Wirecutter/RTINGS defaults
  • 💡 Multi-source aggregation per topic (consensus across several review sites, not one page per refresh)

Phase 4 — Real Settlement 🔜

Today verdicts are recorded on-chain but money does not move. This phase makes the refund percentage enforceable.

  • 🔜 Escrow contract — buyer funds held at purchase, released per the verdict's refund split
  • 🔜 Appeal-bonded escalation — appellants stake a bond, slashed on frivolous appeals
  • 🔜 Reputation-weighted dispute limits (fraud-flagged users face stricter evidence requirements)
  • 💡 Partial-settlement plans (structured refund schedules for high-value disputes)

Phase 5 — Production Hardening 🔜

  • 🔜 Notifications for dispute state changes (email/webhook when a verdict or appeal lands)
  • 🔜 Contract security review ahead of any value-bearing deployment
  • 🔜 Load/latency benchmarking of the consensus tracker under many concurrent disputes
  • 🔜 GenLayer mainnet deployment when the network launches (currently GenLayer Studio Network, chain ID 61999)

Phase 6 — Open Platform 💡

  • 💡 Marketplace SDK / public API so third-party platforms can plug disputes into VerBnb instead of running support desks
  • 💡 Governance of the trusted-domain allowlist and consensus parameters (community-curated rather than owner-managed)
  • 💡 Additional dispute categories (services, freelance work, event tickets)
  • 💡 Cross-chain verdict attestation so settlements can execute on other chains

Non-goals

  • Custodial funds on testnet — no real value flows until Phase 4 + audit.
  • Human moderators — the whole point is AI-validator consensus; we won't add a manual override path.
  • Hardcoded contract addresses in the UI — the frontend resolves specialists through the registry and env overrides only.

Contributions toward any 🔜/💡 item are welcome — see Contributing.