Codemojex · chapter C6
The revenue ledger and the KeyShop.
Where C5 moves the players’ money, this chapter books the house’s. The RVL revenue ledger (cm.6) is the platform’s own account — a dedicated table of signed deltas with no non-negative CHECK — and the KeyShop (cm.7) is the multi-rail pay-in that feeds it. The law is conservation: every keys-unit a player is debited is a house credit or a pool conversion, and every rail’s external event lands exactly once.
Grounding — echo/…/codemojex/wallet.ex (house_post/5, house_balance/1, revenue_breakdown/1) · key_shop.ex · rails.ex · the revenue_ledger/package/order/order_transaction/webhook schemas · the revenue-ledger + keyshop stories.
deposit_seed, the deposit_recovery and revenue credits, and the deposit_reclaim on a void — in keys, paired inside the same transaction as the player debit and the pool increment.The house’s own book
wallet.ex · house_post/5The revenue_ledger is the deliberate inverse of players: a signed delta with no non-negative guard (the house legitimately swings negative on the seed debit), no exactly-once index (each post is a distinct accrual), and its uniqueness is the RVL primary key alone. Every platform movement funnels through one primitive — house_post/5 mints one RVL row and touches no balance column, so it never hits players_non_negative and needs no player lock. The balance is the sum of these rows.
def house_post(account, currency, delta, reason, ref) do
rid = EchoData.BrandedId.generate!("RVL")
{:ok, _} =
%RevenueLedger{}
|> RevenueLedger.changeset(%{
id: rid,
account: account, # "platform" — the sole account this rung
currency: to_string(currency),
delta: delta, # SIGNED — negative on the deposit_seed debit
reason: reason,
ref: ref
})
|> Repo.insert()
rid
end
The reconciliation reads never re-derive: house_balance/1 is a SUM(delta) GROUP BY currency over a table holding only platform movements — no player rows to exclude, the dedicated-table payoff — and revenue_breakdown/1 groups one game’s rows by reason. The conservation identity holds over three observable columns, explicitly not by a zero row-sum.
The three dives
C6.1 · C6.2 · C6.3The revenue ledger
The signed house account — the five Golden-Room movements, the reconciliation reads, and the three-column conservation identity a property test holds.
The KeyShop
The DB-stored PKG catalog and the multi-rail order flow — the pinned rate snapshot, and exactly-once settlement over the (rail, external_id) partial unique index.
Cash-out and the treasury
Forward — cm.8. The withdrawal rail as a house debit through the same signed house_post — grounded in the shipped seams, never read as built.
The order is the money’s: first the house’s own book (C6.1), then the pay-in that feeds it (C6.2), then the outward rail the design points at but has not built (C6.3). Scoring stays linear throughout; this chapter is money, not points.
The doors
out of this chapterExactly-once on the bus
The KeyShop’s (rail, external_id) gate is the ledger-native form of the bus’s exactly-once discipline.
The players’ side
The wallet, the paired TXN, and the pool the buy-in funds — the money this chapter’s house credits pair against.
The ledger law
Coherence is a message about a name; the append-only signed row is that law made a table.
References
sources · relatedSources
- Ecto — Repo.transactionthe paired revenue booking inside one transaction
- Telegram — Mini Appsthe Stars invoice flow the KeyShop pays into
Related
- EchoMQ — the courseexactly-once on the bus, the sibling discipline
- C5 — The Economy and the Bankthe players’ side of the money
- BCS — the architecture lawthe ledger law behind the books