gridprotocol.io is one front-end of many.
The protocol does not know which UI created any given customer account. There is no hardcoded Foundation pubkey with admin authority. Customer accounts on the chain are first-class regardless of which front-end provisioned them. Anyone can ship a competing Grid front-end with the SDK, their own Stripe account, and their own pricing.
The reseller pattern
Per Def-Eco-Design.md Invariant 4, the chain is neutral with respect to front-ends. Operate one with this stack:
Marketing + signup
Your domain. Your design. Your Stripe Checkout. The Stripe customer account lives off-chain.
On-ramp into the customer's escrow
Stripe webhook → your orchestrator → on-ramp (USD → USDC) → funds the customer's on-chain escrow. The escrow converts to GRID at the pool when the market is deep enough to absorb it, and holds dollars when it is not. The chain has no idea who initiated any of it.
SDK calls for everything else
@thegrid/sdk + @thegrid/primitives for chain actions, capability-token issuance, receipt streaming, settlement queries.
Why this matters
- Legal posture — single-asset def:eco + neutral chain bounds constructive-custody analysis. No Foundation admin keys means no centralized risk.
- Ecosystem — competing front-ends can specialize (gaming-focused, AI-agent-focused, regulator-friendly, regional language). They share a chain; users can move between them.
- Resilience — gridprotocol.io can disappear tomorrow. The protocol keeps running. Customer accounts stay valid; another front-end can serve them.
- Pricing freedom — front-end operators set their own SaaS markups, support tiers, premium features. The protocol unit prices are fixed via governance; everything above is your margin.