Point types and immutable ledger

Point types and ledger

Each point type has a stable slug, labels, symbol, precision, transfer policy, and negative-balance policy. Free supports one whole-number point type. Pro supports unlimited point types and zero-to-eighteen decimal precision. Amounts are stored as DECIMAL(38,18) and API callers must send decimal strings, never floating-point numbers.

Fresh installations begin without an opinionated currency. Create the first type as Points, Credits, Reputation, Tokens, or any site-specific reward only when it matches the intended program. A type that is no longer awarded can be archived: it disappears from active configuration and member selection while its balances and immutable ledger history remain preserved. Archiving never deletes or rewrites prior transactions.

Every movement is a balanced double-entry transaction. Projections may be rebuilt from entries; adapters never write projections directly. A posted transaction is not edited or deleted. Correct mistakes with a reversal, which posts compensating entries and links both records.

Use stable idempotency keys for retries. Transaction provenance can include provider, external event, original time, object identity, synchronization run, authority, adapter version, and a normalized SHA-256 source hash.

Concurrent postings serialize exact balance updates inside database transactions. If MySQL or MariaDB selects a posting as a transient deadlock or lock-timeout victim, the complete atomic posting is rolled back and retried with bounded jitter; the idempotency key still guarantees that only one transaction is committed.

Member reward history offers public source labels configured by the site administrator. Filters show those readable labels while submitting stable internal tokens; members never need provider names or implementation keys. Content-type filters resolve posts and their comments to the matching public content label. Filtered database work is performed only when a source filter is actually selected.

Rewards blocks and shortcodes are personalized surfaces. Their page responses, progressive history requests, and authenticated REST responses are marked private and non-cacheable so a shared cache cannot serve one member's rewards or a previous display configuration to another request.