Every unit.
A visible route.

The product is read-only first. A user can inspect treasury state, epoch data and estimates without signing. A wallet approval appears only for an explicit on-chain action such as creating or extending a stake, claiming an available reward, or withdrawing after unlock.

The pre-launch backend includes PostgreSQL migrations, prioritized RPC access, a persistent finalized WebSocket indexer, reconnect and backfill, trader, holder and staker snapshots, integer reward accounting, Kamino job states, dust accruals, capped mass-transfer batches and reconciliation.

This is not a claim that the complete protocol is production-ready. The audited staking program and PDA, protocol-specific trade decoder, verified fee-claim accounts, restricted signer gateway and controlled mainnet rollout remain launch requirements.

Until the staking program exists, backend stake positions are an accounting boundary or test fixture. They are not token custody.

The fee-recipient indexer accepts finalized transactions involving the allowlisted trading program. A trade is eligible when inferred swap volume is at least 0.1 SOL. Its accounting value is the actual positive balance change received by the fee recipient, not headline volume.

Repeated eligible trades are summed once per wallet and epoch. Holder accounts are aggregated by owner. These snapshots create an auditable activity record; under the current policy they do not create a second liability against the same fee principal.

eligible_trade = allowlisted_program AND inferred_volume_lamports >= 0.1 SOL
indexed_fee_lamports = max(fee_recipient_post - fee_recipient_pre, 0)
epoch_fee_principal = sum(indexed_fee_lamports)

protocol fee principal != Kamino yield != staking reward

After an optional allowlisted fee claim, 100% of available fee principal is scheduled for the configured Kamino SOL vault. Only positive yield above the principal high-water mark can become a staking reward.

The earlier 50% traders / 30% holders / 20% reserve split is retained only for historical compatibility and is disabled by default. Combining it with the Kamino principal route would double-spend one accounting source and is rejected by configuration.

Every epoch has an immutable start and end. Finalized trades are indexed continuously. After a disconnect, getSignaturesForAddress and getTransaction backfill the gap before live processing resumes.

A repeated signature is ignored, each job carries an idempotency key and every transition is persisted. Reconciliation continues from stored cursors instead of inventing a replacement total.

A stake locks STREAM from one hour to thirty days. Before approval the interface should show token amount, exact unlock time, WeBased multiplier, effective weight and that rewards are variable. Locked tokens cannot be treated as liquid before expiry.

A wallet may own several positions with different end times. Weight is calculated per position and then summed by wallet. Extending or adding a stake must be an explicit instruction; the interface must never reset a lock silently.

At an hourly boundary a position is eligible only if it started before the epoch ended and unlocks after the boundary. Expired or withdrawn positions have no future weight.

WeBased Weight is the accounting weight of a locked position. The multiplier is clamped to ×1 for a one-hour lock and reaches ×3 at thirty days, with transparent linear growth between those points. It changes reward share, not token ownership.

MIN_LOCK = 3,600 seconds               // 1 hour
MAX_LOCK = 2,592,000 seconds           // 30 days / 720 hours
duration = clamp(lock_seconds, MIN_LOCK, MAX_LOCK)

multiplier_bps = 10,000
  + floor(20,000 * (duration - MIN_LOCK) / (MAX_LOCK - MIN_LOCK))

weight_base_units = floor(stake_base_units * multiplier_bps / 10,000)
reward_share = user_weight_base_units / total_active_weight_base_units

Production accounting uses integer fixed-point basis points, never floating point. Duration is clamped first, the multiplier is rounded down, and weight is calculated from token base units.

1% example. A user locking an amount equal to 1% of supply for one hour has reference effective weight of 1%. The same amount locked for thirty days has reference effective weight of 3%. Actual reward share is still user weight divided by combined active weight.

Two-user example. If two users each stake 1,000 STREAM and choose one hour and thirty days, their weights are 1,000 and 3,000. If they are the only participants, they receive 25% and 75% of that epoch's pool. Three times the weight is not a guarantee of three times the APR.

The system maintains a high-water value for the Kamino position. Earned yield is the positive difference between actual underlying value and that mark. Loss or recovery below the mark produces zero distributable yield. Depositing new fee principal raises tracked principal; it does not count as profit.

earned_yield = max(actual_underlying - high_water, 0)
distribution_target = floor(earned_yield * 7,000 / 10,000)
user_raw_share = distribution_target * user_weight / total_weight

sum(final_user_allocations) = distribution_target
principal selected for rewards = 0

Seventy percent of verified positive yield is selected for stakers; thirty percent remains in the treasury. A deterministic largest-remainder method conserves every selected base unit. Rewards below the dust threshold remain accrued until economical to transfer.

After each eligible epoch, an idempotent job links source epochs to one Kamino deposit. Treasury authority and fee recipient must match; vault and asset mint must be allowlisted. Simulation validates operations without advancing financial state.

The yield worker reads actual vault shares and exchange rate. When positive yield exists, it calculates shares representing at most 70% of that yield, requests a bounded withdrawal and verifies the finalized amount. Principal is not selected.

Kamino yield is variable and exposed to smart-contract, liquidity, oracle, strategy and execution risk. Displayed APY is informational, not a promise.

RPC priority is dRPC, then Chainstack, with Solana public RPC as an emergency path. A persistent finalized WebSocket subscription monitors the fee recipient; HTTP backfill closes gaps after reconnect.

PostgreSQL stores signatures, epochs, snapshots, stake positions, strategy jobs, high-water values, accruals, payouts and batch membership. Values use bigint in TypeScript and numeric(39,0) in PostgreSQL. No accounting formula uses JavaScript floating point.

The production process does not load a private key. Claim, Kamino and transfer operations are delegated to a restricted signer gateway that must enforce program, account, mint, amount and recipient allowlists.

Rewards move through pending, processing, submitted and confirmed states. Temporary failures become retryable; invalid or repeatedly failing rows become dead-letter records. Terminal payments cannot return to processing.

Mass transfers select unique payout IDs into bounded batches. Recipient count and total value are capped. A batch is confirmed only after every required transaction is finalized and received amounts match policy. Partial completion is reported without replaying successful recipients.

Strict historical holder balances require archival account-state access or an on-chain checkpoint. A finalized account read immediately after a boundary is robust current state, but not historical proof of the exact boundary slot.

This is the current pre-launch specification and implemented accounting boundary, not a claim that the complete protocol is deployed or audited. It is not investment, legal or tax advice and does not promise any return.