Skip to content

ROADMAP.md

Latest commit

 

History

History
155 lines (104 loc) · 7.83 KB

ROADMAP.md

File metadata and controls

155 lines (104 loc) · 7.83 KB
Raw

ValuePacket — OSS Gap Analysis & Integration Roadmap

Current State (v0.2.2)

ValuePacket ships: Service Registry, Payment Channels (EIP-712 unidirectional), Spending Policies, SDK (@valuepacket/sdk), CLI (@valuepacket/cli), ElizaOS + G.A.M.E adapters, Ponder indexer, and 3 live services (price feed, contract audit, MEV scanner). Deployed on Base Sepolia with USDC. 119 tests, CI pipeline.

The protocol handles request-response micropayments flawlessly. The gaps below represent the leap from one-shot transactions to ongoing commercial relationships.

Gap 1: Subscriptions (Recurring Agent Payments)

Best OSS Solution Identified

Build natively — no external dependency needed. ValuePacket already has extendChannel() and refundChannel() in PaymentChannel.sol. Subscriptions are a thin SDK layer on top of what exists.

Why not use existing OSS:

  • EIP-1337: Stagnant since 2018, implementation deleted. Dead.
  • Superfluid: MIT license, battle-tested on 10+ chains. But designed for per-second streaming, not monthly billing. Would require abandoning ValuePacket's off-chain-first channel model and wrapping ERC-20s into Super Tokens. Architecturally misaligned.
  • Sablier Flow: Purpose-built for subscriptions with open-ended streams. Best off-the-shelf fit. But BUSL-1.1 license (restricts forking for production), and uses debt-based accounting instead of ValuePacket's fully-collateralized model.
  • Zodiac Reality: Governance execution tool, not a payment primitive. Gas-prohibitive.

Integration Path

A SubscriptionSession class (~200 lines of TypeScript) in the SDK:

  1. Wraps openChannel() with recurring parameters (amount, interval, max cycles)
  2. Monitors channel expiry via block polling
  3. Auto-calls extendChannel() with fresh deposit each period
  4. Payer pre-authorizes via EIP-712 signature for recurring extends
  5. Zero new contracts required

Effort Estimate

  • Engineering: 2 days
  • Risk: Low
  • Dependency: None (pure SDK)

Verdict

GO. Build it this week. The existing contracts already support it.

Gap 2: Cross-Chain Settlement

Best OSS Solution Identified

Axelar GMP — Apache 2.0 license, arbitrary message passing, supports Solana natively, one-line call: callContract("solana", destProgramId, payload).

Runners-up:

  • LayerZero V2: MIT license, OApp pattern, configurable security model (DVN selection). Equivalent effort, slightly more flexible.
  • Wormhole: Apache 2.0, most battle-tested, Solana-first. Higher operational overhead (VAA fetching).
  • Hyperlane: Apache 2.0, permissionless ISMs, philosophically ideal for ValuePacket. Solana support is emerging but not production-grade.

Integration Path

A small adapter contract on the destination chain:

  1. Receive relayer message containing (payer, channelId, spent, eip712Signature)
  2. Verify EIP-712 signature against pre-stored source-chain domain separator
  3. Release escrowed USDC on destination chain

~150 lines of Solidity + a matching program on Solana. Any of the five messaging protocols handles the relay.

Effort Estimate

  • Engineering: 2-3 weeks (Solana program adds time)
  • Risk: Medium (cross-chain is inherently complex)
  • Dependency: External relayer infrastructure (self-hostable, not SaaS-locked)

Verdict

GO if demand exists. Blocked on actual cross-chain agent use case. Don't build it until someone asks for it.

Gap 3: Reputation (Portable Agent Trust)

Best OSS Solution Identified

EAS (Ethereum Attestation Service) — MIT license, 9.5M+ attestations on 15+ chains (Ethereum, Base, Optimism, Arbitrum, Polygon, zkSync, Scroll, etc.). Agent-first CLI (easctl). Explicitly designed for reputation systems.

Key properties:

  • Any agent can register a schema and attest about any other agent
  • Attestations are portable across all EAS-deployed chains
  • Supports off-chain attestations (zero gas) verifiable on demand
  • Transitive trust SDK for computing reputation across attestation graphs

Integration Path

  1. Register a schema: ValuePacketServiceRating(vendor address, requester address, score uint8, transactionId bytes32)
  2. After each transaction, the requesting agent signs an EAS attestation about service quality
  3. Reputation is readable by any protocol on any EAS chain
  4. SDK: npm i @ethereum-attestation-service/eas-sdk

Effort Estimate

  • Engineering: 3-5 days (register schema + attest/verify wrapper)
  • Risk: Low
  • Dependency: EAS contracts (deployed on Base already)

Verdict

GO. Highest-impact, lowest-effort gap. Ship this week.

Gap 4: Escrow & Outcome-Conditional Payments

Best OSS Solution Identified

This is the genuinely hard gap. No solution can automatically determine "was this service delivered correctly?" for subjective services. Every approach delegates to human judgment. The question is how efficiently.

Three-layer approach:

Layer Technology When Latency Cost
Trusted reviewers 2-of-3 multisig witness attestation Repeated transactions, known parties Minutes Gas only
Optimistic oracle UMA OOv3 95% of transactions (happy path) 2-24 hours Bond-based
Arbitration Kleros Court High-value disputes ($500+) 5-14 days ~0.03 ETH

The honest truth about low-value disputes: For $2 contract audits or $0.10 MEV scans, no decentralized oracle works economically — the cost of dispute exceeds the transaction value. The only viable approach is reputation systems (Gap 3) that make disputes unnecessary. UMA works for $500+ services; Kleros for appeals.

Alternative: witness attestation model — simplest to implement, fastest to resolve. A set of trusted verifiers (could be other reputable agents with high EAS scores) sign off on results. This is fundamentally what freelance platforms do.

Integration Path

  • For high-value: UMA OOv3 integration. Assert truth claim, challenge period, DVM escalation.
  • For low-value: Build a ReviewedEscrow contract that releases funds when 2-of-3 trusted reviewers attest via EAS that work was completed correctly.

Effort Estimate

  • Engineering: 1-2 weeks (witness escrow) + 2-3 weeks (UMA integration)
  • Risk: Medium-High (UMA is complex, witness model requires bootstrapping reviewers)
  • Dependency: UMA contracts (deployed), EAS (Gap 3 prerequisite)

Verdict

CONDITIONAL. Build witness escrow after Gap 3 (reputation) ships — reputation of reviewers IS the trust model. Defer UMA/Kleros until high-value agent services exist ($500+ transactions).

Prioritization Matrix

Gap Adoption Unlock (1-10) Effort OSS-Native Production OSS Available Priority
Reputation (EAS) 9 S (3-5 days) Yes Yes (EAS on Base) #1 — ship this week
Subscriptions (native) 8 S (2 days) Yes N/A (no dependency needed) #2 — ship this week
Cross-Chain (Axelar) 4 L (2-3 weeks) Yes Yes (Axelar GMP) #3 — wait for demand
Escrow/Disputes (UMA+Kleros) 6 M-L (3-5 weeks) Partial Partial (UMA works for $500+) #4 — depends on Gap 3

Execution Order

  1. Week 1: Ship reputation (EAS attestations) + subscriptions (native SDK layer)
  2. Week 2: Ship witness escrow on top of EAS reputation
  3. Later: Cross-chain settlement when someone asks for it
  4. Later: UMA/Kleros integration when high-value agent services exist

Bottom Line

Three of four gaps are solvable with OSS integrations this week. The fourth (escrow for subjective quality) is the AI alignment problem in miniature — it's as hard as "did the agent do a good job?" which is unsolved in general. But for specific, structured services with clear acceptance criteria, witness attestation + reputation makes it practical today.

Last updated: 2026-07-16. Built on research into 20+ open source protocols.