Whitepaper

In the agentic economy, compute is the currency.

Agents don't browse. They spend. Every task they run is a stream of tokens in and tokens out, billed by the million, and whoever holds a budget of compute holds the ability to get work done. Money that turns into intelligence is the obvious next primitive, and the race to build it has started. Some projects are building whole new chains for it, with GPU miners producing the compute and a native token to pay for it. FLOP Network is one; according to flop.finance in October 2026, its testnet is planned for Q4 2026 and its mainnet for Q1 2027 [8]. Nowhere is not affiliated with FLOP Network.

We take the other road. No new chain. No miners to recruit. No network to bootstrap before the first answer. Nowhere is one program on Solana, where coins already launch and trade at scale, and it serves AI today from a provider that already runs strong open models privately. What we add is what has been missing: an allowance anyone can check, and privacy spelled out in plain words instead of implied.

The funding is ordinary on purpose, and it is explained where it belongs: $NOWHERE trades on pump.fun, and the creator fee pump.fun collects on every trade feeds a fund whose budget follows a public formula (Sections 3 and 5). The same program serves every coin launched on our Meteora launchpad or plugged in from another Meteora curve, and every one of those coins burns $NOWHERE (Section 11).

We are just as plain about the limit. No program can observe that SOL paid for inference. Nowhere does not remove trust in its gateway. It narrows that trust to one claim, caps what the claim can cost at one day's budget, and publishes the evidence every day (Sections 9 and 12). Version one is deliberately small; what we cut is listed under Later (Section 16). Everything described here is specified in full. None of it is audited or deployed yet (Section 14).

Holders lock the token in their coin's stake vault, a token account the program controls. Each holder has a Position account and each coin a StakeTotals account, and both keep a ring of the last eight days: the value at the end of day X is the last write on day X. That covers every day the fund can still settle, so any stake that matters can be recomputed on-chain, and asking about a day that has left the ring is an error, never a wrong value. Only tokens that actually arrive in the vault are credited. Staking has no admin and no pause.

Days are UTC days numbered from the Unix epoch, ⌊t / 86,400⌋, read from the Clock sysvar in the program and from the clock in every service. Day D has two snapshots: the ends of D − 2 and of D − 1, at 23:59:59 UTC. An account's eligible stake is the smaller of its stakes at the two snapshots, and the eligible total is the smaller of the two totals:

ea(D) = min( eoda(D − 2), eoda(D − 1) )
E(D)   = min( EOD(D − 2), EOD(D − 1) )

eod(X) = the last value written on day X     its value at 23:59:59 UTC

Both snapshots are in the past when D begins, so a day's shares are final at 00:00 UTC. A stake counts only if it was in place at both snapshots, a full day apart: staking around a snapshot earns nothing. A stake made during day X is first counted on day X + 2, which the site puts as stake today, earn from the day after tomorrow. Unstaking is a request, request_unstake: the stake drops at once and withdraw releases the tokens one day later. Because the current day's snapshots are already past, an unstake keeps that day's ration and stops counting from the next day. A position's rent is paid by its staker and refunded by close_position.

The one-day exit is deliberately shorter than the admin's 48-hour time lock (Section 12), so a holder can always leave before any change to the rules applies.

Here is where the AI comes from.

Every trade of $NOWHERE pays pump.fun a trading fee in SOL. Part of it is the coin's creator fee, and pump.fun pays all of that to $NOWHERE's Router account, which sends 60% to the coin's Fund account (Section 5). The fund holds the SOL that pays for holders' AI, as lamports in an account only the program can debit. Nothing else can raise a budget: inflow is counted only when the router's distribute credits the fund. A donation through top_up, SOL sent back by the payout account or lamports transferred straight into the fund all add to the balance, but never to a budget.

Counted SOL is recorded under the day it arrives, I(d). The average inflow for day D divides the counted inflow of the seven days before it by seven, with days before the fund's launch day counting as zero. When the operator opens the day with open_today, the fund fixes the day's budget once:

A(D) = ( I(D−1) + I(D−2) + … + I(D−7) ) / 7
F    = lamports − rent − unspent(D − 1)       free balance
B(D) = min( F, A(D) ) × budget_bps / 10,000

budget_bps = 9,000 at launch, hard maximum 9,500

Today's inflow never enters today's average. A holder's ration is then a value anyone can compute, by simulating ration_of or from the accounts directly, and it is zero when nobody is eligible:

ration_of(a, D) = B(D) × ea(D) / E(D)        in lamports, rounded down

Four properties follow, and the tests check them as invariants:

• The fund always covers its open days. Its lamports above rent cover unspent(today) + unspent(yesterday). A slow week shrinks the next budgets. It never creates a debt.
• The free balance is a backstop. Each day's counted inflow is budgeted at most a seventh at a time, at 90%, and SOL leaves only through draws, so F does not bind: budgets equal 0.9 × A(D), and the cap on F is defence in depth.
• Unspent budget does not compound. It stays in the fund and never raises a later budget, because the average counts inflow, not balance.
• Launch week ramps up. The average always divides by seven, so the launch day's budget is zero and budgets reach their steady level on the seventh day after launch (Section 13).

The fund keeps the last 32 days of budgets and the last eight days of inflow in fixed rings, so its account never grows, and a day that has left a ring reads as zero.

One day, one settlement, the next morning.

Holders spend day D's ration during day D; the gateway meters every call off-chain and pays the provider. The fund pays the gateway back exactly once, for yesterday only. The operator calls draw(instance, day, usd_micro, report, expected_prev_root) for yesterday, and only while unix_timestamp mod 86,400 < 43,200, that is, before 12:00 UTC. The draw states yesterday's AI cost in micro-dollars, and the program prices it in SOL itself, from Pyth's SOL/USD account, at that moment. The total drawn for a day never exceeds that day's budget, every draw goes to the payout account fixed in Config, which only the admin can change, and nothing is ever drawn against the current day.

lamports = ⌈ usd_micro × 103 − expo / price ⌉     Pyth price and exponent, read at draw time
paid     = min( lamports, B(d) − drawn(d) )         only for d = today − 1, before 12:00 UTC

The program takes the price only from the configured Pyth account and feed, fully verified, at most 120 seconds old, and with a confidence band within 1% of the price; otherwise the draw fails and the keeper tries again with a fresher update. The operator opens each day with open_today, which fixes its budget and is idempotent; the keeper calls it at 00:02 and again every hour. A day that is never opened has a budget of zero. A day not settled by noon the next day can no longer be drawn: its budget stays in the fund, unpaid.

Every draw carries the hash h of the usage report it pays for (Section 9) and extends a hash chain for the day, which starts at zero and is stored in the fund as usage_root:

RD ← keccak256( RD ‖ h ‖ a )        a = lamports paid, 32 bytes, big-endian

Each draw must name the root it extends, expected_prev_root, so two draws can never race. A later report for the same day can extend the chain again before noon. A report can be superseded in the chain; it cannot be erased from it.

Every coin's fees end up in its Router account as SOL. From there anyone may call distribute(instance), which splits every lamport not already owed. How the fees get there depends on where the coin trades.

$NOWHERE on pump.fun

$NOWHERE trades on pump.fun's bonding curve and, once the curve fills, in its canonical PumpSwap pool [13]. Every trade pays a fee in SOL, and part of it is the coin's creator fee. The rate is pump.fun's to set: it comes in tiers by market cap and moves as the coin grows.

All of that creator fee goes to the program. Through pump.fun's own fee sharing, the coin's creator fees are routed once to a single recipient, $NOWHERE's Router, at 100%, and the right to edit that routing is then revoked. create_root_pump checks all of it on-chain and refuses to register $NOWHERE otherwise, so the coin can only join the program with its fees already routed to its own router. Whatever pump.fun pays to the router's address before then is kept.

pump.fun holds the fees on the curve and in the pool until someone sweeps them. Its sweep, transfer and distribute instructions are permissionless, so anyone can move the fees into the router, and the keeper runs them together with our distribute:

Before every crank the keeper checks that the routing still pays the router and nobody else. If it does not, the keeper sweeps nothing and raises an alert, and distribute still splits whatever the router already holds.

Burns buy $NOWHERE on the same market. burn_pump buys on pump.fun's curve, and after graduation on the canonical PumpSwap pool and no other pool of the pair, then burns what it bought, under the same caps, cooldown and slippage floor as any burn. The buy is signed by a program account that holds exactly that burn's SOL and is empty again when the burn ends. When the curve fills, pump.fun's migrate_v2 opens the PumpSwap pool, and anyone can run it. pump.fun usually does it within seconds; if it has not after a grace period, our keeper runs it.

Coins on our launchpad (Meteora)

Coins from our launchpad trade on our own Meteora Dynamic Bonding Curve config and, after graduation, in a Meteora DAMM v2 pool [2]. Both collect fees in SOL only. On every trade the pool charges a 1% fee, higher only in the first seconds after a launch (Section 11). Meteora keeps 20% of it, and the other 80% belongs to our partner config, whose fee claimer is the program's Partner account. When a curve graduates, all of the new pool's liquidity goes to the same account and is locked for good, while its fees stay claimable. A coin plugged in from another Meteora curve pays its router that curve's creator fee instead (Section 11).

Anyone may call claim_fees(instance), which moves a coin's fees from Meteora into its router through typed calls into Meteora's two programs. distribute then pays the creator's share, sends 10% to the $NOWHERE Burner and leaves the rest to the coin's fund (Section 11).

Payouts and the Burner

Recipients arrive as fixed accounts, checked against the instance and Config, and the same account can never appear twice. A credit that would leave a recipient below rent exemption is recorded as Owed instead, and anyone can deliver it later with claim_owed. Since inflow is recorded when distribute runs, whoever calls it picks the day on which the fund's share counts. Tokens sent to a fund by mistake can be rescued by the admin with rescue_token; its lamports cannot.

The Burner collects every burn share. It turns its SOL into $NOWHERE with one buy on $NOWHERE's own market, pump.fun's curve or its PumpSwap pool, checks that at least min_out arrived, and burns exactly what arrived with the token program's burn_checked [11]. A burn really reduces the supply: no dead address holds the tokens. The stablecoins it receives from paid usage are first swapped to SOL by convert, through one route the admin pins for each stablecoin. Only the operator may burn or convert, every burn waits out a cooldown and stays under a cap in lamports, per burn and per UTC day, and any $NOWHERE the Burner already holds can be burned by anyone with burn_held, even while burns are paused. The keeper adds two habits of its own:

• Small and private. Burns go out in small chunks, sent privately through Jito and marked with jitodontfront, so no bundle can put a trade in front of them.
• A floor on every swap. Every burn and conversion names a minimum output, so a moved price fails the swap instead of filling it badly.

The ration is the floor, not the ceiling. Usage beyond it is bought with dollar stablecoins: USDG or USDC, and optionally PYUSD [12]. All three have six decimals, so one smallest unit is one micro-dollar. One instruction, buy_credits(account, mint, amount), credits any account. The gateway sells paid usage at 1.3 times its upstream cost, and the program splits every payment the moment it lands:

Since 1 / 1.3 ≈ 76.9%, the 77% upstream share covers the provider. Of the 23% margin, 15.4 points, two thirds, are burned and 8.6 points go to the team. A recipient whose token account is frozen or missing gets a PayOwed balance instead of blocking the payment. Every purchase raises the account's Credits.total_purchased_micro, a counter that only goes up, and the gateway credits each increase exactly once, reading the account at finalized commitment, at one dollar of credit per dollar paid. Paid balance is spent only after today's ration, and never by a ration-only key.

The gateway is the part people touch: OpenAI-compatible chat completions, streamed or not, behind one wallet login. Users sign in with Sign-In With Solana [1], through the wallet's solana:signIn or a plain signed message, checked as an Ed25519 signature inside the gateway with a single-use nonce and an expiry the server enforces, and receive a session valid for seven days. Addresses are base58 and kept exactly as written, never lowercased. A session creates API keys of the form rtn_…, shown once and stored only as SHA-256 hashes, with scope full (ration and paid balance) or ration (ration only).

The ledger counts integer micro-dollars, 10⁶ to the dollar. Rations are amounts of SOL, so to show and meter them in dollars the gateway takes one SOL price a day from Pyth's SOL/USD feed [4], read from its sponsored push account 7AviUf9nL62mcxNbQGKm4nKDQnPjswo6c5MX4D57HmyE. Pyth publishes a price as an integer with an exponent:

P = price × 10expo                      dollars per SOL
μ = ⌊ lamports × price × 10expo − 3 ⌋        a ration in micro-dollars

A price of 10,521,000,000 with exponent −8, for example, is P = $105.21. This snapshot only turns rations into dollars for the ledger and for display. Settlement never depends on it: the program prices each draw itself, at draw time (Section 4).

On a wallet's first request of the day the gateway reads, in one batch, the Position, StakeTotals and Fund accounts of every coin funded that day (Section 11), computes each ration exactly as ration_of does, converts it at the day's price, rounding down, and stores the total. Shared test vectors, checked against the program, keep the two computations identical. The cost of a call is computed from the token counts the provider reports, never from the client's:

c = ⌈ ( p × πin + q × πout ) / 106 ⌉            micro-dollars

charged to the ration       c
charged to paid balance     ⌈ 1.3 × c ⌉

Here p and q are the prompt and completion tokens and π the model's prices in micro-dollars per million tokens. The ration is spent first and charged at cost, because the fund pays the provider exactly.

Before calling the provider, the gateway holds enough for the worst case: the whole request at one token per byte at the input price, plus max_tokens at the output price, plus any debt. The hold is one database transaction, and the schema itself forbids a ration used beyond its amount or a negative balance, so concurrent calls cannot overspend; a wallet may have four holds in flight. When the call ends, the hold becomes the actual charge. A call the provider has started to answer is always charged, even if the client leaves; a hold that never started is released. Overage that nothing covers becomes a debt, paid first from the next ration or credit. If the chain cannot be read, the request proceeds with a ration of zero, for that request only, so paid users are never blocked by an RPC outage.

Each day the gateway serves one usage report per coin: the day, the ration cost in micro-dollars, the paid cost, one entry per wallet with its ration and paid charges and its number of calls, and the coin's instance. Wallets are base58 addresses, sorted by code unit. Paid usage belongs to $NOWHERE, instance 0, so the paid cost is "0" in every other coin's report. Amounts are decimal strings:

report_hash = keccak256( canonical JSON of the report, without report_hash )
signature   = HMAC-SHA256( report signing key, report_hash )

Canonical JSON means keys sorted recursively and no whitespace. The gateway signs every report under a key it shares with the keeper, stores it immutably under its hash, and publishes it at /public/reports.

Every hour from 00:00 to 11:55 UTC, the keeper fetches yesterday's report for each coin and draws only against one whose signature and hash check out and whose entries add up to its ration cost. There is no price for it to cross-check: the program prices the draw itself (Section 4). It sends

draw( instance, D, usd_micro, report_hash, expected_prev_root )        D = yesterday

with the report's ration cost as usd_micro, and then checks that usage_root moved to exactly the value it expects. A repeat run sends nothing.

Anyone can fetch a day's published reports, recompute every hash and the chain, compare the result with the fund's usage_root for that day, and match the amounts against the Drawn events and the payout account.

Your agent gets a daily AI budget, and it can't touch your paid balance.

An agent is software acting for a holder: a script, a bot, an AI assistant. It needs no wallet of its own. The holder signs in, creates an API key with scope ration, and hands it over: that key spends the wallet's daily ration and nothing else, never the paid balance, and the holder can revoke it at any time. Three doors share the one ledger:

• The API. OpenAI-compatible /v1/chat/completions, streamed or not. Any OpenAI client works with a base URL and an rtn_ key. Without a model, the gateway picks the cheapest one.
• The web console. Sign in with the wallet, chat, manage keys and their scopes.
• Telegram. A bot that answers in private chats and groups. It links a wallet through a signed page that names the Telegram account, plus a /confirm in the chat within ten minutes, and the key it receives spends only the ration until the owner widens it. Groups never see amounts, and /ration replies in a private chat. Every answer ends with the line Private model on Venice and the model's name. Unlinked users get a one-line pointer to link a wallet.

Every coin can feed its holders AI.

Nowhere is one Solana program. Every coin in it is an instance: a set of accounts derived from the coin's mint, with its own Fund, Router, StakeTotals and stake vault, and one Position per staker. Nothing is deployed per coin. $NOWHERE is instance 0; coins from the launchpad are numbered from 1. The launchpad starts paused: no launch or plug-in happens until the admin, behind its public 48-hour time lock, unpauses it.

Launch or plug in

• Launch. The creator's wallet sends one transaction. It creates the coin's pool on our Meteora Dynamic Bonding Curve config, always paired with SOL, optionally makes the creator's first buy at the minimum fee, and calls register_launch, which creates the coin's instance with the creator's payout account and share. Fees fund holders' AI from the first trade. register_launch refuses a pool that is not on our config and a mint that is already registered.
• Plug in. adopt_dbc serves a coin launched on someone else's Meteora curve. Its current pool creator signs, and in the same instruction the pool's creator role moves to the coin's Router, so the coin's creator trading fees fund its holders' AI from then on. It is refused between the end of the curve and the migration.

Every launched or plugged-in coin's fees come from Meteora. claim_fees moves them into the coin's router, from the curve before graduation and from our locked DAMM v2 position after it, and distribute splits them. Both are open to anyone, and the keeper calls them for every coin in turn. After a curve migrates, anyone can call set_graduated, which records the new pool once it has checked that our Partner account holds the position and that the pool trades the coin.

The snipe guard

Every launch on our config starts with a trading fee of 99% that falls along an exponential schedule to 1% over about 30 seconds, timed by the clock rather than by slots. Bots that buy in the first seconds pay almost all of it. What they pay is a trading fee like any other, so it flows through the coin's split. The creator's own first buy, inside the launch transaction, pays the minimum fee.

The split

A coin's router pays the creator's share first, anywhere from 0% to 50%, then 10% to the $NOWHERE Burner, and the rest to the coin's fund, which counts it as inflow under the same budget formula as $NOWHERE's. Every coin, whatever it is, burns $NOWHERE.

creator       = fees × creator_bps / 10,000     0 ≤ creator_bps ≤ 5,000
$NOWHERE burn = fees × protocol_bps / 10,000    1,000 at launch, at most 2,000
fund          = fees − creator − burn           takes the rounding remainder

Our launch config

A worked example

Take a coin with a 20% creator share. For every $1,000 traded after the launch window, roughly:

router  = 80% × $10                = $8.00
creator = 20% × $8                 = $1.60
burn    = 10% × $8                 = $0.80   of $NOWHERE
fund    = $8 − $1.60 − $0.80       = $5.60

steady-state budget = 90% × $5.60  ≈ $5 a day of AI

So each $1,000 of daily volume becomes about $5 a day of AI for the coin's stakers once the seven-day average has filled, and every trade in a coin's first seconds pays far more. This is arithmetic, not a forecast: fees are collected in SOL, and the SOL price moves.

Locked to AI

Once a coin's fees reach its router, they are locked to AI. The creator cannot take them back, and the program has no instruction that sends them anywhere but the split. For coins launched on our config the fee claimer is the program's own Partner account; for plugged-in coins the pool's creator role belongs to the coin's router; for $NOWHERE, pump.fun's fee sharing pays its router and nobody else. Only the admin, a Squads multisig whose every change waits 48 hours in public, can change the rules, and a holder can unstake in one day.

One gateway for every coin

To the gateway every coin is alike: it finds them through the program's Registry, an append-only list of every registered coin's mint. A wallet's ration is the sum over the coins funded that day. Its ration charges are attributed to coins in ascending instance id, filling each up to its share. Each coin gets its own signed usage report, settled from its own fund. A holder of three coins sees one ration, and each coin's fund pays only for its own holders' AI.

The program stores its roles in its Config account. Admin control moves in two steps, proposed by the current admin and accepted by the new one, and it can never be renounced.

Because the upgrade authority is the Governance vault, even a program upgrade waits 48 hours in public. That delay is longer than the one-day unstake, so holders can always leave before a change applies. Opening a day, claiming fees and distributing them cannot be paused, and none of them can do harm: one fixes a budget, the others move fees toward the fund. Staking has no pause at all.

Worst cases

• A stolen operator key reaches yesterday's unspent remainder, only before 12:00 UTC, and only to the team's own payout account, never to the thief. That is one day's budget at most. Today's budget is out of reach. Burns and conversions stay within their cooldowns and caps. The guardian can pause all of it at once, and the admin can replace the key after its delay.
• A compromised admin must queue every change 48 hours ahead in public, program upgrades included. No admin instruction moves a fund's SOL: it leaves only through the daily draw.
• A rogue guardian can stop draws, burns, payments and launches. It cannot move a single lamport, and only the admin can unpause.

What the program enforces, each with its own test:

1. Lamports above rent ≥ unspent(today) + unspent(yesterday): the fund always holds what open days still owe.
2. Draws for a day never exceed that day's budget, happen only the next day before 12:00 UTC, and never touch the current day.
3. The rations for a day never add up to more than that day's budget.
4. A stake that was not in place at both snapshots, a day apart, earns nothing for that day.
5. SOL sent straight to a fund, by the payout account or anyone else, never changes the average inflow.

Every instruction also follows one checklist: owner and type checks on every account, canonical addresses, signer checks for every role, typed calls only into fixed program ids, a reload after every call before measuring what moved, rent bounds on every lamport move, and no duplicate accounts. Mints with a permanent delegate, a transfer hook, a pause switch, non-transferable tokens or accounts frozen by default are refused for staking and burning.

The formulas, as the program computes them

eligible_stake(a, D) = min( eoda(D − 2), eoda(D − 1) )
eligible_total(D)    = min( EOD(D − 2), EOD(D − 1) )

average_inflow(D) = Σ inflow[D − k] / 7       k = 1…7, days from launch_day on
budget(D)         = min( free, average_inflow(D) ) × budget_bps / 10,000
ration_of(a, D)   = budget(D) × eligible_stake(a, D) / eligible_total(D)
drawable(d)       = budget(d) − drawn(d)      only for d = today − 1, before 43,200 s
lamports(usd)     = ⌈ usd_micro × 103 − expo / price ⌉    Pyth, at draw time

$NOWHERE fees        its router 10,000 of the creator fee pump.fun sets
$NOWHERE router      fund 6,000 · Burner 2,500 · team 1,500
coin trading fee     Meteora 2,000 · our partner config 8,000
coin router          creator 0–5,000 · $NOWHERE Burner 1,000 · fund the rest
payments             upstream 7,700 · Burner 1,540 · team 860 (remainder)
paid price           1.3 × upstream cost

One holder's ration

Suppose a day's budget is B = 27 SOL, the day's price is $105.21 (Pyth price 10,521,000,000, exponent −8) and E = 8.4 million NOWHERE are eligible, the mock figures the Nowhere site uses. A holder with 10,000 NOWHERE eligible is owed

r = 27 SOL × 10,000 / 8,400,000
  = 32,142,857 lamports ≈ 0.0321429 SOL

credited = ⌊ r × 10,521,000,000 × 10−11 ⌋ = 3,381,749 micro-dollars ≈ $3.38

That is about $3.38 of inference at the provider's price, out of a whole budget of $2,841. Since budgets equal 0.9 times the average, a steady budget of 27 SOL implies an average of 30 SOL a day of counted inflow, which at the fund's 60% share means 50 SOL a day of $NOWHERE creator fees reaching its router.

One settlement

Say the next morning's report shows $2,500 of AI, and Pyth reads SOL at $104.00 (price 10,400,000,000, exponent −8) when the operator draws:

lamports = ⌈ 2,500,000,000 × 1011 / 10,400,000,000 ⌉
         = 24,038,461,539 lamports ≈ 24.04 SOL

paid     = min( 24.04 SOL, 27 SOL − 0 ) = 24.04 SOL      nothing drawn yet

The other 2.96 SOL of that day's budget stays in the fund.

Rations never add up to more than the budget

For every account, e_a is at most its stake at the end of D − 2 and at most its stake at the end of D − 1. Summing over accounts:

Σ ea ≤ Σ eoda(D − 2) = EOD(D − 2)      Σ ea ≤ Σ eoda(D − 1) = EOD(D − 1)

Σ ea ≤ min( EOD(D − 2), EOD(D − 1) ) = E     so     Σ ra = B × Σ ea / E ≤ B

Each ration is rounded down, which only widens the gap. The inequality is strict when stake moves between accounts during D − 1: an account that left and one that joined both have e_a = 0, while E still counts the moved stake once. If half the eligible total moved, half the budget goes to no one and stays in the fund.

Launch week

With a constant counted inflow f a day from the launch day L, the average for day L + n is n·f / 7 for 1 ≤ n ≤ 7, so B(L + n) = 0.9 · n·f / 7. For f = 30 SOL:

Recycled SOL cannot amplify budgets

SOL sent straight to a fund never counts, so drawn SOL can count again only by passing through a router. Of x SOL sent to $NOWHERE's router, 0.6x reaches the fund as counted inflow and 0.4x leaves for good, 0.25x burned and 0.15x to the team. The counted part raises each of the next seven averages by 0.6x / 7, adding 0.9 × 0.6x = 0.54x to later budgets. Each loop returns at most 54% of what entered it, so even if every budget so raised were drawn and recycled again, the extra budget from all loops together would be at most

Σk≥1 0.54k · x = 0.54 / 0.46 · x ≈ 1.17x

spread over the following weeks, while 40% of the SOL leaves the system on every pass.

The worst case with a stolen operator key

The key can draw only for yesterday, only before noon, and only what yesterday has not yet drawn:

W ≤ B(D − 1) − drawn(D − 1) ≤ B(D − 1)        one day's budget, to the payout

With steady budgets B, that is at most B, reached by taking the key just after midnight on a day whose predecessor is still unsettled. After that, no more than each day's budget, one day at a time, always to the team's own payout account, until the guardian pauses draws.

Where a dollar goes

• The program: specified, not audited, not deployed. One Anchor program [3], laid out in full in the binding design [5], tested in LiteSVM against the real Meteora and pump.fun programs, with Surfpool forks of mainnet for end-to-end scenarios, $NOWHERE's launch on pump.fun and its move to PumpSwap included. It runs only on local validators and forks, and it must not hold real value before a security review.
• Services: built and tested locally, moving to Solana. The gateway, the keeper and the Telegram channel run in workerd. On Solana they read the chain through @solana/kit and a client generated from the program's interface, and sign users in with Sign-In With Solana.
• Nothing is live. No address is final, the launchpad ships paused, and everything on the Nowhere site is mock data.

Read these before you stake anything.

• pump.fun. $NOWHERE's fees and burns run through pump.fun's three programs: the bonding curve, PumpSwap and Pump Fees. pump.fun sets the fee tiers and can change them, so the creator fee can shrink. A single upgrade authority controls all three programs, and pump.fun has changed its trade interfaces before. A breaking change stops the fee crank and burn_pump until our bindings catch up; it cannot move funds, because a failed call reverts the whole instruction. A malicious or broken upgrade could take at most the SOL of one burn, or stop paying the router. A full curve trades again only once it migrates; if pump.fun does not migrate it, our keeper runs migrate_v2.
• pump.fun's admin. pump.fun can reassign a coin's creator and its fee sharing with admin_cto, a "community takeover", even after the right to edit the routing was revoked, and so send $NOWHERE's creator fees elsewhere whatever the program checked at registration. The keeper sees it on its next run and stops cranking. The program cannot prevent it.
• Meteora. Every launched or plugged-in coin's fees come from Meteora's Dynamic Bonding Curve and DAMM v2 programs. Meteora keeps 20% of every trading fee on our config, and its programs and terms are Meteora's to change. A finished curve trades again only once it migrates; if Meteora's keepers do not migrate it, ours runs the open migration.
• One provider. All AI comes from Venice. If Venice is down, calls fail and are not charged; if it changes its terms, its prices or its privacy policy, or cuts access, Nowhere has no fallback today.
• Provider terms. Venice's terms license API use "solely for your personal, non-commercial use" in one clause, set duties for products built for end users in another, and bar selling or transferring the access granted. Whether a staking-funded gateway fits is an open question for counsel.
• Pyth. Each draw is priced by one Pyth feed. If the price is older than 120 seconds or its confidence band is wider than 1%, the draw fails and the keeper retries; a day it cannot settle by noon stays in the fund, unpaid. The gateway's daily dollar price comes from the same feed.
• Trust in the gateway. The program bounds what the operator can draw, not what it buys. The reports make misuse visible after the fact, not impossible.
• Pools and keys. Thin pools and slippage on burns and conversions are capped, throttled and sent privately, not eliminated. The operator is a hot key, the program is unaudited and upgradeable behind its time lock, and off-chain services can fail. A day not settled by noon the next day is never paid. The guardian can stop everything; it cannot fix anything.
• No promises. Nothing here is a promise of a price, a return or a minimum amount of AI. Rations follow trading, and trading can stop.

We cut these to keep version one small. None of them is built or promised. Some could be added next to the current program; others, like the pay-per-call market, would need new instructions in it.

• Verifiable receipts. Models served in hardware enclaves (TEEs) that sign every answer, with the signatures rooted into each day's report.
• More providers. Other private hosts and models next to Venice, so one outage or one change of terms does not stop the service.
• AI-stock pairs. Coins paired with tokenized stocks such as NVDA, or with stablecoins, converting their fees to SOL.
• Stablecoin savings. Stake USDG or USDC in a lending vault and let only its interest fund the rations.
• An agent pay-per-call market. Unspent budget sold per call to agents with no account, for example over x402, every payment burning $NOWHERE.
• MCP. A remote Model Context Protocol server, so agents can use their ration as a tool.
• Paying with other tokens. Credits bought with SOL or tokenized stocks, not only stablecoins.
• The Compute Reserve. A treasury of tokenized NVDA, MSFT and GOOGL that would refill the fund from its own gains, as an idea only.

The AI stocks are already on-chain. Nowhere puts the AI there too: a daily allowance of it, for people and the agents that work for them, sized by a formula anyone can run and served by private models that keep no prompts. Ask it anything. It goes nowhere.

The pieces are deliberately few. Fees enter a fund whose daily budget is a fixed share of its average counted inflow. The budget is divided among stakers by a rule that is final when the day begins and that staking around a snapshot cannot game. The operator can settle each day once, the next morning, only to a fixed account, at Pyth's price of that moment, and only by committing to a signed, published report. The gateway remains trusted, but what it can take is bounded by the program at one day's budget, and what it did is on-chain for anyone to check. Paid usage and every coin burn $NOWHERE, for real, and any coin on the launchpad can give its holders the same deal.

No new chain. No miners. Just AI you're owed, and proof.

1. Phantom, "Sign In With Solana," specification, and the Wallet Standard solana:signIn feature. github.com/phantom/sign-in-with-solana
2. Meteora, "Dynamic Bonding Curve" and "DAMM v2": documentation, source and IDLs, read October 2026. docs.meteora.ag
3. Anchor, the Solana program framework, version 1.2.1. anchor-lang.com
4. Pyth Network, "Price Feeds": SOL/USD, sponsored push account 7AviUf9nL62mcxNbQGKm4nKDQnPjswo6c5MX4D57HmyE, feed id ef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d. docs.pyth.network/price-feeds
5. Nowhere on Solana, the program design, Revision 8 (binding): docs/solana-design.md.
6. Nowhere off-chain services, interface spec: docs/gateway-spec.md, superseded by [5] wherever the two differ.
7. Nowhere service documentation: gateway/README.md, gateway/docs/providers.md (Venice research, 17 October 2026), keeper/README.md, channels/README.md.
8. FLOP Network, project site and testnet page, October 2026. flop.finance
9. Squads, "Squads Protocol v4," multisig with time locks. docs.squads.so
10. Venice, "Privacy" overview, model list and Terms of Service. docs.venice.ai/overview/privacy · venice.ai/privacy · venice.ai/legal/tos
11. Solana, "Tokens": SPL Token and Token-2022, including burn_checked and transfer_checked. solana.com/docs/tokens
12. Stablecoin mints accepted for paid usage: USDG (Token-2022) 2u1tszSeqZ3qBWF3uNGPFc8TzMk2tdiwknnRMWGWjGWH, USDC (SPL Token) EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, PYUSD (Token-2022, optional) 2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo.
13. pump.fun, "pump-public-docs": the bonding curve, PumpSwap and Pump Fees programs, creator fees, fee sharing, migration and IDLs, read October 2026. github.com/pump-fun/pump-public-docs