Xava Inference

1How you earn, in plain words

This section is for anyone, with no background in crypto or AI. The technical sections that follow say exactly how each step works and how to check it.

1. You hold $XINF. $XINF is a token on Solana, paired with USDC. You buy it and keep it in your wallet. There is nothing to stake and nothing to lock up. To earn AI credits, hold at least 1,337 $XINF on average over each hour.
2. The 3% Hold Rewards Tax pays you USDC, automatically. Every time anyone transfers $XINF, 3% is withheld. The launchpad, StonkFun, converts it to USDC and pays holders in USDC, in proportion to what they hold. It arrives in your wallet every few minutes on its own.
3. The lock's earnings become AI credits you claim weekly. A third of all $XINF was bought at launch into a permanent lock that can never sell, and our buybacks keep adding to it. The lock earns its share of the tax in USDC like any holder. Part of that USDC (the autobuy share, 30% at launch, never more than 70%) buys $XINF back into the lock; the rest goes into a public reserve and becomes AI credits for $XINF holders, shared by how much you held and for how long. Once a week you claim them with one click, within 30 days.
4. Spend them on any model with one key. One credit is one dollar of AI usage. Credits work with every text, image, video and audio model in the catalog through one API key. They cannot be sold or cashed out. Earned and promotional credits expire after 365 days unused; credits you buy don't expire.

1.1A worked example (illustrative)

The numbers below are made up to show the arithmetic. They are not a forecast: real amounts depend on trading volume, prices and how many people hold.

If you do not claim a week's credits within 30 days, or do not use claimed credits within 365 days, they are burned. Nobody keeps them: their USDC goes 50% to $XAVA stakers and 50% to $XINF buybacks locked forever (section 3).

1.2The second pillar: every prompt buys back your token (0.5% to 2%)

The same credits buy inference for anyone, holder or not. You top up with a card or USDC, get one key for every model, and pay each model's list price. Every time you spend, 0.5% of it buys back a token you pick ($XINF by default), out of our margin. Hold 1,337 $XAVA or 1,337,000 $XINF and you reach Elite: lower Elite prices and a bigger buyback. What we earn on the rest buys $XINF for the lock and pays $XAVA stakers (sections 5 to 8).

1.3The whole flow, in one picture

2$XINF and the protocol lock

2.1A reward coin, paired with USDC

$XINF launches on the StonkFun launchpad (stonks.fun) as a reward coin: a Solana Token-2022 mint with a 3% transfer tax, paired with USDC. We call it the 3% Hold Rewards Tax: every $XINF transfer pays holders in USDC. The tax is withheld in $XINF on every transfer, including a move from one wallet to another. StonkFun sweeps it, converts it to USDC in the $XINF/USDC pool, and pays holders pro rata to their balance, in USDC, every few minutes.

• Payouts are snapshot-based: each cycle reads balances at that moment. There is no holding-time weighting.
• Trading pools, the bonding curve, burned supply and the launchpad's own wallets are excluded. Their share is not lost; it goes to the holders who are paid.
• Holders do nothing: there is nothing to stake or claim to receive the holder rewards.
• The distribution is operated by the launchpad, not by us. Its rules include a minimum payout per holder per cycle.

The tax applies to our own transfers too. Buybacks therefore swap directly into the lock's token account, so that each purchase pays the tax once rather than twice.

Why USDC. Rewards in a dollar stablecoin need no further swap: the credits share of the lock's USDC goes straight into the credit reserve, one credit per dollar, with no price risk between earning and minting. Reward coins on StonkFun paired with USDC pay their holders in USDC.

2.2The protocol lock

The protocol lock holds $XINF that is never sold:

• 33% of supply bought at launch as the creator's first buy, announced in advance, and deposited into the lock.
• Every buyback afterwards: the autobuy share of the lock's own USDC (section 2.4), the 50% $XINF half of every burn (section 3), and the buyback of every account that picked $XINF as its buyback token (section 7).

There is no separate team purchase or team allocation of $XINF: the launch buy goes entirely into the lock.

The lock is allowlisted by StonkFun and earns its share of the tax in USDC, like any other holder. That USDC is moved into the credits program's intake, where it is split between $XINF buybacks into the lock and AI credits for $XINF holders (2.3, 2.4). The lock does not earn for us, and nothing it holds is available to the team or to operations.

The lock runs no code of our own. It is a sealed Squads v4 vault: a multisig set up so that no key can ever govern it, built only from existing, audited software that can no longer change (the Squads v4 program, whose upgrade authority is none, and Token-2022).

• A keyless member. Its only member is an address that provably has no private key (it is derived by a public formula and lies off the ed25519 curve), with a threshold of one, and its config authority is set to none. No proposal can ever be created, approved or executed and no setting can ever change, so nothing, and no one, can move locked $XINF out.
• One fixed path for rewards. A single Squads spending limit, set before sealing, lets a short published list of executor keys move only USDC, and only to one destination: the credits program's intake account (its intake PDA), from which each weekly list is funded. It can move nothing else, and it can never be changed.
• Sealed in one transaction. The multisig is created, given that spending limit and handed its keyless configuration in one atomic transaction. The temporary setup key has no power left afterwards.
• Anyone can verify it. A public script with no dependencies reads the chain and checks the Squads program's upgrade authority and bytecode hash, the keyless member, the missing config authority, the single spending limit with its mint and destination, and the $XINF mint's extensions.

2.3AI credits for holders

The USDC the lock receives is moved into the credits program's intake. After the autobuy share (2.4), the rest funds credits for $XINF holders, backed by USDC in the reserve. Each hour's pool is exactly the USDC the lock received that hour that was routed to credits. Holders do nothing to earn them; they spend them on any model in the catalog. See /rewards.

• Hourly. Credits are shared out per hour, by each wallet's time-weighted balance over that hour (its average balance across the window), so buying just before a snapshot earns almost nothing.
• A minimum floor of 1,337 $XINF. A wallet earns only if its average balance over the hour is at least 1,337 $XINF. Eligible wallets share the hour's pool pro rata by that time-weighted balance (token count is the weight); the weight of wallets below the floor, and of excluded addresses, goes to the eligible wallets.
• Excluded addresses. Trading pools, the protocol lock and the launchpad's wallets earn nothing; their weight is shared among eligible holders.
• Claimed weekly, never automatic. Credits accrue to the holding Solana wallet every hour. Once a week they are put on a published claim list; the holder signs in with that wallet and claims them in the dashboard with one click. Each weekly list is funded from the program's intake by create_claim_list; claiming (claim(list)) mints non-transferable credits into a dated lot on the account, against USDC already in the reserve. Nothing is added to a balance without a claim.
• 30-day claim window. Each week's list can be claimed for 30 days after it is published, so several lists can be open at once and one click claims them all. Credits not claimed within 30 days are burned: with no inference cost behind them, their full USDC goes 50% to $XAVA stakers and 50% to $XINF buybacks into the lock (section 3.4). Nothing goes back to us.
• 365-day expiry. Claimed holder credits expire if they are not used within 365 days (section 3.5).
• For using models. Holder credits are backed by USDC but are not redeemable for cash and cannot be transferred or withdrawn.

2.4The autobuy split

The lock's USDC is split on-chain, by the credits program, before any of it becomes credits. An autobuy share of 0 to 70% (30% at launch) goes to a fixed autobuy wallet; the rest stays in the program's intake and funds the next weekly holder claim list.

• route_intake(amount). Anyone can call it, after each move of the lock's USDC into the intake. It sends amount × autobuy_bps / 10,000 (rounded down) to the autobuy wallet's USDC account and leaves the rest in the intake; any rounding remainder stays with holder credits. It emits one public event with both legs.
• The autobuy wallet buys $XINF for the lock. Right after the launchpad's sweeps, the executor buys $XINF with that USDC in the main $XINF/USDC pool, in small slices, and delivers it straight to the lock's $XINF account, where it can never move again. The wallet's address is set at launch and can change only through the program's timelocked admin.
• The rest becomes holder credits. It is escrowed from the intake by create_claim_list for the week's list, claimed within 30 days (section 2.3).
• A hard cap of 70%. The program rejects any autobuy share above 7,000 basis points, from every path, so at least 30% of the lock's USDC always funds holder credits.
• Set by a public controller multisig. Only a separate controller, a public Squads multisig (not the program's admin), can change the share, with set_autobuy_bps. A new share waits 24 hours; the pending value and the time it applies are visible on-chain, and every change is a public event.
• Control can move. The controller can hand control to another address, for example a governance program, in two steps: propose_controller, then accept_controller signed by the new address (a program signs by invoking it with its own address). A proposal can be cancelled before it is accepted.

3Credits and reserves

3.1What a credit is

A credit is $1 of prepaid inference. Credits are a non-transferable Token-2022 token on Solana: they sit on an account and can be spent, but not sent, sold or cashed out. Every credit is backed one for one by USDC held in a public credit reserve, and the reserve always holds at least the credit supply.

3.2Minting: only against USDC

Credits can only be minted against USDC deposited into the reserve. The credits program enforces this; there is no other way to create them.

• USDC top-ups: a deposit to your address mints credits once the transfer is final.
• Card top-ups: your balance shows the credit once the payment has cleared, and the credits are minted when the matching USDC reaches the reserve.
• Holder credits: the USDC the lock receives, minted when a holder claims (section 2.3).
• Affiliate credits: minted against the USDC set aside from the margin (section 8).

3.3Burning: hourly, by a fixed split

Usage is metered live against your balance, so a request never waits for the chain. The off-chain meter is only a buffer of usage not yet settled: every hour, the settled usage is burned in one batch. Each batch commits to the head of the hash-chained usage log (section 10) and is published with its own fingerprint. When credits burn, the program releases their USDC only by a fixed split:

There is no team share. If a batch's margin is negative, nothing is split and the next batches repay the difference first.

3.4Unclaimed credits: burned after 30 days

Holder credits not claimed within 30 days of their list are burned. There is no inference cost behind them, so their whole USDC goes through the 50/50 split: 50% to $XAVA stakers and 50% to $XINF buybacks into the lock.

3.5Unused credits: burned after 365 days

Earned and promotional credits expire after 365 days unused; credits you buy don't expire. By default the expiry applies to claimed holder credits, affiliate credits and promotional credits. Credits bought with a card or USDC never expire: the credits program exempts them whatever the configuration. Each other source has its own switch, which can only narrow the expiry further, and any change is published.

• Lots. Every time credits arrive on an account, they form a lot with its date and its source.
• Expiring credits first. Requests spend your expiring credits first, oldest first, so they rarely go unused; credits you buy are used after them. Within each group, the oldest lot is used first (first in, first out). A refund takes back the newest lot first.
• Expiry. Whatever is left of an earned or promotional lot 365 days after it arrived is burned. With no inference cost behind it, its whole USDC goes 50% to $XAVA stakers and 50% to $XINF buybacks into the lock. On chain this is the permissionless crank burn_expired_lots: anyone can call it, and the program itself checks each lot's age, so nothing young can be burned.
• Warnings. Your dashboard shows "$X expires on <date>" 30, 7 and 1 days before a lot expires. Credits that do not expire never show a warning.
• Published. Expiry runs as one batch per UTC day, published with its fingerprint beside the other burn batches: the accounts (by pseudonym), the lots, the amounts and the split.
• Configuration. CREDIT_EXPIRY_DAYS (default 365) and CREDIT_EXPIRY_SOURCES (default holder_claim,affiliate,promo). Purchased credits never expire on chain whatever this setting says; the switch only narrows the expiry further.

3.6Proof of reserves

The reserves section of /buybacks shows the credit supply next to the reserve's USDC, and every burn batch (spent, unclaimed and expired) with its hash, its usage-log segment and its split. Anyone can check that the reserve covers the supply and that each batch adds up.

4Rewards for $XAVA stakers

$XAVA is the token of Avalaunch, a launchpad on Avalanche. Half of every burn goes to $XAVA stakers in USDC: 50% of the margin when credits are spent, and 50% of the whole USDC of unclaimed and expired credits. It is weighted by stake, by time and by how long each part of the stake has been held. Stakers keep staking where they already stake, and claim on Solana.

4.1Who is eligible

• Only $XAVA staked in the Avalaunch staking contract on Avalanche C-chain counts.
• Weight is the stake the staking contract itself credits to an address, including compounded stake, read from its own accounting.
• Holding $XAVA without staking, $XAVA on other chains, and bridged $XAVA do not count.
• No exclusions. Every staker in the staking contract's pool 0 counts, by the same formula, including Avalaunch's own wallets and stakers that are contracts.

4.2Time-weighting and the loyalty multiplier

Every staker's stake is kept as tranches. Each deposit, and each compound that increases the stake, starts its own tranche at age 0. A tranche's multiplier rises in a straight line from 1x at age 0 to 3x at 180 days, and stays there. A partial withdrawal removes the youngest tranches first, so older tokens keep their age and multiplier; a full withdrawal clears every tranche. A stake transfer moves the tranches with the stake, unchanged.

m(age)  = 1x + (3x − 1x) × min(age, 180 days) / 180 days
w_i     = Σ over hours h in the week of  Σ over tranches t of i  (min amount of t during h) × m(age of t at h)
share   = w_i / Σ_j w_j
claim   = share × USDC released to stakers that week (spent, unclaimed and expired credits)

A deposit made late in an hour starts counting from the next full hour, so staking for a moment before a list is cut earns nothing. Tranches make the multiplier hard to game: keeping a tiny amount staked for months and then depositing a large amount gives the large amount a fresh start at the lowest multiplier.

Weighting starts at a snapshot of every staker taken when the program starts; each staker's stake at the snapshot is one tranche at age 0. From then on every deposit, withdrawal, compound and stake transfer is replayed from the staking contract's public events, so the tranches can be rebuilt by anyone, and the replay is reconciled each day against a live read of the contract.

4.3Publication: daily weights, weekly lists

Every day the stake weights, including each staker's multiplier-weighted total, are published with their fingerprint. Once a week the claim list is computed and published:

1. It reads the USDC released to stakers by that week's burn batches and each staker's tranches on Avalanche C-chain.
2. It computes every staker's USDC amount for the week and cumulative entitlement, and builds a merkle tree over one leaf per staker address that has a linked Solana wallet.
3. It publishes the full list, the merkle root and a fingerprint chained to the previous week's list, so anyone can recompute them from public data; the root is also posted on Solana.
4. Funding of the distributor is delayed by several hours after publication, so an independent watcher can recompute the list and veto a wrong one before any funds move.

4.4Claiming

1. Sign in with the Avalanche wallet you stake from (Sign-In with Ethereum). That wallet only proves the stake; it never receives funds.
2. Link a Solana wallet. You sign one plain binding message, "this Avalanche address pays to this Solana address", with both wallets.
3. A first link applies at once and is used by the next weekly list. A change to an existing link takes effect after 48 hours, so a stolen session cannot silently redirect rewards. Both signatures are published with the link.
4. Claim each list's USDC on Solana, within 30 days of its publication.

4.5The 30-day claim window

Each week's list can be claimed for 30 days after it is published, the same window as holder credits. USDC not claimed in that time, a list's rounding remainder and the lines of stakers with no linked Solana wallet are added to a later week's staker pool and shared by the same formula. Nothing goes back to us.

5AI inference at list price

The second pillar is the product the credits are spent on. Inference is a large and recurring cost for anyone building with AI models, and it is fragmented: a team using a text model, an image model, a video model and a speech model typically holds four accounts, four keys and four invoices. We put every model behind one key and one balance, at each model's list price, and turn part of every spend into buybacks of a token the buyer picks.

5.1One key, every model

One API key reaches every model in the catalog: text and reasoning models, embeddings, image generation, video generation, speech, transcription and music. The API is OpenAI-compatible, so an existing SDK needs two changes: the base URL and the key. Image, video and audio models use the same key and the same balance.

Models are presented by maker and name. A request goes to the model it names. Nothing is swapped, downgraded or quietly rerouted to a cheaper model.

5.2Prices

Every model has its list price: the model maker's own published price, synced from the catalog. Everyone pays the list price. Elite accounts (section 6) pay the model's Elite price instead: the list price minus that model's Elite discount. There is no markup and no platform fee on top.

5.3Routing and retries

Every request is served from our own inference account upstream. If the upstream fails before a text response starts (a server error or a dropped connection), the request is retried once, so a caller sees a result rather than an outage. Once a streamed response has started it is not retried, so a caller never receives the first half of one answer and the second half of another. Media generations are never retried, because a timed-out generation may still complete and bill upstream.

5.4What we store

We never store the content of requests or responses, and request and response bodies are never logged. Whether the model provider keeps anything depends on the model: on models marked ZDR supported, neither we nor the model provider store prompts or outputs; on other models the model provider's own retention policy applies. Generated images, video and audio, and reference files you upload, are kept at a private link for 24 hours, then deleted automatically. Per request we keep billing metadata only: the model, token or unit counts, the price charged, the actual cost, timing, status and the key used. That metadata is what the public ledger in section 10 is built from, under a pseudonym.

5.5Agents

The same API is available to AI agents through plugins for common coding agents and a remote MCP server. Coding agents sign in once and spend the account balance within a daily cap; agents that already pay through a wallet provider with spending policies can pay per call for media models with x402 (section 12).

6Reward Status

Reward Status is for the people who hold the ecosystem's tokens. It has two tiers: every account starts as Noob, and an account is Elite while one of its linked wallets holds either:

• 1,337 $XAVA on Avalanche C-chain: the wallet's $XAVA balance plus its credited stake in the Avalaunch AllocationStaking pool 0 (the staking contract's own accounting; pending, uncompounded earnings do not count). The wallet is linked by signing a message with it (no transaction).
• 1,337,000 $XINF on Solana, in a wallet the account signs in with.

One wallet has to clear the bar on its own; holdings are not added across wallets. The status is cached per account: it is checked when a wallet is linked and again every 15 minutes. If a check fails (for example an unreachable node), the previous status stands until a check succeeds.

6.1What Elite gives

• Elite prices. Each model has an Elite discount, set per model by the operator (the default is 10% off the list price; it can be set in bulk by maker or category). The catalog shows the list price and the Elite price side by side.
• A bigger buyback. 2% of every spend buys back $XINF, or 1.5% if the account picked a custom token, instead of 0.5% (section 7).

6.2Never below cost

An Elite price may never be lower than what the model actually costs us. Every model's Elite discount is capped at 100% minus its trailing actual cost: the cost the upstream reported for that model's requests over the last 30 days, as a share of their list price. A model with no reported cost yet is assumed to cost its full list price, so it has no Elite discount until real cost data shows room for one. The cap is applied when the operator saves a discount and again on every request, so an Elite price that the trailing cost no longer supports falls back automatically.

7The buyback token

Every account picks one buyback token: $XINF by default, or any eligible Solana token. A share of everything the account spends buys it back. The share comes out of our margin, never on top of the price.

7.1Capped at the margin

The buyback of a request is its rate times what the request was charged, but never more than that request's margin (the charge minus its actual cost). If the margin is smaller, the buyback is whatever the margin allows, and if the margin is zero or negative there is no buyback for that request. The capped cases are logged. The credits program enforces the same rule on chain: in every burn line the cost plus the buybacks can never exceed the amount burned, and the buybacks never exceed 2% of it.

P = list price, or the Elite price for Elite accounts
C = actual cost of the request (section 8.1)
B = min(rate × P, max(0, P − C))      your buyback
M = P − C − B                          the margin left for the burn split

7.2Buybacks accrue from settled spend only

A buyback accrues when the request that funds it has settled and been paid for. Picking a token carries no weight on its own: an account that spends nothing contributes nothing. The community leaderboard on /buybacks ranks tokens by the dollars actually directed to them from settled spend.

Accruals are pooled per token and executed on-chain in batches through Jupiter. A custom token must pass eligibility checks before it is bought: no freeze authority, no risky token extensions, a working route and a minimum liquidity. Until it passes, its accrual waits in dollars; it is never lost.

Custom tokens bought this way are held in a public vault address controlled by the treasury multisig. They are not distributed to users.

7.3x402 callers

Callers that pay per request with x402 have no account, so they pay the list price and name their buyback token with the call: a header X-Buyback-Token: <mint> (or a buyback_token body field). Without one, the token is $XINF. The rate is the base rate, 0.5%, and the token is bound into the payment requirements, so a payment made for one token cannot be replayed for another.

8Margin and the burn split

8.1Margin from actual cost

Our margin on a request is what it was charged minus what it actually cost us upstream, request by request. Nothing about it is configured:

• Reported cost. Where the upstream response itself reports the billed cost (compute-unit models report their units, and some providers report their cost inline), that is the request's cost.
• Trued up from the billing log. Where it does not, the request is first recorded at its catalog list cost and flagged as estimated. The upstream's billing log records the cost of every request under our own request id; every 5 minutes, before an hour is sealed into the usage chain and burned, each estimated request is replaced by its billed cost and its buyback and margin are recomputed. The price the user paid never changes.
• Still estimated. A request the billing log does not show in time keeps its catalog estimate and stays flagged in the ledger.

Margin is released only when credits are burned for settled usage (section 3.3), never at top-up: unspent credit is still owed to its holder. Card and payment costs are covered by the posted card price (section 12).

8.2The split

After the user's buyback, the margin is split by the credits program at every burn: 50% buys $XINF into the protocol lock and 50% goes to $XAVA stakers in USDC. There is no team share. If the account that generated the margin was referred by an affiliate, the affiliate's cut comes out of the $XINF half: never out of the stakers' half.

An affiliate choosing credits receives twice the cash rate, and the buyback is reduced accordingly. Their credits are minted against the USDC set aside, like any other credit.

8.3Worked example

An illustrative request at a list price of $1.00 whose actual cost is $0.80, with $XINF as the buyback token:

An illustrative set of burns releasing $1,000 of margin:

The figures are examples of the arithmetic, not a forecast of cost or margin.

8.4The operations account

The inference-cost leg of every burn goes to an operations account, which pays for the capacity used. Refunds and chargebacks burn the affected credits and release their USDC back to operations to fund the refund.

9Weekly promotions

Each week we may announce extra price cuts on specific models for $XAVA stakers. A promotion names its models, the extra cut, and when it starts and ends. Current promotions are marked "this week" in the catalog and on the home page.

• For $XAVA stakers only. An account qualifies when it has a linked Avalanche staking wallet whose credited stake is above zero. The check reads the indexer's latest stake, which updates every 5 minutes and is cached for up to 5 minutes, so a new stake qualifies within about 10 to 15 minutes, and a full withdrawal stops qualifying within the same time.
• Funded from our margin. The extra cut comes out of our margin and is capped at each request's own margin (its charge minus its actual cost), so it can never push a request below cost.
• A plain price cut. It lowers what you pay, on top of any Elite price; the buyback is then taken from what is left.
• One at a time. When several promotions cover a model, a request gets the best one it is eligible for, never the sum.

10Verifiability

Requests are metered off-chain and settled on-chain in hourly burns, so every claim has to be checkable from outside. Each claim below has a public artefact and a way to check it.

10.1The usage log

Every settled request becomes an entry in an append-only, hash-chained log. Each entry commits to the previous one, so no entry can be changed, removed or reordered without breaking every hash after it.

hash_n = sha256(0x04 ‖ "xava-usage-v1" ‖ hash_(n−1) ‖ u64le(n) ‖ canonical row_n)
account pseudonym = first 32 hex of sha256("xava-acct-v1|" + account id)

Rows carry the account pseudonym, never the account. Once a day the chain head and a merkle root over the day's allocations are posted on Solana with an SPL Memo from a dedicated attestation key:

xava-audit v1 <day> seq=<first>-<last> head=<hash> root=<root>

10.2Public exports

• The daily audit export: the chained rows, per-pseudonym spend and accruals, per-token allocation leaves, the merkle root and the spend bound, at /api/audit.
• Every buyback batch with its transaction, the per-token totals and the vault balances, at /buybacks. Each batch links to the audit period it was planned from.
• The credit supply, the reserve's USDC and every hourly burn batch with its hash, usage-log segment and split, at /buybacks (section 3.5).
• The daily stake weights (with the loyalty multiplier) and the weekly USDC claim lists with their merkle roots (section 4.3), and every wallet link with both signatures, from /rewards.
• The weekly lists of holders' AI credits, each chained to the previous list (section 2.3).

10.3The watcher

An open-source watcher recomputes the chain, the totals, the merkle roots, the spend bound and the plan hashes from the exports, and optionally checks the memos and swaps on-chain. It exits with an error on any finding. It is meant to be run by people who are not us; going live requires that a second party runs it first.

10.4Bounds in code

• Cumulative user buybacks can never exceed cumulative settled spend × 30%. With rates of at most 2% an honest ledger cannot come near this bound; it exists to stop a corrupted one.
• Each day's buyback plan is published as canonical text with its SHA-256. The executor refuses any job that is not a line of a plan hashing to that value.
• Only eligible tokens are bought, with per-token caps per run.

11Security and threat model

11.1Custody

• The treasury is a Squads v4 multisig with a time lock. Its USDC vault and its holdings vault are separate.
• The executor's key is not a multisig member. It can only draw USDC through Squads spending limits: fixed daily caps, and a fixed destination.
• Swap output goes directly to the holdings vault or the lock, which the executor's key cannot spend. A transaction that would route output to the executor's own account is refused.
• A pre-approved break-glass transaction removes the spending limits if the key is ever suspected.

11.2The executor

The executor runs as a separate application in a dedicated, locked-down environment with its own keys: no shared data stores with the main application, no public routes beyond a signed health check, and outbound connections only to the main application's job feed, the chains and the swap router. It never reads our database. It re-checks every job against its own configuration: allowlisted vaults, the plan hash, per-job and per-day caps, the spend bound, price impact, slippage and minimum output.

It runs in dry-run until the owner approves going live, after at least a full day of dry runs against the real application and a watcher run by a second party. In dry-run it never reads a secret and never signs.

11.3On-chain programs

We use existing programs: SPL Token and Token-2022, SPL Memo, Squads v4 (for the treasury, and for the protocol lock as a sealed vault, section 2.2), Jupiter and an existing audited merkle distributor. We write one small program of our own: the credits program (section 3), which mints credits only against USDC deposited into the reserve and releases USDC from burns only by the fixed split. It is open source, verifiably built and independently audited before mainnet; nothing goes to mainnet without the owner's approval.

11.4Threat model

12Payments

• Card, at our posted price: $100 of credit costs $105. There is no separate card fee.
• USDC on Solana, credited one for one: $100 of USDC buys $100 of credit, so paying in USDC saves 5%. Each account gets its own deposit address; a deposit is credited once the transfer is final.
• Either way, credits are minted only against USDC in the reserve (section 3.2).
• Minimum top-up $5.00 of credit, by either method.
• Credit is prepaid, is not redeemable for cash, and is spent per request at the prices shown when the request is made.

12.1x402 for media

Agents can call image, video and audio models with no account through x402: the first call returns 402 Payment Required with an exact price quoted from the request (model, and the meters that request uses), and the agent retries with a USDC payment on Solana signed by its wallet provider, within that provider's spending policies. Because the price is exact, there is no overpayment to refund or hold. Text and streaming models use an API key.

13Open items

The following are to be finalised before launch. We state them because a design is only as credible as its unresolved parts are visible.

14Risks and disclaimers

• Utility token. $XINF is a utility token. It is not a share, a debt or a claim on Xava Inference or its revenue. Nothing in this paper is investment, legal or tax advice.
• No guarantee of rewards. Holder rewards exist only while $XINF is transferred, and depend on a launchpad we do not control. What the lock earns, and so the AI credits for holders, may be small or zero. What $XAVA stakers receive depends on our margin, which may also be small or zero. Holder credits are for using models, not money.
• The launchpad controls the lock's rewards. StonkFun's contracts are not immutable. The 3% tax rate, and whether the lock's address is included in holder distributions (an allowlist), are controlled by StonkFun and may change or stop at any time. Either would change or stop the lock's rewards, and so the AI credits for $XINF holders.
• How the tax is paid out. StonkFun converts the collected tax to USDC by selling $XINF in the pool, which can affect the price.
• The autobuy share can change. The controller multisig can set the share of the lock's USDC that buys $XINF anywhere from 0 to 70%, after a 24-hour delay. A higher share means fewer holder credits, a lower share fewer buybacks. Buys go through the same pool and pay the same tax.
• Lock rewards can get stuck. The lock can move its USDC only through one fixed Squads spending limit. If every executor key were lost, the USDC would stay in the lock for good and holder AI credits would stop. Locked $XINF is unaffected.
• Claim within 30 days. Rewards not claimed within 30 days of their list expire. Unclaimed holder credits are burned through the 50/50 split; they are not paid to the holder.
• Credits can expire. Earned and promotional credits expire after 365 days unused; credits you buy don't expire. Expired credits are burned through the 50/50 split and are not refunded.
• Reserve and credits. Credits are only as good as the USDC behind them and the program that guards it. USDC itself depends on its issuer. Until the credits program is live, the reserve figures are not yet on-chain.
• Third parties. The design relies on Solana, Avalanche, the launchpad, the USDC issuer, the swap router, the multisig, the distributor and the Avalaunch staking contract. Any of them can fail, change or stop.
• Smart contracts and keys. Audited code can still have faults, and keys can be lost or stolen. The limits in section 11 reduce these risks; they do not remove them.
• Regulation. Rewards linked to a business's revenue may be treated differently, including as regulated products, depending on jurisdiction. Participation may be restricted where you live, and the design may change to comply with law.
• Draft. This paper describes the design as of its date. Parameters marked as current can be changed by the operator, and changes will be published.

15Glossary

list price

the model maker's own published price; what everyone pays

Reward Status

an account's tier: Noob by default, or Elite

Elite

an account with a linked wallet holding 1,337 $XAVA (balance plus credited stake) or 1,337,000 $XINF

Elite price

the list price minus the model's Elite discount; never below the model's trailing actual cost

actual cost

what the upstream billed us for a request: reported in the response, or trued up from its billing log, else the catalog estimate (flagged)

buyback token

the token a share of every spend buys back: $XINF by default or a custom token; 0.5% of the spend, Elite 2% ($XINF) or 1.5% (custom), out of the margin

credit

$1 of prepaid inference: a non-transferable token minted only against USDC in the reserve

credit reserve

the USDC backing every credit; always at least the credit supply, and public

burn

credits destroyed when they are spent (hourly batches), left unclaimed for 30 days, or left unused for 365 days (earned and promotional credits); their USDC is released by the fixed split

lot

credits that arrived on an account together, with their date and source; spending uses expiring lots first, oldest first, then purchased lots

burn split

cost to operations, the user's buyback, then the margin: 50% $XINF buyback into the lock, 50% to $XAVA stakers in USDC

settled spend

usage that has completed and been paid for; the only source of buybacks

operations account

receives the inference-cost leg of every burn and pays for the capacity used

protocol lock

the $XINF that is never sold: 33% of supply bought at launch plus every buyback

pair asset

USDC, the asset $XINF is paired with; holder rewards and the lock's rewards are paid in it

Hold Rewards Tax

the 3% tax on every $XINF transfer, withheld in $XINF, converted to USDC by StonkFun and paid to holders in USDC

autobuy share

the part of the lock's USDC (0 to 70%, 30% at launch) that the credits program routes to the autobuy wallet, which buys $XINF into the lock; the rest funds holder credits

controller

the public Squads multisig that alone can change the autobuy share (after a 24-hour delay) or hand that power to another address

holder AI credits

the lock's USDC after the autobuy share, shared hourly among $XINF holders at or above 1,337 $XINF by time-weighted balance, claimed weekly

credited stake

the $XAVA stake the Avalaunch staking contract credits to an address, including compounding

tranche

one deposit or compound increase of a stake, aged from the moment it was added

loyalty multiplier

1x for a new tranche rising to 3x at 180 days; withdrawals remove the youngest tranches first

weekly promotion

an extra price cut on some models for a week, for $XAVA stakers, paid out of our margin

reward week

Monday 00:00 UTC to the next Monday; each week's rewards are published as one claim list

claim window

the 30 days a weekly list can be claimed after it is published

credit expiry

earned and promotional credits left unused 365 days after they arrived are burned; purchased credits do not expire

merkle root

a single hash that commits to a whole list; any entry can be proven against it

watcher

independent software that recomputes everything we publish and flags any difference

executor

the isolated application that executes buybacks and publishes the reward lists

spending limit

a Squads rule letting one key draw a capped amount to a fixed destination

x402

a protocol for paying per HTTP request, here in USDC on Solana

pseudonym

a one-way hash that stands in for an account in public data

Xava

pronounced ex-AH-va