You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Permissionless, batched, recipients fixed by the map, works mid-period. A batch is capped at `MAX_RECIPIENTS`, so a full payable table drains in two calls. Zero-entitlement entries (unknown wallets, duplicates within the batch) pay nothing and return 0 at their position. An unknown or deleted stream id returns all zeros, so a repeated claim after its tombstone drains is benign. An all-zero batch succeeds.
206
215
216
+
## The f099 burn sentinel
217
+
218
+
f099 in an explicit share map is a burn instruction, not a payee. Wire shares still sum to
219
+
`DENOM`; share-map admission validates that checksum, then strips all f099 rows. The stored
220
+
shortfall is the burn share. Persisted state rejects f099, so it cannot accrue, be claimed, or
Only `accrue` enters the stream pool and `total_explicit_minted`; the remainder uses the
231
+
existing burn send and counter. Flooring the survivor side prevents a removal from improving
232
+
survivor earnings through rounding.
233
+
234
+
Claim and fold divide the survivor pool by `stored_share_total`, leaving stored share values
235
+
unchanged. A total of `DENOM` uses the ordinary path; zero accrues nothing and burns the whole
236
+
portion. The total is derived from the inline share vector, bounded by `MAX_RECIPIENTS`.
237
+
207
238
## Supply accounting
208
239
209
240
Circulating supply is consensus-relevant (`GetFilMined` feeds initial pledge) and Lotus, Forest, and Venus each compute it independently, so its inputs do not change. `FilMined` stays "read position 9 of f02": the split changes who receives issuance, not how much, so the field keeps meaning the total and no implementation changes its supply logic.
0 commit comments