Reward accounting (normative)

5.7 Reward accounting (normative)

bINT accounting is event-based. The Epoch 9+ economic source is the bINT movement ledger; cPoints remains a separate background metric. Four record families carry the related state:

bINT movement ledger — append-only event rows. Every bINT credit is written with its source (receipt, contribution_center, yumo_pass, ...), the source record's id, amount, source bucket, status, quota day, and creation timestamp. Balances are derived from events; events are never edited in place. The lifecycle is locked → reserved_in_epoch → claimable → claimed.
contribution_point_events — background cPoints contribution/airdrop metric; it is not an epoch-9+ bINT source.
receipt_rewards — the per-receipt reward record: what a specific verified receipt earned and how the amount was composed (the composition is stored as a breakdown alongside the amount).
User balance — the running balance surfaced in the product, derived from the event history.

text

// contribution_point_events row (representative cPoints metric)
id:          184223            // serial
user_id:     9c41...-...       // account id
source:      receipt
source_id:   6f2b...-...       // receipt UUID
amount:      125.00            // decimal
created_at:  2026-05-17T14:23:12Z

Settlement: epoch snapshots

Settlement is periodic. Epoch 8 may use the historical cPoints path. Epoch 9 and later select only post-cutover bINT movements in locked state from the user_rewards source bucket, reserve each movement once, and build a snapshot of eligible accounts as reward_epochs + reward_epoch_leaves (one leaf per account). The leaves are folded into a Merkle root, and an independent verifier recomputes the ledger totals, eligibility window, reservation set, and root before approval. A released root can then be sealed on-chain, and INT claim entitlements are read from that released epoch's leaves.

The epoch snapshot — rather than a per-entry chain — is the auditable unit: a published epoch's leaves, root, and verification method let anyone recompute the commitment and check that the released root matches the records. Each eligible bINT unit maps to one INT unit. Corrections after sealing are handled as new entries in a later epoch; sealed history is never rewritten.