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. 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% tax pays you NVIDIA, automatically. Every time anyone transfers $XINF, 3% is collected by the launchpad and paid out to holders in tokenized NVIDIA stock (NVDA), 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 the same NVIDIA payouts as any holder. We swap what it earns into USDC, put that USDC in a public reserve, and turn it into AI credits for $XINF holders, shared by how much you held and for how long. Once a week you claim them with one click.
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; they are for using models.

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 60 days, they expire and are burned. Nobody keeps them: their USDC is split between $XINF buybacks for the lock and $XAVA stakers, by the same rule as all spending (section 3).

1.2The second pillar: discounted AI

The same credits also buy discounted inference for anyone, holder or not. You top up with a card or USDC, get one key for every model, and pay less than the model maker's own price. Every dollar you spend is backed by USDC in the public reserve, and part of what we earn on it buys $XINF for the lock and pays $XAVA stakers (sections 5 to 8).

2$XINF and the protocol lock

2.1A reward coin

$XINF launches on the StonkFun launchpad (stonks.fun) as a reward coin: a Solana Token-2022 mint with a 3% transfer tax, paired with tokenized NVIDIA stock (NVDA) (the pair asset). The launchpad collects the withheld tax, sells it for tokenized NVDA, and pays holders pro rata to their balance, in tokenized NVDA, 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 every transfer, including our own. Buybacks therefore swap directly into the lock's token account, so that each purchase pays the tax once rather than twice.

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 50% $XINF half of margin released at every burn (section 8), expired holder credits (section 3.4) and the $XINF share of every account's split (section 7).

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

The lock earns the holder rewards, in tokenized NVDA, like any other holder. What it earns is swapped to USDC into the credit reserve and becomes AI credits for $XINF holders (2.3). The lock does not earn for us, and nothing it holds is available to the team or to operations.

The lock is a minimal on-chain program of our own:

• No withdraw instruction. Nothing, and no one, can move locked $XINF out.
• A permissionless sweep. Anyone can call one instruction that forwards the rewards the lock has received towards the credit reserve (swapped to USDC). It can move nothing else.
• Open source and a verified build, so the deployed program can be checked against the published code.
• An independent audit before mainnet, and then the upgrade authority removed, so the program can never be changed.

2.3AI credits for holders

The lock's tokenized NVDA is swapped to USDC, the USDC is deposited into the credit reserve, and credits backed by it are shared among $XINF holders. Each hour's pool is the USDC value of the NVDA the lock received that hour. Holders do nothing to earn them; they spend them on any model in the catalog. See /earn.

• 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 on /rewards with one click. Claiming mints the credits to the account, against USDC already in the reserve. Nothing is added to a balance without a claim.
• 60-day claim window. Each week's list can be claimed for 60 days after it is published, so several lists can be open at once and one click claims them all. Credits not claimed within 60 days expire and are burned: with no inference cost behind them, their full backing USDC goes through the burn split, 50% buys $XINF for the lock and 50% goes to $XAVA stakers (section 3.4). Nothing goes back to us.
• For using models. Holder credits are backed by USDC but are not redeemable for cash and cannot be transferred or withdrawn.

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 lock's NVDA swapped to USDC, 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.4Expired credits

Holder credits not claimed within 60 days are burned. There is no inference cost behind them, so the whole backing USDC goes through the margin split: 50% buys $XINF for the lock and 50% goes to $XAVA stakers.

3.5Proof of reserves

The reserves section of /buybacks shows the credit supply next to the reserve's USDC, and every burn batch 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. 50% of our margin, released in USDC every time credits burn, goes to $XAVA stakers, 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 (burns + 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 60 days of its publication.

4.5The 60-day claim window

Each week's list can be claimed for 60 days after it is published. 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.

5Discounted AI inference

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, each billed at the maker's standard price. Discounts on that price exist, from volume commitments and capacity that would otherwise go unused, but they rarely reach the developer who pays. We offer that discounted capacity openly, let the buyer decide where the discount goes, and publish the accounting.

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 starts from its standard price: what the model maker charges when you buy direct. Your price is the standard price minus the part of the model's current discount (section 6) that you choose to take as savings (section 7). There is no markup and no platform fee on top of the standard price. When no discounted capacity is available, a model is served at its standard price: 0% off.

5.3Routing and failover

Each request is matched to a liquidity order, and the seller behind that order serves it. If a seller fails before the response starts, the request moves to the next eligible order, and then to standard-price capacity, so a caller sees a result rather than an outage. A seller that answers with a payment or rate-limit error has its orders paused until it recovers. Once a streamed response has started it is not moved, so a caller never receives the first half of one answer and the second half of another.

5.4What we store

We never store the content of requests or responses. Per request we keep billing metadata only: the model, token or unit counts, 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. Agents without an account can pay per call for media models with x402 (section 12).

6The liquidity book

Discounted capacity is posted as orders in a public liquidity book. At launch the only seller is the house, and its orders are set by the operator. Third-party sellers use the same order machinery later, with budgets capped by capacity they have verified.

6.1Orders

6.2Fills

1. A request arrives for a model. Every active order whose scope covers that model is eligible.
2. Eligible orders are sorted best discount first, then oldest first.
3. The request places a hold of its estimated standard-price value against the best order. Holds are taken in one place per book shard, so two requests cannot spend the same budget.
4. The request is served by that order's seller. At settlement the hold is released and the order's remaining budget falls by the request's real standard-price value.

6.3The platform fee

The platform fee comes out of the order discount, never on top of the price. For every order, including the house's, the discount a user sees is:

U = max(0, D − f)
f = platform fee = 5 percentage points (the book's current setting)

So an order at 25% off appears to users as 20% off. An order whose U is 0 after the fee is served like standard-price capacity and never counts toward "credits available".

6.40% off is always unlimited

The last row of the book is always "0% off, unlimited": standard-price capacity from the house, with no budget. A model is never unavailable because discounted capacity ran out; it simply returns to its standard price until new orders are posted.

The book is public: /models shows the aggregate depth by discount tier and recent buys (a short wallet or pseudonymous id, a time and an amount, never the model or the content).

7The split

Each account allocates its discount as savings or token buybacks. The allocation is one setting per account, applied to every request on every model; it is a share of whatever discount each request receives, so it scales with the book.

New accounts start with the whole discount as savings. Choosing a custom token moves half of the discount to it by default; every share can be changed at any time.

7.1Pricing formulas

For a request whose standard-price value is L and whose user discount is U:

P        = L × (1 − U × s_disc)      what leaves your balance
B_xinf   = L × U × s_xinf            accrues to the $XINF buyback
B_custom = L × U × s_custom          accrues to your chosen token
P − B_xinf − B_custom = L × (1 − U)  what we keep, whatever the split

The last line is why the split is margin-neutral: we receive the same amount whichever way an account allocates its discount. The split changes only who benefits from the discount, never our share.

7.2Worked example

An illustrative order at 25% off, the current platform fee of 5 points, so U = 20%. An account splits its discount 50% savings, 25% $XINF, 25% a custom token. The request's standard-price value is $1.00.

The figures are an example; each model's live discount is shown beside its standard price in the catalog.

7.3Buybacks accrue from settled spend only

A buyback accrues when the request that funds it has settled and been paid for. Slider positions carry no weight on their own: an account that sets a split and 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.4x402 callers

Callers that pay per request with x402 have no account setting, so they pass a split with the call: a header X-Split: xinf=<bps>,custom=<bps>,discount=<bps> and, for a custom token, X-Split-Token: <mint>. When no split is sent, the whole discount is taken as savings and the caller pays the discounted price.

8Margin and the burn split

8.1Where margin comes from

We source inference capacity below standard price. Our cost discount c is what we pay below the standard price for a given maker. For each fill against an order with discount D and platform fee f:

margin per fill = L × (c − D + f)

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.

8.2The split

At every burn, the margin is split by the credits program: 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 users' discounts or 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 set of burns releasing $1,000 of margin:

The figures are an example of the shares, not a forecast of 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 discounts on specific models for $XAVA stakers, on top of the discount from the liquidity book. A promotion names its models, the extra discount, 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 discount comes out of our side of the fill, is capped at the platform fee when it is set, and is capped again at each request's own margin, so it can never push a request below cost.
• A plain price cut. It lowers what you pay; your split applies to the book discount as before.
• 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%. An honest ledger cannot reach 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, Jupiter and an existing audited merkle distributor. We write two small programs of our own: the lock (section 2.2) and 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. Both are open source, verifiably built and independently audited in one audit 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 signed USDC payment on Solana. 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.
• Tokenized NVDA's issuer. Holder rewards and the lock's rewards are paid in tokenized NVDA, a tracker certificate issued by Backed Assets (JE) Limited, not an NVIDIA share, with no voting rights. Its issuer can freeze any account, pause all transfers, move or burn tokens from any account, and install a transfer hook, through multisigs with no time lock. It is not offered or sold to US persons and is restricted in other jurisdictions.
• Swaps. The lock's NVDA is swapped to USDC before it becomes credits. A swap can fill at a worse price than quoted, which lowers that hour's credits.
• Claim within 60 days. Rewards not claimed within 60 days of their list expire. Expired holder credits are burned through the burn split; they are not paid to the holder.
• 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 issuer of tokenized NVDA, 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

standard price

what a model maker charges when you buy direct; the starting point of every price

your price

what you pay after the share of the discount you take as savings

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 spent on settled usage, destroyed in hourly batches; their USDC is released by the fixed split

burn split

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

order

a posted block of discounted capacity: scope, order discount D, budget

order discount (D)

the % off the standard price an order offers

platform fee (f)

the points taken from the order discount; currently 5

user discount (U)

D − f: the discount a user receives and splits

split

an account's allocation of U between savings, $XINF buybacks and a custom token

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

tokenized NVIDIA stock (NVDA), the asset $XINF is paired with; holder rewards and the lock's rewards are paid in it

holder AI credits

the lock's earnings, swapped to USDC and 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 discount 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 60 days a weekly list can be claimed after it is published

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