02 / 10
How rewards are computed
The accounting is deterministic. Anyone can rebuild it from chain history. This page walks through it in the order the kiln runs it. Version: kiln-accounting/1.
1. Epochs
An epoch is 21,600 seconds — six hours — aligned to UTC: 00:00, 06:00, 12:00, 18:00. The opening and closing blocks are the canonical blocks around those wall-clock boundaries. The first epoch after launch only covers the seconds after the launch timestamp.
An epoch is published only after the configured finality policy is met (by default, 64 confirmations and the batch posted to Ethereum).
2. Base weight: token-time
Your base weight is the sum of KILN balance × seconds held during the epoch.
- Transfers are ordered by block, transaction and log index.
- Before a block's transfers apply, every affected wallet accrues
balance × elapsed seconds. - All transfers in one block share one timestamp. A same-block round trip earns no extra time.
- The zero address, the dead address and disclosed policy exclusions (launch pool, protocol treasury, the reward distributor) get no weight.
Example. A holds 100 KILN for all 21,600 seconds; B holds 100 KILN for half of them. Base weights are 2,160,000 and 1,080,000. Unboosted shares: 2/3 and 1/3.
There is no minimum balance. There is no staking. Any nonzero token-time counts.
3. The boost
At epoch close the kiln freezes one row per holder:
heldUsd = average KILN balance × frozen KILN price
burnedUsd = sum of verified burns in [epochEnd − 30 days, epochEnd)
boost = min(10, 1 + burnedUsd ÷ heldUsd)
effective = floor(baseWeight × boost)
Division is floored in basis points. Zero held value or zero burns gives 1×. The cap is 10×, reached when your burned value equals nine times your held KILN value. The KILN price, its source, the window, your lanes, base weight and effective weight are all stored with the freeze. A finalized epoch is never rewritten.
Burn value is fixed when the burn is recorded, at the price observed then. See Reforge for what counts.
4. Lanes
You pick one to four Stock Tokens. Your effective weight is split evenly across them. If you pick nothing, it all goes to SPCX. Equal halves, thirds and quarters stay exact integers before allocation.
Example. A and B each have effective weight 1. A picks SPCX and NVDA; B picks SPCX only. In the SPCX lane their weights are 1 and 2. Funding 100 units of SPCX gives A 33, B 66, remainder 1. In the NVDA lane A gets everything.
5. Allocation
For each lane, the kiln allocates only the Stock Token quantity Q that was actually funded:
allocation = floor(Q × laneWeight ÷ totalLaneWeight)
The sum never exceeds Q. The remainder is recorded and rolls into the next epoch. Entitlements are cumulative per wallet and asset and never decrease. A delivery threshold may batch small payments; it never changes what you are owed.
The fee counter on the homepage is a run-rate estimate from recent trading volume. It never becomes Q. Only confirmed fee receipts, completed conversions and net Stock Token units received can fund an allocation.
6. Publication
Cumulative entitlements go into a Merkle tree (OpenZeppelin StandardMerkleTree, double-hashed leaves over chainId, distributor, sequence, account, asset, cumulativeAmount). The kiln-manifest/1 document lists the root, the finalized epochs, every entry, per-asset totals and a digest. Once a RewardDistributor is configured, roots are published there with increasing sequence numbers, and claimFor pays the unpaid difference to the leaf wallet — and only to that wallet.
Six evidence states
Kiln keeps these apart, and so should you:
- A volume-derived fee estimate.
- A confirmed fee receipt.
- A confirmed conversion and funded Stock Token quantity.
- A deterministic allocation and proposed manifest.
- A published root.
- A confirmed delivery transfer.
No response is not zero. No price is not zero value. A published root is not a delivered payout.
Next: Reforge → · Verify it yourself →