Provider rewards

Current mode: Bankr-wallet-funded provider rewards. HISS can route a configurable portion of the claimed HISS-token side to eligible vault providers. The live state — imported claims, epoch plans, allocations, and receipts — renders on /app/provider-rewards from committed ops artifacts, and is served as JSON at /api/provider-rewards/status. Because the state comes from committed, chain-verified artifacts, a degraded or failed status read falls back to the last verified state, labeled as such — an unreachable endpoint reads as status unknown, never as “not configured” or “no rewards program”.

The policy

• Asset: rewards are paid in the $HISS token itself (0x47162135cc8fb253f939bd70e3d2b83075eaeba3, 18 decimals, Robinhood Chain 4663) — nothing else.
• Split: 30% of the claimed HISS-token side goes to the provider pool; 70% stays with the treasury (the Bankr wallet).
• WETH side: 0%. The WETH half of a fee claim is never allocated to providers — it funds treasury operations, like the USDG conversion that seeded the flagship vault.
• Exact math: all amounts are 18-decimal base units with bigint arithmetic. The provider side is floored, treasury absorbs the division dust, and every base unit reconciles.

Who is eligible

Eligible providers are creators of live, deposit-open vaults. Scoring v1 checks three verifiable operational facts against Robinhood Chain and the vault artifacts:

• the vault contract is live on-chain,
• the vault accepts public deposits (deposit-readiness registry),
• the creator's skin deposit is present.

There are no PnL, price, or performance inputs anywhere in scoring — deliberately. Rewards recognize operating a real vault, not trading outcomes.

Epochs and the plan hash

An epoch is a deterministic plan over imported claims: total HISS allocatable, per-provider allocations with their basis facts, and the treasury remainder. The plan's keccak256(stableStringify(plan)) hash is the funding confirmation token. Statuses are honest states, not aspirations:

• planned — computed and written; nothing moved.
• funded — every non-self allocation transferred and verified on-chain.
• published — the public summary is emitted.
• bootstrap_retained — the only eligible provider is the Bankr wallet itself, so the allocation is retained in-wallet, allocated. A self-transfer is never executed. Epoch 1 is such a bootstrap epoch.

Funding is double-gated

The funding command refuses to run unless both gates pass, and it fails closed:

• OWNER_APPROVED_PROVIDER_REWARDS_FUNDING must be exactly true in the runtime environment (never committed), and
• --confirm-plan-hash must equal the hash recomputed from the plan on disk.

Transfers execute from the Bankr wallet (ERC-20 transfer of the HISS allocation on chain 4663), and each transfer transaction is verified on-chain before the epoch is marked funded. Receipts (tx hashes) are recorded in the epoch artifact and rendered on the status page.

Copy rules

Every surface describing this program uses the sanctioned copy and avoids income-product vocabulary entirely; a copy guard in @hiss/core enforces the banned list in tests. See HISS fee routing for where the claimed fees come from.

Relationship to the V2 reward split

This 30/70/0 program covers imported Bankr-wallet claims under provider-rewards-policy-v1, and is unchanged. It is separate from — and never conflated with — the current methodology split. Newly classified, verified HISS trading-fee claims route through the V2 50/15/15/10/10 reward split — where Vault Providers receive the 15% provider leg (raised from the historical V1 10% leg) alongside the xHISS staker, Vault Contributor, treasury, and economic-burn legs. The full claim-to-injection pipeline is described in the reward flywheel, and the xHISS staker leg is covered there too. In both programs the same truth rule applies: planned is not funded, and funded is not claimable.

V2 retroactively and cumulatively re-scored the historical fee ledger and trued it up under the new split; prior irreversible on-chain transfers are counted as actuals, never reversed. The migration is executed on-chain (complete is true): the provider reserve is custodied at the Treasury Safe (separately ledgered), but no monthly epoch is funded — so nothing is vesting or claimable yet.