The Network as a Platform (NaaP) model is the most advanced Gateway operator pattern: build a multi-tenant platform that wraps Livepeer compute as a managed service. Users sign up, receive API keys, and pay in fiat or standard crypto. The platform handles all crypto complexity internally - users never interact with Livepeer contracts.
What NaaP solves
The go-livepeer gateway binary routes jobs and handles payments. It does not handle:
- User authentication or API keys
- Per-customer rate limiting or quotas
- Usage tracking or billing
- Multi-tenant isolation
NaaP is the product layer that sits on top of the gateway and handles all of these. It turns a single-operator gateway into a platform that can serve many customers independently.
Your customers
│
│ API key + request
▼
NaaP product layer ←── auth, billing, usage metering
│
│ authenticated request
▼
go-livepeer gateway ←── orchestrator selection, payment
│
│ job + payment ticket
▼
Livepeer network (orchestrators)
“The user never interacts with Livepeer contracts. The signer uses incoming USDC revenue to keep its hot wallet funded for PM ticket generation. The two payment layers are fully independent.”
Two independent payment layers
The core architectural insight behind NaaP: your customer-facing payments and the network-facing payments are completely separate.
Your margin is the difference between what customers pay you and what the network charges. The customer never sees ETH, Arbitrum, or payment tickets. The protocol is invisible to them.
Reference implementation: the NaaP dashboard
The NaaP dashboard (github.com/livepeer/naap) is the reference implementation for multi-tenant gateway access. It provides:
- JWT-based authentication via SIWE (Sign-In with Ethereum) - developers sign in, receive a JWT, and use it for all API calls
- Developer API Keys - per-customer keys with configurable rate limits
- Usage metering - per-key request counting, pixel tracking, inference counting
- Dashboard UI - self-service portal for API key management and usage monitoring
NaaP is in active development. The demo is operational but the production API is not yet stable. Build against it with the expectation that breaking changes will occur.
Multi-tenant architecture
Authentication flow
Tenant isolation
Each customer (tenant) operates within boundaries set by their API key:
| Isolation concern | How NaaP handles it |
|---|
| Request quotas | Per-key rate limits (requests/minute, requests/day) |
| Usage caps | Per-key maximum usage (pixels, inferences, minutes) |
| Billing separation | Per-key usage tracking for independent invoicing |
| Failure isolation | One customer exceeding quota does not affect others |
| Data separation | Per-key logs and metrics |
Orchestrator affinity
For premium tenants, you can configure orchestrator routing preferences:
- Route premium customers to high-tier orchestrators (lower latency, higher reliability)
- Route budget customers to standard orchestrators
- Route specific workload types to capability-matched orchestrators
This is configured at the middleware layer using -orchAddr or -maxPricePerCapability per request path. The NaaP layer passes routing hints to the gateway based on the customer’s tier.
Building the product layer
Option 1: Use the NaaP reference implementation
The fastest path. Clone the NaaP dashboard, configure it for your gateway, and customise the billing and branding.
What you get out of the box:
- JWT auth via SIWE
- API key generation and management
- Usage tracking per key
- Dashboard UI
What you still need to build:
- Payment integration (Stripe, crypto billing, etc.)
- Custom pricing tiers
- Customer onboarding flow
- Production monitoring and alerting
Option 2: Build your own product layer
If your platform has specific requirements that NaaP does not cover, build your own using standard middleware patterns.
Architecture:
Customer request
↓
[Auth middleware] - validate API key / JWT
↓
[Rate limiter] - per-key request throttling
↓
[Usage tracker] - log request for billing
↓
[Routing middleware] - select orchestrator tier based on customer
↓
[go-livepeer gateway] - route job and handle payment
↓
[Response middleware] - log result, update usage counters
↓
Customer response
- Auth: Express.js middleware, FastAPI middleware, nginx auth_request
- Rate limiting: Redis-backed counters, nginx rate_limit
- Usage tracking: PostgreSQL or TimescaleDB for per-key metrics
- Routing: Custom proxy logic or Kong/Traefik API gateway
See Gateway Middleware for detailed middleware architecture patterns.
Billing integration
What to meter
| Workload type | Metering unit | How to capture |
|---|
| Video transcoding | Minutes of transcoded video | Gateway result metadata |
| Batch AI (text-to-image, etc.) | Output pixels or number of generations | Gateway result metadata |
| Live AI (LV2V) | Seconds of processed stream | Session duration tracking |
| LLM | Output tokens | Gateway result metadata |
| Audio-to-text | Seconds of input audio | Request metadata |
Pricing models
| Model | Description | Used by |
|---|
| Per-request | Charge per API call or per inference job | API providers, Daydream |
| Per-minute | Charge per minute of video transcoded or live AI processed | Livepeer Studio |
| Subscription | Monthly access fee regardless of usage | SaaS gateway products |
| Usage-based | Charge per unit (per pixel, per generation, per token) | Direct API products |
| Free + SPE-funded | No charge to users; costs covered by treasury grant | Livepeer Cloud SPE |
| Credits | Pre-purchased credits debited per job | Hybrid platforms |
-maxPricePerUnit and -maxPricePerCapability to control your network costs; set your customer prices independently.
Clearinghouse: the payment bridge
The clearinghouse is the component that bridges your customer-facing payment layer with the network-facing ETH payment layer. It:
- Receives customer payments in your chosen currency (fiat, USDC, credits)
- Maintains an ETH hot wallet funded from customer revenue
- Acts as the remote signer for your gateway - generating payment tickets backed by the ETH balance
- Settles with orchestrators via probabilistic micropayments
The clearinghouse means your gateway node holds no ETH and has no direct Ethereum dependency. The clearinghouse operator (you, or a hosted service) manages the on-chain side.
For the full clearinghouse design and implementation, see Clearinghouse Guide (Payments & Pricing section).
Next steps
