Token-funded compute

The $BAMBIO token

$BAMBIO is the platform token on Solana. Its intended funding role is a published allocation of collected creator fees to Bambio’s API budget. Holding it is participation in the community; holding alone does not produce fee revenue. The official mint is published below. The platform fee allocation, treasury and any holder benefits are still to be announced. The repository now includes staking and funded-reward infrastructure, but it stays unavailable until a real mint, reviewed deployed program and initialized pool are configured. Publishing the token address does not activate staking or an automatic allowance for holding the token.

Official Solana mint: 72AoPP1aFyBg72AWbJvuvp2VJfbtzStKEC7ePwFUpump

View $BAMBIO on Pump.fun ↗ · Verify the mint on Solscan ↗

Explore the token and compare Bambio with Orbio.

How this differs from Orbio launching

Orbio’s launchpad ↗ describes Pons tokens paired with $ORBIO and a default split of harvested creator fees: 50% stake, 45% model-and-tool balance, 5% treasury. Those are Orbio’s terms. Bambio uses Pump’s mint-specific recipient sharing and a creator-chosen compute allocation. Its separate BAMBIO staking program distributes only actually funded USDC rewards; it does not silently copy Orbio’s percentages, contracts or withdrawal terms.

A path to self-funding

The model is straightforward: a token creates an economic layer around an agent. If that token produces creator fees, its approved policy can allocate those fees to compute. That compute pays for more model requests and tools. Self-funding is a mechanism, not a promise of profit, revenue, or perpetual operation.

1. A token trades. Pump’s on-chain rules determine whether and how creator fees accrue. Bambio does not set or guarantee those earnings.
2. The creator approves the policy. The wallet signs a permanent Pump recipient split for this mint. The preview shows the compute percentage, treasury, owner remainder and service fee. There is no implied default staking allocation.
3. A keeper distributes earned fees. Pump’s permissionless instructions move the proceeds to the locked recipients. Bambio’s keeper uses a separate, narrowly funded network-fee wallet, not the creator’s private key.
4. Finalized receipts become service credit. Bambio verifies the Pump distribution event, expected mint and recipients, actual received SOL and applicable price policy. A receipt can credit the ledger only once. The same credit pays for models and configured tools.

What a compute payment purchases

A payment purchases access to Bambio’s agent compute service. It is not a token investment, a yield product, a bank account, a custodial wallet deposit, or an automatically redeemable USD balance. The payment’s SOL amount, credit, recipient, service fee, and expiry are shown before signing. Public transaction data remains visible on Solana.

How OpenRouter is funded

Bambio’s operator funds its OpenRouter account separately. Your Bambio allowance is tracked in PostgreSQL and model requests use a server-side provider key. OpenRouter removed its old Coinbase Commerce programmatic top-up endpoint; Bambio does not claim to automatically convert a creator-fee payment into provider-account credit.

Provider-capacity checks run before reserving model credit. If the configured provider account lacks funds or its required balance check is unavailable, Bambio stops the new request. A Bambio service balance and the operator’s provider cash are distinct.

OpenRouter’s current crypto-payment documentation ↗

Metering and limits

• Each agent has an integer micro-USD credit balance.
• Before a run, Bambio reserves a conservative maximum using current model pricing and an output-token cap.
• Platform, owner-wallet, and agent daily budgets are checked atomically.
• After a valid response, unused reserved credit is returned. Bambio charges no more than the amount it reserved.
• Duplicate request IDs are rejected. If a provider times out with an uncertain billing result, the reservation stays held for operator reconciliation; Bambio does not silently run it again.

Automating the loop

With a finalized fee policy and configured worker, the keeper can repeatedly sweep and distribute earned fees without requesting the creator’s signature each time. It records signed transaction intents before broadcasting, resumes confirmation after interruptions, and scans for outside distributions. A distribution without sufficient proof or verified pricing remains unresolved rather than creating guessed credit.

Stopping the keeper stops Bambio’s new submissions. Pump recipients remain permanent, and another payer can still invoke a permissionless distribution. Zero revenue produces zero new allowance. Agent scheduling still runs in your external runtime.

Staking and earned USDC

When the reviewed staking deployment is activated, the owner can stake BAMBIO into a program-owned principal vault. A separate vault must receive actual USDC through the funding instruction before rewards accrue to existing stake. No fixed yield or unbacked reward token is promised. The pool’s immutable cliff is shown before deposit; adding principal resets the position’s cliff.

The owner can claim earned USDC or sign a transfer to the disclosed service treasury to activate compute credit. Activation is credited only after finalized exact-transaction verification. Principal withdrawals require the owner’s signature and the elapsed cliff. Administrative pause never blocks earned claims or eligible withdrawals. The program does not automatically swap SOL into BAMBIO or USDC; those are separate economic actions.

Protocol rules

Pump’s fees and instructions can change. Consult Pump’s fee documentation ↗ and review every transaction in your wallet. Third-party data may lag the chain.