Delivery status
Panorama roadmap
Granular view of what is live, in flight, queued, and exploratory — including the UGC ad network track.
This page is the authoritative roadmap surface for the Panorama Protocol public program. Product pages explain the "why"; here we track discrete deliverables, how we label maturity, and what sits on the horizon. For the live display and video surfaces, see Demo and UGC Ad Network. For HTTP and repository context, see the API page (which includes a shorter roadmap summary that always defers here).
How this differs from /docs
The API page roadmap section stays high-level for developers scanning endpoints and repos. This ledger is the detailed source: every row is a checkable deliverable with status and evidence notes. When the two diverge, treat this page as current.
How we label delivery
Every row in the ledger below uses one of these statuses. They are intentionally finer than a simple "done / not done" so readers can tell production exposure from local-only or research work.
| Status | What it means |
|---|---|
| Live Now | Shipped to production on panoramaprotocol.com (or the primary public deployment); no feature flag required for the described behavior. |
| Implemented | Built in the current codebase or sibling repos and usable in local/staging stacks; may rely on env flags, sample data, or operator wiring before it is considered production-hardened. |
| In progress | Actively being extended or hardened this cycle: APIs, UX, or infra are partially complete and the direction is committed. |
| Upcoming | Sequenced work with a clear product intent and rough ordering; scope and timelines can still move as dependencies land. |
| Research | Exploratory: technical or market validation, prototypes, or standards alignment before we commit to a delivery milestone. |
Master delivery ledger
Rows are grouped by workstream. Within a group, order is roughly closest to user-visible impact first, then deeper systems— not a strict priority ranking across groups.
| Status | Deliverable | Detail & evidence |
|---|---|---|
| Public surfaces & developer experience Marketing site, API documentation surface, and trust-oriented demos that explain how ingestion, proof, and settlement connect. | ||
| Live Now | Unified SiteNav across marketing, marketplace, and SaaS header | Single navigation model (About dropdown, API, Roadmap, marketplace entry points) so orientation does not change when users cross app boundaries. |
| Live Now | API page (/docs) as canonical HTTP + repo map | Endpoint table (health, auth nonce/verify, public offers, ingest impression/click, debug state), curl examples, and links into repository search for market, dash, and SaaS repos. |
| Live Now | Live PoI demos: /demo (display-first) and /ad-network (display + video lab) | Viewability-gated PanoramaDisplayAd, streaming-style PanoramaVideoAd with quartile hooks, consent + correlation IDs, and POST to market-api /ingest/impression when NEXT_PUBLIC_API_URL is reachable. Proof readout via AdNetworkProofStrip (journal digest sim aligned with RISC Zero guest tags — no zkVM in the bundle). |
| Live Now | Thematic education pages (Data Unions, dCommerce, Proof of Impression) | Dedicated long-form pages linked from primary nav to explain inventory models, commerce adjacency, and verifiable impression story. |
| Live Now | Integrations hub (Comment Protocol × Panorama) | First integration guide under /integrations/comment-protocol: embed asset, marketplace placement deep link, live-style preview, and copy that states deploy boundaries vs Panorama-owned surfaces. |
| Implemented | Mobile-responsive tables, code blocks, and nav wrapping | Horizontal scroll shells for wide ledgers, wrapping monospace examples, tighter padding under ~560px, and flex-wrap on top navigation. |
| In progress | Living “site text export” for audits and localization prep | Maintain a concatenated text artifact of site copy paths so compliance, brand, and future l10n passes can diff without spelunking JSX. |
| Upcoming | Versioned API changelog section on /docs | Structured breaking-change log tied to market-api semver or deploy tags; includes migration notes for publisher-sdk event schema bumps. |
| Upcoming | OpenAPI / typed client generation from SERVICES_API.md | Publish machine-readable spec (or generated SDK stubs) so integrators can lint requests in CI instead of hand-maintaining examples only. |
| UGC & display ad network (publisher surfaces) End-user ad units, ingestion envelopes, and trust UI that turn creator and publisher inventory into verifiable impressions — the path from “slot in React” to market-api and the prover lane. | ||
| Live Now | Panorama ad React surfaces on the marketing site | PanoramaAdProvider, PanoramaDisplayAd, PanoramaVideoAd, and AdNetworkProofStrip shipped in-repo; /ad-network exercises display + video together; /demo centers a single real-style display creative as the primary live story. |
| Implemented | Shared client lib for ingest + digest binding (lib/ad-network) | Typed config, impression IDs, consent gating, simulated RISC Zero receipt fields (VIEWABILITY_V1 / PLAYBACK_QUARTILES_V1), and fetch toward /ingest/impression — structured so risc0-prover can consume the same journal story without forking payloads. |
| Implemented | Comment Protocol × Panorama integration paths | Integrations page, embed sample, marketplace rows, and placement deep links so adjacent UGC inventory (e.g. Comment Protocol stars) can reserve Panorama-backed slots with consistent copy. |
| In progress | Exec mode: real receipts from risc0-prover | UI documents exec (prover service) vs sim (digest only in-browser); wire market-api / proof-worker to attach verifier-facing bundles from the Rust prover for batches that opt in. |
| In progress | npm publisher SDK (browser + correlation helpers) | Same delivery as ingestion workstream ‘Publisher SDK: npm package’ — extract /demo and /ad-network patterns into one semver’d package with /docs examples matching market-api validation. |
| Implemented | Minimal display ad decision API (GET /v1/display/ads) | market-api resolves placementId (+ optional publisherId) to an active line item + creative; landing PanoramaAdProvider fetches by default and binds decisionId/creativeId into signed impressions. Next: multi-creative rotation, frequency caps, and auth on decision for production. |
| Upcoming | Decision depth: multi-creative rotation, frequency caps, geo/device signals | Extend /v1/display/ads with weighted rotation, per-user cap state, and optional context signals while keeping the same impression envelope and PoI binding. |
| Upcoming | CTV / SSAI reference emitters on the same impression contract | Server-side and big-screen samples that sign the same fields as web so UGC and long-form inventory land in one settlement graph. |
| Marketplace UX & operator workflows Authenticated and public flows for browsing offers, managing entitlements, and inspecting protocol-backed state in the market UI. | ||
| Live Now | Route-level marketplace experience behind shared layout | Home, offers, and purchases routes with cards, tables, and navigation consistent with the rest of the protocol site. |
| Implemented | Graceful fallback when live market API data is absent | Sample offers, grants, and protocol-state placeholders so the UI remains explorable in demos and during partial outages. |
| Implemented | USC listing labels + merged external union catalog | Prices display in USC across offer flows; catalog merges real-style rows (Comment Protocol, top news network) with demo listings and placement query scroll/highlight on marketplace home. |
| In progress | Offer creation & editing UX aligned with market-api contracts | Surface validation errors from the API, preserve draft state, and expose correlation IDs returned on successful mutations. |
| Upcoming | Campaign flight dashboard (read-heavy v1) | Impressions delivered, spend pacing vs cap, and settlement intent status per campaign with deep links into verifier logs. |
| Upcoming | Role-aware marketplace (buyer vs publisher vs admin) | Route guards and navigation variants keyed off JWT claims once multi-role tokens are stable in market-api. |
| SaaS portal shell Customer-facing Next.js starter for onboarding, billing presentation, and tenant-scoped configuration without duplicating marketplace internals. | ||
| Live Now | Branded auth entry (sign-in / sign-up) and shared Panorama header | Visual continuity with marketing; correct deep links back to marketplace or docs where appropriate. |
| Implemented | Protected shell routes with session establishment | Baseline pattern for loading user context and rendering empty states before tenant data APIs are fully wired. |
| In progress | Tenant settings: API keys, webhook endpoints, allowed origins | CRUD UI backed by future market-api admin routes; v1 may persist to config tables only without billing integration. |
| Upcoming | Usage & invoice summaries (read from billing provider) | Stripe (or similar) customer portal links plus in-app usage charts keyed off metered impression events. |
| Identity, wallet auth, and session security Wallet-linked authentication for operators and publishers, JWT issuance, and safe local-development bypasses. | ||
| Implemented | Nonce + signature verify flow (/auth/nonce, /auth/verify) | Standard challenge flow documented on /docs; tokens used as bearer credentials on protected HTTP routes. |
| Implemented | NEXT_PUBLIC_DEV_BYPASS_AUTH for UI development | Skips wallet round-trip when explicitly enabled; stubs protected offer paths so frontend teams are not blocked on local chain setup. |
| In progress | Refresh tokens & shorter-lived access JWT rotation | Reduce blast radius of leaked tokens; add server-side revocation list hooks for compromised wallets. |
| Upcoming | Optional SIWE message versioning & chain ID binding | Explicit domain and chainId in signed payloads to reduce phishing and wrong-network signatures. |
| Research | Passkeys / MPC custody bridges for non-wallet-native buyers | Evaluate custodial and semi-custodial patterns that still anchor settlement to on-chain intents where required. |
| Ingestion, event contracts, and publisher SDK Signed impression and click events, schema evolution, and publisher-facing libraries that preserve correlation IDs end to end. | ||
| Implemented | HTTP ingest routes (/ingest/impression, /ingest/click) | Documented on /docs as the primary surface for SDK and server-side emitters; payloads carry placement, campaign, and signature fields. |
| In progress | Publisher SDK: npm package (browser emitters) | Single versioned package (same milestone as UGC ad network workstream) exporting types, consent-aware emit, correlation helpers, and backoff — patterns proven in /demo and /ad-network before extraction. |
| In progress | Schema registry & JSON Schema validation at the edge | Version field per event; reject unknown versions with actionable errors; publish diff between vN and vN+1. |
| Upcoming | Server-side Golang / Node emitter for SSAI partners | Reference integration for ad stitching proxies that cannot run browser JS but can sign server-to-server payloads. |
| Upcoming | CTV / streaming-stick reference player | Android TV–class shell that requests ad decisions, emits playback quartiles, and maps AVOD breaks to the same event envelope as web. |
| Proof pipeline, verification, and settlement Workers that move events from raw ingest through verification into settlement intents and adapter execution (including dry-run modes). | ||
| Implemented | Debug /state introspection for pipeline visibility | Supports demos and operator debugging; aligns with LOCAL_STACK correlation ID checks across services. |
| In progress | Proof worker hardening: idempotency + poison-queue handling | Exactly-once effects for settlement intent creation; DLQ with replay tools for stuck correlation IDs. |
| In progress | Verifier: policy packs for invalid signature classes | Configurable rules for clock skew, duplicate eventId, and mismatched campaign/placement tuples. |
| In progress | RISC Zero–oriented journal binding (sim) + prover hand-off design | Marketing and demo UIs expose digest + guestTag aligned with VIEWABILITY / PLAYBACK guests; browser stays zkVM-free. Next: optional zk bundle attachment per batch from risc0-prover for buyers who require succinct proofs beyond signed logs. |
| Upcoming | Production settlement adapters beyond dryRun | On-chain settlement driver with gas budgeting; off-chain ACH/wire ledgering for hybrid deals. |
| Campaign automation & optimization Agents and services that translate verified performance into bid/budget adjustments without breaking auditability. | ||
| Implemented | Optimizer agent writing campaign actions post-verification | Described in LOCAL_STACK-style E2E docs as the tail of the happy path after settlement marks intents complete. |
| In progress | Guardrails: max delta per hour, kill switch, spend caps | Deterministic limits on how far automated actions can move bids or budgets without human confirmation. |
| Upcoming | Creative rotation suggestions from performance clusters | Privacy-preserving aggregation across placements to recommend creative swaps (no raw cross-site profiling in v1). |
| Research | Hybrid auctions (reserved + programmatic + private deals) | Simulation harness for clearing prices when some demand is verified on-chain and some remains off-chain with delayed attestation. |
| Trust, abuse prevention, and compliance posture Rate limits, audit logs, data retention, and regional considerations that surround the core ad pipeline. | ||
| In progress | Per-API-key rate limits and burst control on ingest | Protect market-api from abusive emitters; tier limits by tenant plan. |
| Upcoming | Structured audit export (CSV + Parquet) for finance review | Immutable snapshots of settlement intents joined to proof batch IDs for quarter close. |
| Upcoming | Data retention TTLs with publisher-configurable minimums | Meet policy floor while allowing longer retention where contracts require provable replay windows. |
| Research | Jurisdictional placement rules (geo, category, political) | Policy engine that can block serve decisions pre-ingest and at verification time. |
| zkRTB, auctions, and programmatic depth Real-time bid paths, supply-path optimization, and privacy-preserving bid streams that build on verified impressions. | ||
| Research | zkRTB prototype: succinct bid eligibility proofs | Prove inclusion in audience or budget segment without revealing underlying identifiers to every counterparty. |
| Research | Autonomous targeting agents with human-in-the-loop escalation | Agents propose segment changes; humans approve before segments bind to live spend in regulated categories. |
| Upcoming | OpenRTB adapter shim (server-side translation only) | Map classic bid request/response to internal decision objects while keeping Panorama-signed playback as source of truth. |
Near term (roughly 0–90 days)
Execution focus: harden what operators touch daily (auth, ingest, proof visibility), shrink time-to-first-validated-impression for new publishers, make marketplace + docs truthful mirrors of production behavior, and close the loop from live ad surfaces (/demo, /ad-network) to verifier-ready receipts.
- Connect risc0-prover output to market-api / proof-worker for exec mode batches; keep sim mode for fast local demos and CI.
- Ship npm publisher SDK v0 with browser bundle, consent gating, and correlation ID helpers documented beside /docs examples.
- Close the loop on offer CRUD error surfaces in marketplace UI; add optimistic UI only where idempotency keys are guaranteed.
- Proof worker idempotency + replay CLI documented in LOCAL_STACK; add dashboards for DLQ depth in protocol status views.
- JWT rotation design landed behind feature flag; default remains current behavior until integrators confirm header changes.
- Expand automated smoke tests: health → nonce (bypass) → public offers → ingest test payload → debug/state snapshot in CI.
Mid term (roughly 90–180 days)
Broaden inventory types without forking the event model: CTV reference player, SSAI server emitter, and read-heavy campaign analytics that reuse the same settlement records as web.
- CTV reference app in a public repo with signed playback → ingest mapping and a minimal ad-decision stub server.
- Campaign flight dashboard v1: pacing, delivery, settlement intent timeline, and export to CSV for finance.
- Tenant API keys + signed webhooks from SaaS shell into market-api admin routes; rotate keys without session invalidation.
- Settlement adapter beyond dryRun for one production-grade chain configuration with gas alerts and pause switches.
- Begin OpenAPI publication from SERVICES_API.md with CI check that examples in /docs still compile against the spec.
Later & research (order TBD)
Higher uncertainty or heavier cross-industry alignment: zkRTB depth, hybrid auctions, advanced policy engines, and non-wallet buyer flows.
- zkRTB prototype tied to a constrained demo network; publish benchmarks (proof time, verifier cost, bid latency impact).
- Hybrid auction simulator results + proposed clearing rules; engage demand partners only after simulation coverage thresholds.
- Passkey / custodial buyer flows that preserve auditability of spend approval without forcing every media buyer to custody ETH.
- Jurisdictional policy engine PoC: category blocklists, political ad windows, and geo fence evaluation at decision time.
- Additional cross-product bridges (Streamy, further partners) scoped per integration RFC; Comment Protocol path is already live on-site — extend only where contracts require.
Risks & dependencies
- Live ad demos POST to market-api; if NEXT_PUBLIC_API_URL is wrong or the stack is down, the UI still shows digest state but operators see failed ingest — document this clearly for booth and pilot setups.
- Settlement on-chain costs and RPC reliability directly affect whether dryRun remains the default in pilot deployments.
- Schema changes to ingest payloads require coordinated publisher-sdk semver bumps; backward compatibility window must be published.
- Third-party SSAI and CTV partners move on independent roadmaps; reference implementations reduce coupling but not calendar risk.
- Verifier policy complexity can outpace UX: every new rule needs a human-readable explanation in protocol status and /docs.