How it works

A launch here is an ordinary pons v2 token: a bonding curve holding the entire supply, tradeable from the first block, graduating into a pool whose liquidity is locked permanently. What is different is what the fee is for.

Every launch backs one GPU SKU from the catalogue — an H100 node, a consumer RTX 5090 on a marketplace, a community-hosted DGX Spark — and trades against a pair asset of the creator's choice: ETH, a stablecoin, or a tokenized stock. Every trade against that token pays 2% to the platform treasury, and each claim is split — 50% of it is the compute pool, and anyone who has launched a token can spend that, on any GPU the platform carries, not only their own.

1. 01

   Launch. Title the token, pick the GPU it backs, pay the launch fee. The whole supply is minted to a bonding curve, and the treasury is set as the fee recipient in the same transaction.

2. 02

   Trade. 2% of every trade accrues as a creator fee, in the asset the token trades against. It sits on the launch's own curve until something sweeps it.

3. 03

   Claim. The keeper sweeps each curve into the fee escrow, then claims the escrow to the treasury and records what was collected and at what ETH price.

4. 04

   Split. Each claim is split: 50% funds the compute pool, 30% is held against a future buyback and burn of the protocol token — which does not exist yet, so nothing is bought or burned — and 20% is kept by the protocol.

5. 05

   Spend. The pool's share becomes GPU-hours. Anyone who has launched a token can run jobs on any backed GPU, and each job is billed against the pool per GPU-second.

The GPU is chosen at creation and recorded with the launch. It is a catalogue id such as nvidia/h100-sxm-80gb, and it is checked against the live marketplace catalogue before the launch is recorded, so a token cannot claim to be backed by hardware nobody rents.

A GPU becomes provisionable when a token launches for it, and not before. The catalogue lists every SKU the aggregator can source; the ones you can actually run jobs on are the ones something funds.

Several tokens can back the same GPU. Nothing stops it, since they all contribute to the same pool.

A launch trades against a pair asset, chosen at creation and fixed afterwards. pons v2 accepts any ERC-20 here, and on Robinhood Chain that includes real-world assets: Robinhood stock and ETF tokens, tokenized gold, and dollar or euro stablecoins — as well as plain ETH.

Whatever the pair, the mechanics are the same: the bonding curve quotes in it, the 2% creator tax is charged in it, and graduation seeds a pool of the token against it. Only the ledger step changes — the keeper values claimed fees at the pair's spot price when it books the credit, and swaps non-dollar assets to USDC before topping up the GPU marketplace.

The creator tax is 2% on every launch and is not a setting. Letting each launch choose would make what a trade contributes depend on which token it happened to be, and would let a launch opt out of funding the thing it is using.

Fees are charged in the asset the token trades against, never in the token itself.

Every launch points at the same treasury address as its creator fee recipient, fixed in the launch transaction and unchangeable afterwards. There are no per-token vaults: one address collects everything, because there is one pool to fund.

The treasury is also the keeper's own wallet. The escrow credits whatever address a launch named, and claim() pays out to whoever calls it, so the only wallet that can collect those fees is the one that owns them. It can hold fees and spend them on GPU time. It cannot mint, cannot reach locked liquidity, and cannot touch anyone's balance.

Fees do not arrive on their own. Before graduation a fee sits on the launch's own curve until a sweep moves it into escrow, and the escrow holds it until it is claimed. The keeper walks every launch, sweeps what has accrued, then claims the escrow once.

curve fees (in pair asset) → sweepFees() → fee escrow → claim() → treasury → valued at spot → compute pool → USDC → marketplace credit

Nothing is swept until it is worth more than the gas to collect it. On each claim the ETH amount is converted at the spot rate and that rate is written onto the record. If no rate can be fetched the claim is still recorded and the credit is left for a later run, rather than being booked at a guessed price.

The pool is a ledger, not a balance. Every credit and every debit is a row, and the balance is their sum. A stored total would be wrong the moment two jobs settled at once.

available = Σ(claims credited) − Σ(GPU-seconds billed)

Amounts are integer micro-USD, meaning millionths of a dollar. Marketplace rates are quoted per hour but settle per second, and floating point addition over thousands of rows does not stay exact. Rows carry the launch they belong to where there is one, so a token page can say what that launch contributed.

There is no single “OpenRouter for GPUs”, but an aggregator plays the same role: one API and one price catalogue over many clouds, so the platform never hardcodes a provider. The keeper tops up the aggregator account from the treasury; jobs are provisioned there at the live rate for the SKU a token backs.

Desktop-class hardware — DGX Spark, DGX Station — is not a cloud SKU. Those come from community hosts who list a box the way Vast.ai hosts do, and are paid from the pool per GPU-second like any other provider.

Anyone whose wallet has launched a token can run jobs on any backed GPU. Not only the GPU they launched, and not only while their own token is trading.

Access is proven with a signature, not with a claimed address. Each request carries a signed message with a timestamp, valid for 10 minutes. There is no session: the signature is checked per request. The browser reuses one signature for its lifetime, so a session is one wallet prompt rather than one per job.

Every job reserves its cost at submit time from the SKU's marketplace rate, then settles from the seconds the provider reports when it ends. It is never a flat rate per job.

cost = gpu_seconds × (hourly_rate ÷ 3600)

The result is rounded up to the nearest micro-USD, so a long tail of short jobs cannot add up to free compute. Both the reservation and the settlement are stored on the job and on the ledger row, so a charge can be checked against the catalogue rather than taken on trust. Jobs are capped at 8 hours each.

Anything you can do in the console you can do from your own code. Mint a key on the keys page and POST a job spec to https://cudapad.com/api/v1.

POST /api/v1/jobs { gpu, template, hours, env }, Authorization: Bearer cudapad_sk_…

Keys are stored as a SHA-256 hash and never in plaintext, so the key is shown exactly once, when it is minted. A key spends the shared pool, not a balance of its own. Treat it like a credential that can spend other people's money, because it can.

A launch holds its entire supply on a bonding curve from the moment it is created. The curve will always sell you tokens and always buy them back, and the price is worked out from how much of the supply has been bought so far. You are never waiting for someone else to take the other side.

Every launch opens with a tax on buying that starts near 99% and decays to nothing within 5 seconds. It exists so that being first is not profitable. Selling is never taxed by it, and the launching wallet is exempt.

When the curve sells out, the launch graduates: everything it collected is handed over to seed a pool, along with the share of supply that was held back from the start for exactly this purpose. The liquidity is locked permanently.

Everything runs on pons v2 on Robinhood Chain, chain id 4663. Each launch's own curve and token are created per launch and should be resolved from the factory rather than hardcoded.

Two parts of the path above are not automated yet, and it is better to say so here than to let someone discover it.

Topping up the aggregator is manual. The keeper claims fees and credits the pool, but nothing moves that ETH into marketplace credit. The pool is our accounting of what has been raised, not a reading of the real balance.

Trade volume is not mirrored. Trades are read from chain logs by an endpoint nothing currently calls, so 24h volume is not shown anywhere. Price and market cap do not depend on it.

Launch tokens are volatile and can lose all value. Anyone can create a launch with any title, symbol and image, including ones that deliberately imitate an existing project. Titles and symbols are not unique and are not verified.

Transactions are submitted by your own wallet and may be irreversible. Nothing here takes custody of your tokens or your funds.