加密賭場

Torrent Gear

資產負債表和錢包：多錢包體系結構

1）為什麼要使用多錢包，目標是什麼

一個「平衡=數字」條目不涵蓋iGaming的現實。我們需要單獨的錢包/子賬戶：真實現金（現金），獎金，花瓶池，飛盤，復合，有時是貨幣錢包（EUR/USD/BRL）。

體系結構目標：

金錢的準確性（雙入門，可審核性）。
註銷政策（例如，首先是獎金/旅行者，然後是現金）。
速度（p95 API ≤ 250-400毫秒，實時投註/設置）。
安全性和合規性（KYC/AML，負責任的遊戲限制，監管機構）。
規模：高峰→數萬個操作/秒，數十億個職位/月。

2）數據模型： 「Ledger+Subwallets」

最小實體

帳戶：玩家/品牌/市場。

Wallet: `{type: CASH	BONUS	WAGER	FS	POINTS, currency, status}`.
LedgerEntry (двойная запись): `debit_account`, `credit_account`, `amount`, `currency`, `operation_id`, `category`, `created_at`.
Posting：原子業務運營,結合2+LedgerEntry。
Hold/Reservation：臨時鎖定資金/提款。
政策：註銷/入計優先權規則。
FXRate：課程/精度/四舍五入規則。
極限：白天/月/負責任的遊戲。

示例表（簡化）

sql
-雙入賬賬戶（包括辦公室）
accounts(id, owner_user_id, type, currency, status,...)

-接線（雙重記錄，業務操作鏈接）
ledger_entries(id, posting_id, debit_account_id, credit_account_id,        amount_minor, currency, category, operation_id, created_at)

-丘陵（儲備）
holds(id, account_id, amount_minor, currency, reason, expires_at, state,    operation_id, created_at)

-註銷政策（優先事項）
spend_policies(id, market, wallet_priority jsonb, updated_at)

- 跨匯率fx_rates（ccy_from、ccy_to、率、精確、valid_from）

規則：真相生活在布線日誌中（「ledger_entries」）。當前余額是聚合（實例化截面）或從日誌中計算（價格昂貴，但唯一正確）。

3）錢包的類型及其行為

錢包	為什麼	可以補充	可以註銷	特別規則
CASH	真實金錢	PSP/手動計費/退款	投註、購買、退貨	影響AML/KYC；交易陷入混亂
BONUS	獎金錢	促銷/活動	投註（根據規則）	不直接輸出,在執行增壓器時轉換為Cash
WAGER	計算「凍結」獎金	賽車從獎金在賭註	退款支持遊戲提供商	設置/取消豁免規則
FS (FreeSpins)	旋轉數據包	運動活動	在插槽中還款	T&C固定現金等價物
POINTS	忠誠度/同伴	活動	商店/狀態	不是錢；不屬於AML報告

4）註銷政策和優先次序

明確地形式化資金來源算法：示例（插槽/賭場）：

1.首先從WAGER中註銷（如果有wager活動）。

2.然後從BONUS，直到用盡。

3.余額來自CASH。

示例（體育）：

1.首先是CASH（監管機構/稅收）。

2.然後BONUS（freebet），翻譯成WAGER。

在Postings中保留「策略解決方案」作為屬性，以使劄幌和審計看到「為什麼會註銷」。

5）金錢和運營的生命周期

存款

1. 「POST/wallet/deposit」 →創建一個貼紙記錄（PSP香腸收件箱）。

2.PSP webhook（HMAC簽名，「operation_id」的冪等）→ credit CASH，category=「DEPOSIT」。

3.我們發布「wallet_updated」事件。

投註

1. 「POST/bet/place」 →在源帳戶（CASH/BONUS/WAGER）上創建保留（備份）。

2.在確認費率時，→轉移來源的保管→借款，這是提供商服務「結算」帳戶的信用。

3.取消時為release hold。

設置（結果）

獲勝：debit提供商的「結算」帳戶→ credit CASH或政策WAGER→BONUS→CASH。

損失：我們關閉提供商的「支出」布線→沒有向玩家貸款。

1.KYC/AML驗證，負責任的遊戲限制。

2.保持輸出總和。

3.PSP的成功→最後的借款CASH →信用「付款」。

4.PSP故障→釋放保留。

6）相似性和「意義上」的異常性"

具有唯一索引的「operation_id」（UUID/增強的 ULID）無處不在。重新查詢→過去操作的狀態。

PSP/遊戲提供商 webhooks：收件箱表，從dedupe到「event_id+signature」。加工是Idempotent Worker（Outbox模式）。

客戶端的HTTP上的Idempotency-Key；TTL存儲≥ 24-72小時。

7）儲備和丘陵（holds）

冷卻不是註銷，而是可用余額的「凍結」。

規則：

霍爾壽命：seconds→minutes（費率）或時間（輸出）。
冷藏可以部分或全部償還（部分設置）。
expire-自動釋放和事件。
存儲鏈接「hold_id」 ↔ 「bet_id/withdraw_id」。

8）貨幣,外匯和四舍五入

現金金額為小單位（cents）,類型為整數。

四舍五入的銀行（從頭到尾）或T＆C。

FX：「現金（EUR）」↔「現金（USD）」最好分開錢包。作為單獨的操作進行轉換：

「debit EUR，credit FX_EURUSD'和'debit FX_EURUSD，credit USD」-對審計透明。
在爭議中，自動機「拉近」課程被禁止；所有規則都在FX政策中。

9）負責任的遊戲和限制

Deposit/Bet/Loss/Session限制（每天/每周/每月），「cooling-off」，自我釋放。

在hold/debit之前實現為預檢查。

故障日誌包含在單獨的審計日誌中，sapport和監管機構可以使用。

10）錢包周圍的反親信號

設備/ASN集群，頻繁的少量存款→主要推斷，洗滌模式。

通過BIN/國家/設備在「deposit/withdraw」上限為Velocity。

收件人的清單（錢包/IBAN），「mu子」列表。

錢包事件在功能性評分商店（登錄/存款/投註）中→。

11）一致性和性能

真相vs緩存

真相在於ledger。對於API，「取得平衡」-保持實例化快照（'user_id+ wallet_type → balance_minor，版本'）。

寫作：DB中的事務→使緩存失效。

在「重型」flow（實時）中，短的TTL 1-5與+在輸出/大賭註之前必須進行真相檢查是適當的。

攀巖

通過「user_id」（模塊/排名）進行緩存，在CASH vs BONUS下進行單獨的緩存池。

Hot Keys （VIP/bots）-通過「user_id」進行查詢。

異步聚合（在背景中加上「posting」 → 「snapshot-updater」）。

12） API合同（偽）

平衡

http
GET /v1/wallets?types=CASH,BONUS
→ 200 {"wallets":[
{"type":"CASH","currency":"EUR","available":12050,"hold":500,"version":1942},  {"type":"BONUS","currency":"EUR","available":3000,"wager_req":15000}
]}

投註（持股）

http
POST /v1/bets/place
{"bet_id":"b_123","amount":500,"currency":"EUR","source_policy":"casino_default", "idempotency_key":"ik_abc"}
→ 201 {"status":"HELD","hold_id":"h_789","expires_in":30}

定居點

http
POST /v1/bets/settle
{"bet_id":"b_123","result":"WIN","payout":1250}
→ 200 {"status":"SETTLED","cash_delta":+1250}

http
POST /v1/withdrawals
{"withdraw_id":"w_456","amount":10000,"currency":"EUR","method":"sepa", "idempotency_key":"ik_def"}
→ 202 {"state":"PENDING","next_check_sec":2,"status_url":"/v1/withdrawals/w_456"}

13）接線示例（雙入口）

100歐元押金（PSP fee 1, commis.帳戶是單獨的）


Debit: PSP_Settlements(EUR)   10000
Credit: User.CASH(EUR)         10000

Debit: User.CASH （EUR） 100 （fee transfers）
Credit: PSP_Fees(EUR)          100

BONUS出價5歐元（翻譯成WAGER）


Debit: User.BONUS(EUR)       500
Credit: User.WAGER（EUR）500（移至「vager」）
Debit: User.WAGER(EUR)       500
Credit: Provider.Settlement （EUR） 500（註銷費率）

贏得12歐元。5 →在CASH


Debit: Provider.Settlement(EUR)  1250
Credit: User.CASH(EUR)         1250

持有的註銷（通過HOLD服務帳戶實現）


Debit: User.CASH(EUR)       500
Credit: User.HOLD （EUR） 500（已創建）
-在settle中
Debit: User.HOLD(EUR)       500
Credit: Provider.Settlement(EUR)   500
-取消後
Debit: User.HOLD(EUR)       500
Credit: User.CASH(EUR)         500

14）審核、不變性和合規性

用於日誌的WORM/immutability（對象存儲/WAL歸檔）。

登機記錄：誰閱讀/更改限制，誰進行手動調整（僅通過帶有理由的「調整」）。

GDPR/監管機構：保存5-10年的交易（根據管轄權），玩家計算的透明度（註銷/旅行者的歷史）。

15）容錯和DR

Multi-AZ是必需的；錢包的DR區域：區域中的同步復制，async到區域；PITR包括在內。

Promote standby-僅通過支票單手動進行（不包括split-brain）。

恢復每周檢查（測試還原）,核對校驗報告的金額。

16）錢包的可觀察性

SLI: `deposit_success_ratio`, `withdraw_success_ratio`, `bet_hold_latency_p95`, `settlement_latency_p95`.

Тех: `ledger_postings_rate`, `db_connections_saturation`, `queue_lag_seconds`, `hold_expired_rate`.

Alerts： PSP在市場上的成功率下降,「hold_expired_rate」的增長,遊戲提供商的rassinchron（沒有確認>N min）。

17）測試和質量控制

與PSP/遊戲提供商的合同測試（webhooks/簽名）。

基於財產的貨幣測試：借方總和==每個郵政的貸款總和。

Fuzz/chaos： PSP/提供程序延遲, webhook重播,network flappy。

負載：爆破投註（60-120秒），soaks（4-8小時），控制「queue_lag」和p99。

18）生產就緒支票清單

雙重錄音ledger，所有通過Posting的操作均帶有「operation_id」。
清晰的間諜政策和優先順序（隨帖子一起進行）。
Holds with TTL/partial settle/expiry, bet/withdraw鏈接。
Inbox/Outbox，HMAC webhooks，在所有邊界上均具有等效性。
個別錢包CASH/BONUS/WAGER/FS/POINTS；按貨幣劃分。
小單位的FX和四舍五入；轉換是一個單獨的操作。
負責任的遊戲限制為hold/debit；故障審核。
讀取緩存（簡稱TTL）+在關鍵行動之前強制檢查真相。
PITR/備份/DR腳本；手動promote，定期DR演習。
Dashbords/Alerts SLI+技術；WORM邏輯和訪問日誌。
負載/混沌測試；與PSP/提供商重新聯系的報告。

二.總結

多錢包體系結構不是「很多資產負債表數字」，而是具有雙重記錄，支出策略，保留和透明跟蹤的財務系統，用於審計和玩家。在日誌中保持真相，使用冰雹和偶然性，分開錢包和貨幣，自動重新計算和DR。因此，錢包對於UX來說將是快速的，對金錢來說是準確的，並且可以抵抗高峰負荷和監管檢查。