Whitepaper · v0.1 · September 2026 · draft

Ponslab.

A prompt-to-build playground on Robinhood Chain (Arbitrum Orbit L2, chainId 4663). Token: $PONSLAB.

Abstract

Ponslab lets a builder lock $PONSLAB to receive AI inference credit, prompt and preview an app in the browser, then deploy it to a subdomain and launch the app's own token — in one flow, from one balance, with the app's creator fee going entirely to the builder.

Two design principles govern everything else:

1. The platform never takes the app's creator fee. Every app token launched through Ponslab records the builder as its fee recipient. The platform's only claim on a launch is a fixed $PONSLAB burn.
2. Inference is funded by the creator tax on $PONSLAB trading, never by user payments. Consumption burns supply; it does not fill the treasury. Burn and funding are separate mechanisms with separate purposes.

1 · The product

Building an on-chain app today means wiring a frontend, hosting, a token, and a fee structure across four different tools. Ponslab compresses that into a single loop: Lock → Prompt → Preview → Launch.

• Lock any amount of $PONSLAB — no minimum — and receive inference credit at the prevailing on-chain rate.
• Prompt the builder: describe an app in plain language. Generation runs through frontier AI models (the full Orbio catalogue, 400+ models under OpenRouter naming), streamed live.
• Preview the app instantly in a sandboxed pane, and iterate.
• Launch: a single transaction burns a fixed $PONSLAB amount and creates the app's token on the pons v2 factory, with the builder's wallet as creator-fee recipient — then the app is promoted to its permanent subdomain under *.ponslab.family.

A builder profile is just a wallet. Registration costs no gas; the first on-chain transaction a builder ever sends is the lock.

2 · The $PONSLAB token

• Launched on pons v2, paired with NVDA (Robinhood's tokenized NVIDIA).
• Carries a 2% creator tax on every trade, split 1% development / 1% inference treasury. Plain transfers — including locking into the vault — are untaxed.
• The tax is paid in NVDA, the pair token. It accrues in pons' fee escrow under the platform's splitter contract and is claimed and split automatically every 3 hours. The inference share is converted to provider credit in batches — funding inference sells NVDA, never $PONSLAB.
• The inference treasury purchases provider credit in small tranches sized to near-term consumption. Provider credit is a grant of product access, not a redeemable asset, so large prepaid blocks are deliberately avoided.

There is no oracle anywhere in the system. Every economic parameter is a fixed token quantity, adjusted as market conditions move.

3 · Access and metering

3.1 The rate R

R is an on-chain, admin-editable parameter defining inference tokens granted per $PONSLAB locked. Baseline: 1,000,000 $PONSLAB ≈ $5 ≈ 100,000 inference tokens. R is fixed in token terms — its fiat equivalent floats with market price and is corrected by adjustment. R is the system's only throttle: if the treasury drains faster than tax revenue fills it, R comes down.

3.2 Three balances

• Consumption draws base first, bonus second.
• Every unit of I_base consumed burns the corresponding $PONSLAB from the lock. Deflation is a direct function of usage.
• Bonus consumption burns nothing — it is a treasury-funded grant.

3.3 The daily bonus

Idle credit earns a daily bonus of 25% of idle I_base. Non-compounding — computed on base only — and each grant expires 24 hours after issue, never accumulating across days. The distribution is intentional: the builder who prompts regularly captures the most value.

3.4 Per-model credit weights

Ponslab serves the full provider catalogue, and models differ in price by orders of magnitude. Credit is therefore weighted per model against a $50-per-million-token baseline: a $50/M-output model costs 1.0 credit per token, a $10/M model costs 0.2, and free models are floored at a small minimum so consumption always burns. When a model's price cannot be determined, the full baseline weight applies — outages never mint discounts.

3.5 Withdrawal

• Withdrawable amount = locked balance net of burns. Burned tokens are gone.
• A 24-hour cooldown separates withdrawal request from release — an anti-rotation measure.
• A burn is never blocked by a pending withdrawal: if free balance is insufficient, the withdrawal request is cancelled — a launch never fails because of it.

4 · The launch flow

1. Build — prompt and preview on a temporary subdomain, consuming credit.
2. Burn + Launch — one atomic transaction: the vault burns a fixed $PONSLAB amount (admin-set, targeting roughly $5–10) from the builder's locked balance — inference credit reduces proportionally — and calls the pons factory in the same transaction, passing the builder's wallet as fee recipient. The builder pays the pons fee (0.0005 ETH) and gas. If the factory call fails, the burn reverts with it.
3. Promote — on confirmation, the app moves to its permanent subdomain.

What is gated is the deploy, not the token. Token creation is open to anyone directly on pons. The burn pays for what only Ponslab supplies: app generation, hosting, and the subdomain.

5 · App lifecycle

Deployed apps live at *.ponslab.family. Apps with zero traffic for 30 days are auto-sunset — hosting is taken offline, while the app's token (which lives on pons, not on Ponslab) is unaffected. There is no slot rent; the sunset exists to cull abandoned deployments and shrink the shared domain's abuse surface.

6 · Architecture

• Vault contract (on-chain): holds locks, meters entitlement at R, executes burns, enforces the withdrawal cooldown, accrues and expires the daily bonus, and routes the atomic burn+launch to the pons factory. Every rate change and burn is an on-chain event.
• Backend (off-chain): reads locked balances from chain 4663, enforces per-epoch quota, relays inference through Orbio with a direct-provider fallback behind one adapter, weights credit per model from the live catalogue, and reports each day's consumption back to the vault — which burns accordingly.
• Playground (web): the prompt/preview interface, credit dashboard, lock form, and launch flow.

Transparency: the backend publishes a public daily reconciliation feed — aggregate credit consumed, credit reported on-chain, and burn transaction hashes for every epoch. Anyone can compare the feed against on-chain burn events.

7 · Trust assumptions

• The backend holds the inference keys, meters consumption, and reports burn amounts to the vault. A dishonest or compromised backend could misreport.
• Deployment and hosting are centralised.
• Some inference requests are served through marketplace supplier keys and pass through those suppliers' accounts under whatever logging they configure. Builder prompts are product ideas; this will be disclosed in the terms of service.

The mitigation is the public reconciliation feed above — misreporting is detectable by third parties, every day.

8 · Risks

• Bonus liability is unbounded by user count. The daily bonus is treasury-funded with no burn behind it. The 24-hour expiry caps outstanding liability at a single day's grant, but not the daily flow. R and the bonus percentage are monitored against treasury inflow.
• Both income and sink are hype-driven. Tax revenue tracks trading volume; burn tracks launch count. Neither automatically scales with the number of live apps.
• A falling token price makes inference cheaper while tax revenue falls in the same move — the primary drain scenario, and the reason R is actively managed rather than set once.
• Always-on agents are a different cost class from apps. An agent launched through the playground must carry its own economics; the platform does not fund its children's runtime.
• User-generated code on a shared domain is a phishing surface. Deployed apps run under a locked wallet SDK, CSP, and address allowlist; generated previews run in a no-network sandbox.

9 · Roadmap

This document describes intended v1 behaviour and will change. Nothing here is financial advice; $PONSLAB is a utility token for metering inference on Ponslab.