Treasury policy

liveDeployed

$BASIS is LIVE on Base; here is how Basis accounts for treasury value. WETH-side and $BASIS-side amounts are accounted separately and never blended: the WETH side is a liquid external reserve in the creator wallet; the $BASIS side is native inventory split 50% burn / 50% staker rewards on every claim — 50% burned on-chain and 50% funded to the staking vault (streaming over 7 days, read live from Base). The continuous, automatic 50%-of-fees feed is not yet wired, and the per-job burn is not implemented; the rest is a v0.1 design proposal pending operator and legal review.

Principles

—WETH-side and $BASIS-side are separate ledgers — never blended. WETH is a liquid external reserve; $BASIS is native inventory. There is no single blended total.
—No made-up allocation matrix. The treasury is accounted as assets (what it holds) and obligations (what it owes) — not a fixed percentage matrix across invented categories.
—Burned and staker amounts are tracked separately from treasury balances.
—No automatic on-chain action. Every claim, conversion, market buy, burn, liquidity move, or staker distribution is an explicit, operator-approved, signed-wallet action — never executed server-side, never in the inference hot path. No automatic buyback is promised.
—No financial-promise language. The treasury funds the network; it is not a vehicle that pays anyone for holding a token.
—Honest pending. Until the treasury and beneficiary recipient reads are verified on-chain, every treasury surface reads pending and fabricates no balances.

Assets vs obligations (no allocation matrix)

The treasury is accounted as what it holds and what it owes, each on a single side, with every amount null until verifiable on-chain — never fabricated, never netted across assets and obligations, never netted across sides.

Assets — what it holds

Bankr creator fees (WETH-side)
WETH
Bankr creator fees ($BASIS-side)
$BASIS
Per-job burn share (earmarked)
$BASIS
Payment-router fees
$BASIS

Obligations — what it owes

User credit balances
credits
Pending worker rewards
$BASIS
Pending staker rewards
$BASIS
Unsettled refunds / releases
$BASIS

All amounts read pending until launch plus a verified production read. The machine-readable composition is served by GET /api/treasury.

WETH-side policy (separate; no burn/staker split)

WETH accrues from the WETH side of the Bankr / Doppler creator fee. It is a liquid external reserve — not $BASIS — so it can fund real costs without touching native inventory. It has no burn or staker split and is accounted entirely separately from the $BASIS side.

Intended uses (operator-executed, explicit)

·operations
·inference backend
·liquidity
·security
·treasury reserve

Market buys — only if explicitly approved

WETH may fund market buys of $BASIS only if the operator explicitly approves a specific action. No automatic buyback is promised or scheduled, and it is never described as a buyback program, value accrual, or price support. WETH-side claimable and claimed are read from Bankr's unauthenticated endpoints for display only; claiming is an operator/keeper action with a signed wallet, never server-custodied, and only the current beneficiary may claim. WETH-side amounts are never added to a $BASIS-side number.

$BASIS-side policy — designed split

$BASIS-side fee generation is the $BASIS side of the Bankr creator fee. This is native inventory. By design it splits 50% burn / 50% staker rewards — applied to the $BASIS side only, never the WETH side, and separate from the per-job burn (the protocol's per-job share, which is its own earmarked-for-burn flow).

realized per claim

This split is realized on every claim: 50% of each $BASIS-side claim to date has been burned on-chain (to the dead address — the burned supply is read live from Base) and 50% has been funded to the staking vault via fundRewards, where it vests linearly over 7 days into the redeemable value of staked $BASIS (read live from Base). What is not yet wired is the continuous, automatic 50%-of-fees feed — each claim, burn, and vault funding to date was an explicit operator-signed action.

Burn (50% of each $BASIS-side claim — realized on Base)

50% of each $BASIS-side claim to date has been burned on-chain — sent to the dead address, the burned supply read live from Base. The burn removes $BASIS from supply, making the token deflationary as $BASIS-side fees grow. Supply reduction scales with real usage, not speculation, and must never be oversold or framed as value accrual or appreciation. What is not yet wired is the continuous, automatic burn feed; the policy getter describes that automatic feed and stays not implemented, so its burned-to-date counter is 0 — distinct from the realized dead-address balance read live from Base.

Activation requires (all)

☐A deployed $BASIS token contract
☐A burn contract or verified burn action (send-to-dead or burn()) on Base
☐On-chain proof of burned supply before any burned amount is reported
☐Operator approval and legal review.

These prerequisites are for the continuous, automatic burn feed. The BASIS_BURN_ENABLED env gate, even if set to true, leaves that automatic-feed policy not implemented until it is wired and verified on-chain; its automated-feed counter stays 0. The realized per-claim burns are operator-signed and read live from the dead address on Base.

Staker rewards (50% of each $BASIS-side claim — funded + streaming)

The staker-reward side is delivered through the BasisStakingVault, and fundRewards has been called: 50% of each $BASIS-side claim is funded into the vault, where the funded $BASIS vests linearly over 7 days into the redeemable value of staked $BASIS, every figure read live from Base. The continuous, automatic feed is not yet wired — each funding to date was an explicit operator-signed claim.

No yield framing

Staker rewards are the accounting of a funded, streaming flow, not yield, passive income, or a guaranteed return; rewards are not guaranteed. There is no stake-to-earn, no staker yield, and no passive income — and none is promised. Every reward figure is read live from Base, and the staker-reward to-date counter for the automatic feed starts at 0.

Activation requires (all)

☐A deployed $BASIS token contract
☐A deployed + verified BasisStakingVault (ERC4626 + cooldown) on Base
☐Production verification of distributed rewards before any amount is reported
☐Operator approval and legal review.

Risks

Legal / optics (highest)
A burn or staker reward is easily misread as value accrual or a return. The forbidden-language rules apply with full force; copy must say what happens mechanically and never imply holder benefit, appreciation, or return. Mis-framing is a launch blocker.
Treasury solvency
Burning the $BASIS-side share removes native inventory; opex must be covered by the WETH-side reserve. The side separation is what keeps this honest.
Over-promising at low usage
Effects are proportional to usage; at low usage they are negligible. State honestly with real denominators — zeros until fees flow.
Irreversibility & bugs
Burns are permanent; both flows require audited, keeper-gated, idempotent, separately-accounted paths — never automatic hot-path actions.

Status

Realized per claim; continuous feed not yet wired

No standalone treasury contract exists on-chain, but the $BASIS-side 50/50 has been realized on every claim — read live from Base.

Treasury assets and obligations read pending — null amounts until a verified per-pool read. The per-job split is a v0.1 proposal, and the per-job burn is not implemented. The WETH-side policy is a separate reserve in the creator wallet with no burn or staker split and operator-only claims. The $BASIS-side burn (50%) and staker rewards (50%) are realized per claim — 50% burned on-chain (dead address, read live from Base) and 50% funded to the vault, vesting over 7 days into staked value; the continuous, automatic 50%-of-fees feed is not yet wired. The Bankr beneficiary share is null until read from the launch output. The side separation (WETH / $BASIS / burned / staker / obligations) is enforced at the type level.