How it works

Three independent assets

Item	Where it exists	What determines its value or availability
Tradable token	Solana or Robinhood Chain	Supply, liquidity and market trading
API price snapshot	Community registration record	The published model tariff observed at registration
Community API budget	Operator accounting database	Activated provider funding minus reserved and settled usage

The token and service budget are distinct. A holder has conditional service access; holding tokens does not give a transferable share of the operator’s treasury. This product specification is not a legal classification.

Connect an existing token

Choose a model, paste an existing Pons/Robinhood or Solana address, connect a wallet and configure holder access. Registration reads token metadata and saves the model identifier, published input/output rates and observation time. It does not ask for a new token name, ticker, image or mint transaction.

A Solana mint may not supply a readable name through its mint account, so the registration form accepts display labels. These labels do not mint or rename the actual token. Robinhood ERC20 names and symbols are read from the contract.

The model snapshot is a fixed record. It does not change the existing pool price or fix future provider bills. There is no live price oracle or automatic repricing mechanism.

Community flow

An operator registers an existing token, sets its holder threshold and chooses budget limits. Registration reads token metadata but does not prove that the registrant is the issuer. Each community has a distinct registration ID; registration does not verify issuer affiliation.

A funding wallet contributes native cryptocurrency to the configured treasury. The app verifies the exact transaction and records an awaiting-provider deposit. The operator converts funds as necessary, tops up OpenRouter and allocates verified available credit. Only then does the community budget increase.

Request flow

The user signs in, accepts the current terms and checks their wallet. An eligible holder creates a personal API key or uses the playground. Each inference request checks the holding threshold again, reserves budget atomically and forwards a bounded request to OpenRouter.

Successful billing returns the unused reservation. Unknown cost or interrupted streaming leaves the reservation held for investigation. A second API key does not create a second allowance for the same wallet in the same community.

What happens when conditions change

If the user sells below the holding threshold, subsequent requests fail eligibility checks. Previously issued keys do not override this. If the shared budget is exhausted, requests stop. A model may be repriced or removed; its registration snapshot remains unchanged, while new inference requests use current available tariffs.

The threshold is wallet-based, not person-based. A person who splits qualifying holdings across several wallets may obtain several allowances. No proof-of-personhood or anti-Sybil guarantee is implemented.