$KAMI

$KAMI is the Kami token. Every losing close earns $KAMI at a fixed rate that halves as total losses grow, paid from 70% of the supply, locked for losing traders. You can stake $KAMI to earn a share of protocol revenue in USDC.

What it is

• $KAMI was launched on pump.fun as a Token-2022 mint with a fixed supply of 1,000,000,000 and 6 decimals. It has no mint authority and no freeze authority: nobody can create more $KAMI or freeze a wallet's balance. Its only extensions are the metadata pointer and the metadata itself.
• At launch, in the same transaction that created the mint, the protocol bought 70% of the supply and locked all of it in a Jupiter Lock escrow. The escrow releases 20% of it into the Kami program's reward vault at launch and the rest linearly over 60 days. A release only makes tokens available to the reward schedule below; nothing leaves the vault except to a losing trader (or a withdrawal of what someone has earned or deposited). The escrow can't be cancelled and its recipient can't be changed.
• The reward vault is a token account owned by a program address (the vault authority, a PDA). No person holds its key. The program moves tokens out of it only when a trader withdraws $KAMI they have earned or deposited.
• $KAMI is earned and staked on your trading account. Rewards credit your account's unstaked balance, and staking moves $KAMI between unstaked and staked there, so fills and liquidations never need access to your wallet.
• Withdraw to wallet moves unstaked $KAMI from the vault to a wallet. Deposit from wallet moves it back, for example to stake $KAMI you bought.
• Staking earns USDC rewards. Wallet tokens earn nothing until deposited and staked.

Moving $KAMI between your account and a wallet

• withdraw_token(amount) takes amount from your unstaked balance and transfers it from the reward vault to a token account of the $KAMI mint. Staked $KAMI must be unstaked first (instant). The app always sends to your own wallet.
• deposit_token(amount) transfers $KAMI from a token account you own into the vault and credits your unstaked balance with what actually arrived in the vault.
• Both need your wallet's signature. A 1-click session key can't sign either one, so a leaked session key can't move $KAMI out. Neither is ever paused.
• Both first move any of your owed $KAMI that the vault can now cover into your balance (see below).
• Solvency. The vault always holds at least the uncredited budget plus every credited balance: every account's unstaked and staked $KAMI and referrers' unclaimed balances. Owed $KAMI (earned, waiting for a lock release) isn't counted until it's backed. Tokens leave the vault only through withdraw_token, and only from the caller's own balance.

Earning $KAMI: a fixed rate that halves

Losing closes earn $KAMI. Winning closes earn nothing, and neither do settlements of retired markets (their loss is set by the final price).

What counts. Every losing close counts the whole loss, the 2% fee included; a liquidation counts the full margin. A $100 loss earns on $100. A close with zero PnL earns nothing.

The rate. The program keeps a running total of counted losses, cum_loss. The rate depends only on where that total stands:

Counted losses so far	$KAMI per $1
first $250,000	1,400
next $250,000	700
next $250,000	350
next $250,000	175
and so on	halves every $250,000

rate(x) = 1,400 / 2^floor(x / 250,000)          per $1 of counted loss, at running total x
tokens  = the rate summed over [cum_loss, cum_loss + basis), rounded down once

• A close that crosses a boundary pays each rate on its own part.
• The schedule adds up to at most 700,000,000 $KAMI, exactly what is locked for it, so it can never promise more than exists.
• The rate and the halving step are fixed when the token is attached. There's no setting to change them; only a program upgrade could, through the multisig and its time lock.
• Your rate doesn't depend on who else is trading or when. Anyone can work out what a loss will earn before placing the trade, and the app shows it.

Getting paid. The tokens are credited at the close:

• straight into your unstaked balance, from what the lock has already released into the vault;
• if the vault can't cover all of it yet, the rest is owed and shows as unlocking. As the lock releases more, owed tokens are moved into balances: the keeper does it automatically, oldest first (settle_reward, which anyone can send for anyone and which can only credit the owner), and your own next close, withdrawal, deposit, stake, unstake or claim does it for you too. While anything is owed, new credits wait behind it.
• Owed tokens never expire.

Funding the vault

The budget grows from three sources:

• Lock releases. claim_vested, which anyone can send, claims what the Jupiter Lock escrow has released into the vault and adds it to the budget. The program checks that the escrow streams this mint to its vault authority and can't be cancelled or redirected.
• Buybacks. USDC from the buyback reserve (below) buys $KAMI, which is sent to the vault.
• Anything else sent to the vault. sync_budget, which anyone can send, adds tokens that reached the vault from outside to the budget. It only counts tokens actually in the vault above what is already budgeted or owed, so it can't be gamed.

Creator fees. The token's pump.fun creator is the program's vault authority, so pump's creator fees accrue to the program, for future buybacks. pump.fun's admins can reassign a token's creator.

Referrals

Every trader gets a referral code automatically: 6 letters and digits, registered with their trading account on their first deposit or order. Codes are derived from the trader's address by the program itself (no look-alike characters), so nobody can choose or take someone else's. A new trader links to a referrer by entering their code once; the link never changes and never expires.

A referred trader's loss counts 115% on the schedule: its basis plus 5% for the trader and 10% for the referrer. The tokens are split 105 : 10:

	Nobody referred the trader	The trader was referred
Counted on the schedule	loss basis	loss basis × 1.15
The trader gets	the tokens for the basis	105/115 of the tokens (5% more than unreferred)
Their referrer gets	—	10/115 of the tokens, into their referral balance

Both shares come from the same schedule, so referrals move the running total a little faster.

• Referrers claim their referral balance into their own unstaked $KAMI (owner or session key), ready to stake or withdraw. Claiming moves balance within the program and earns nothing new.
• You can't refer yourself (the same wallet); a second wallet of your own is allowed and unavoidable.
• The 500 / 1,000 split is a governance parameter (timelocked; together at most 3,000).

The buyback reserve

20% of staker revenue (the staker share of fees, and house overflow sweeps) accrues to a buyback reserve, in USDC. Stakers receive the other 80%: 40% of all fees instead of 50%. The admin (a multisig) claims it and buys $KAMI back into the reward vault. That step happens off-chain, so you trust the multisig to do it, and each buyback is published. The claim is bounded by what accrued and can't touch any trader's balance, the house or stakers' cash. The share is a governance parameter, at most 50%.

Staking and unstaking

• stake(amount) moves unstaked $KAMI to staked, and unstake(amount) moves it back. Both are instant. There is no lock-up, cooldown or penalty, and unstaking keeps the rewards you have already accrued.
• The owner or a live session key can sign either one.
• Rewards are shared in proportion to staked amount, with conservative integer rounding. The pool rounds each allocation down and carries the leftover forward as dust. Each account's reward checkpoint rounds up, so fractional USDC base units can be lost when an account settles, and many small claims can receive slightly less than one large claim.

Rewards (USDC)

Sources. All rewards are USDC:

1. The staker share of every fee: currently 50% of the 2% loss fee and of the 2% payout fee, including payout fees on queue payments.
2. LP excess sweeps: the treasury above staker_cap ($5,000,000), swept whenever the payout queue is empty and a settling instruction runs (The house).

20% of both goes to the buyback reserve instead (pol.share_bps, rounded down), and stakers receive the rest.

Streaming. New revenue isn't paid out instantly. It vests linearly in fixed-schedule tranches:

epoch = ceil(reward_stream_s / 8)                     (currently ceil(3600 / 8) = 450 s)
start = (floor(now / epoch) + 1) × epoch              (the next epoch boundary)
end   = start + reward_stream_s                       (currently 1 hour later)

• Revenue added within one epoch joins the same tranche. Up to 10 tranches can be active at once. Each tranche keeps its own schedule, so new revenue never delays older revenue.
• Whatever has vested so far is credited to the current stakers whenever a staking-related or settling instruction runs. Staking and unstaking settle vesting first, so you earn only from vesting that happens while you are staked.
• Why. Revenue arrives in bursts, for example a big liquidation or a sweep. If it were paid instantly, someone could stake just before a burst and unstake right after (just-in-time staking). Because vesting starts at the next epoch boundary and runs for an hour, a stake held for seconds around a burst earns almost nothing from it.
• Revenue that vests while nobody is staked is held back. When someone stakes again, it is rescheduled as a new tranche.
• Timing. With an unchanged window and a free tranche slot, revenue starts vesting at the next epoch boundary (within 450 s) and streams for one window (1 hour). If governance shortens the window while all 10 slots are occupied, new revenue waits in the held pool until a slot frees up, which can delay it longer. Existing tranches keep their schedules.
• reward_stream_s is a governance parameter: 3,600 s (1 hour) to 7 days in production builds. Test and devnet-feature builds also allow 0, where new revenue is allocated immediately if anyone is staked. Held revenue, and revenue that arrives while nobody is staked, is still scheduled (over a 1 s window), and existing tranches are unchanged.

Claiming. claim_rewards credits everything accrued to your available USDC balance (your trading balance in the app). Rewards are never sent to your wallet directly; use withdraw to move them out. The owner or a live session key can claim.

Claimable amount in the app. The Kami app simulates claim_rewards without signing it, refreshes about every 15 s, and shows the last simulated amount. If the simulation fails it shows a client-side estimate instead. The amount actually claimed can differ, because vesting and state keep moving.

Governance

fee_bps, staker_share_bps, staker_cap and reward_stream_s are economics parameters; the buyback reserve's pol.share_bps, and the referral split each have their own proposal. After launch they change only through a governance proposal (Oracle and safety). The reward rate and its halving are fixed when the token is attached and have no proposal.