StackTrading Docs

UC 7.4

Flow 5 - Immutable Ledger: ghi event CorporateMetricVerified lên Polygon qua POST /api/ledger/record và đẩy Journal Entry sang QuickBooks song song

FieldValue
BA in ChargeAnh Hoang
Date Created2026-10-12
Versionv1.6
Document ReferencesZapier Integration V7.pdf (§Flow 5 — Immutable Ledger Logging) · RFQ_ Stack Trading Prop Tech V7.pdf (§3.1 mục 7 Immutable Ledger · §3.2 Record Immutable Ledger POST /api/ledger/record · Public Ledger Feed GET /public/ledger · §3.4 Financial GL QuickBooks Online · §3.6 / §3.6.1 Smart Contract) · QnA from clients — QnA_STAGE5_PAYOUT_WITHDRAWAL.md (A-30, A-33, A-36, A-65, A-68, A-96, A-97, A-107) · Common Rules CR-08

UC_7.4 — Flow 5: Immutable Ledger

🇻🇳 Section này viết bằng tiếng Việt để BA review. Mọi ID, anchor, tên field/API và text hiển thị cho user giữ nguyên tiếng Anh.

1. Overview

FieldContent
IDUC_7.4
Use CaseFlow 5: Immutable Ledger
DescriptionUC này ghi lại mỗi khoản tiền thưởng đã trả cho trader ở 2 nơi. Nơi thứ nhất là Immutable Ledger, một sổ công khai trên blockchain Polygon: ai cũng xem được và đã ghi thì không xoá, không sửa được, để chứng minh Stack Trading thật sự trả tiền. Nơi thứ hai là QuickBooks Online, sổ kế toán nội bộ của Stack Trading; chỉ ghi khoản trả qua Dots cho trader contractor, còn khoản trả lương W-2 qua Rippling do Rippling tự đồng bộ sang QuickBooks.
Zapier FlowFlow 5 (Payouts — Bonus), bước "Immutable Ledger Logging". Chạy sau UC_7.3 (Routing & Execution)
Zapier TableKhông đọc Table nào
APIPOST /api/ledger/record (Record Immutable Ledger) · POST /financial/qbo-log-payout · QuickBooks Online API (POST /v3/company/{realmId}/journalentry)
Cron Job taskKhông có. Ledger Retry Queue là worker chạy liên tục để thử ghi lại, xem BR_7.4.2
3rd PartyPolygon PoS (qua Alchemy RPC), QuickBooks Online

2. Trigger

  • UC_7.3 đạt mốc thành công: Dots hoặc Rippling trả kết quả thành công và Middleware đã lưu provider_transaction_id (Ref: UC_7.3 BR_7.3.4).

3. Pre-conditions

  • Contract StackTradingLedger đã được deploy lên Polygon PoS Mainnet (BR_7.4.1). Địa chỉ contract và private key của owner wallet nằm trong biến môi trường của Middleware. Owner wallet là ví đã deploy contract, và chỉ ví này ghi được lên contract.
  • Bản ghi payout có số tiền và provider_transaction_id.

4. Post-conditions

  • Polygon có một event CorporateMetricVerified cho payout này, và tx_hash được lưu trong PostgreSQL gắn với bản ghi payout.
  • Payout trả qua Dots (Path A, Path B): QuickBooks Online có một Journal Entry cho payout này. Payout trả qua Rippling (Path C) không có Journal Entry do UC này tạo.
  • Mỗi level là một bản ghi payout riêng (BR_7.4.3). VD: trader lên 3 level trong lúc hồ sơ bị giữ thì có 3 event Polygon và 3 Journal Entry.

5. Basic Flow

Stage 1 và Stage 2 chạy song song, không chờ nhau, và không được bỏ Stage 2 với payout trả qua Dots.

5.1 Ghi Immutable Ledger

Stage 1 — Ghi event lên Polygon

  1. Zapier Flow 5 gọi POST /api/ledger/record (Record Immutable Ledger):

    Input fieldValue
    trader_idDiscord username dễ đọc của trader, VD trader_steve. Trader chưa liên kết Discord thì dùng platform_username. Không bao giờ ghi user_id (UUID) (BR_7.4.5)
    metric_category"Level Profit Target"
    metric_value"$[Payout_Amount] Bonus Cleared", có số tiền thật. VD "$41,250 Bonus Cleared". Với trader Futures lên Level 3, Payout_Amount gồm cả tiền hoàn phí market data (BR_7.4.6)
    dateNgày hôm nay (UTC, CR-08)
    receipt_hashprovider_transaction_id của lệnh trả tiền ở UC_7.3

    Mọi khoản thưởng thành tích đều do Flow 5 ghi với metric_category = "Level Profit Target", kể cả trader W-2 Level 6 trở lên trả qua Rippling và khoản Level 24. Lương, retainer, severance do Flow 34 đến Flow 36 ghi với metric_category khác. Lệnh ở UC_7.3 bị timeout hoặc Failed thì xem E_7.4.1. Tiền thưởng của lần lên level là $0 thì xem E_7.4.4.

  2. Middleware tạo Ethers.js wallet phía server bằng private key của owner wallet trong biến môi trường bảo mật. Ethers.js là thư viện Node.js dùng để ký và gửi transaction.

  3. Middleware gọi contract.recordMetric() qua Alchemy RPC để ghi metric lên smart contract. Alchemy RPC là dịch vụ gửi transaction lên Polygon. Cách ánh xạ input sang event xem BR_7.4.1. Contract emit event CorporateMetricVerified. Gọi lỗi thì xem E_7.4.2.

  4. Middleware chờ Polygon xác nhận, rồi lưu tx_hash vào PostgreSQL gắn với bản ghi payout. tx_hash là mã transaction trên Polygon, tra được trên PolygonScan.

  5. Middleware trả { "status": "success", "tx_hash": "<hash>" }.

  6. Khi đã lưu tx_hash:

    • GET /public/ledger trả event này trong danh sách 50 event gần nhất và tăng total_verified_milestones. Cache làm mới mỗi 5 phút (UC_1.3.2).
    • Điều kiện thứ 2 của WebSocket "Payout Completed" được thoả (UC_7.3 BR_7.3.7).

5.2 Ghi sổ kế toán QuickBooks (chỉ payout trả qua Dots)

Stage 2 — Tạo Journal Entry (song song Stage 1)

  1. Payout trả qua Rippling (Path C, trader US W-2) thì bỏ qua Stage 2. Rippling tự đồng bộ khoản này sang QuickBooks bằng tích hợp có sẵn giữa Rippling và QuickBooks; Sotatek không làm phần này.

  2. Ngay sau khi bước gửi lệnh Dots của Flow 5 trả thành công cho Zapier (UC_7.3, Path A hoặc Path B), Zapier gọi webhook tới endpoint nội bộ mới POST /financial/qbo-log-payout của Middleware, kèm số tiền payout. Mỗi bản ghi payout gọi 1 lần, với số tiền của riêng level đó (BR_7.4.3).

  3. Middleware dựng Journal Entry 2 dòng và gọi QuickBooks Online API POST /v3/company/{realmId}/journalentry (BR_7.4.4):

    PostingTypeTài khoảnSố tiền
    Debit5035 Trader Performance Bonuses (chi phí)Số tiền payout
    Credit1102 DOTS (tài sản)Số tiền payout

    VD: trader Level 3 là contractor nhận bonus $2,000 qua Dots. Journal Entry gồm Debit 5035 $2,000 và Credit 1102 $2,000. QuickBooks lỗi thì xem E_7.4.3.

6. Exceptional Flows

Exception IDExceptionConditionSystem Handling / Fallback
E_7.4.1Lệnh trả tiền không thành côngLệnh ở UC_7.3 bị timeout hoặc payout_status = 'Failed'.UC này không chạy: không ghi Polygon, không tạo Journal Entry (Ref: UC_7.3 BR_7.3.5, UC_7.3 BR_7.3.6). Kể cả khi sau đó Operations xử lý tay và trả tiền thành công thì cũng không ghi lên Polygon.
E_7.4.2Ghi Polygon lỗi (Ref: BR_7.4.2)Mất kết nối, gas tăng, mạng nghẽn, hoặc transaction không được xác nhận.Middleware đưa payload vào Ledger Retry Queue và thử lại tới khi có tx_hash, không bao giờ bỏ event. Có tx_hash thì lưu như bước 4. Trong lúc chờ, WebSocket "Payout Completed" chưa được gửi và GET /public/ledger chưa có event này. Stage 2 không bị ảnh hưởng.
E_7.4.3QuickBooks lỗi (Ref: BR_7.4.4)Gửi Journal Entry sang QuickBooks không thành công.Lỗi mạng hoặc lỗi 5xx: Middleware thử lại tối đa 3 lần, mỗi lần chờ lâu hơn lần trước. Lỗi 4xx (dữ liệu không hợp lệ): không thử lại. Vẫn lỗi thì gửi Slack alert vào #ops-treasury theo mẫu `[QBO SYNC FAILED] User ID: {user_id}
E_7.4.4Tiền thưởng bằng $0Tiền thưởng của lần lên level là $0, VD theo bảng hiện tại thì Level 1 lên Level 2 không có thưởng.Không ghi lên Polygon. QuickBooks cũng không nhận dòng $0 nên không tạo Journal Entry. Middleware so giá trị tiền thưởng với $0, không hardcode theo level: nếu sau này bảng thưởng đổi Level 1 thành $100 thì khoản đó vẫn được ghi bình thường.

7. Business Rules

BR_IDRule Description
BR_7.4.1Smart Contract: Chỉ có một smart contract StackTradingLedger trên Polygon PoS Mainnet. Không dựng blockchain riêng, không chạy node riêng; tiền thật không đi qua blockchain.Deploy đúng code trong RFQ_ Stack Trading Prop Tech V7.pdf §3.6.1. Ghi thành công thì trả tx_hash.Ánh xạ input của endpoint sang field của event CorporateMetricVerified: trader_id thành traderId; metric_category thành metricCategory; metric_value thành metricValue; date thành timestamp; receipt_hash thành verificationHash.receipt_hash là mã giao dịch Dots hoặc Rippling của lệnh trả tiền (provider_transaction_id từ UC_7.3).Dữ liệu on-chain là công khai và vĩnh viễn: ghi sai thì không sửa được.
BR_7.4.2Ghi Polygon lỗi thì thử lại, không bao giờ bỏ: Ledger Retry Queue là worker trong Middleware chạy liên tục. Worker gọi lại contract.recordMetric(), mỗi lần chờ lâu hơn lần trước (exponential backoff), tới khi có tx_hash. Không được bỏ event.Hàng chờ phải bền vững: payload không được mất khi Middleware khởi động lại.Số lần thử và khoảng chờ do Sotatek tự quyết. Quá số lần thử thì gửi Slack alert vào #ops-dev (C0BRCDB8U3U, CR-15.2) theo mẫu `[LEDGER SYNC FAILED] User ID: {user_id}
BR_7.4.3Ghi sổ tách theo từng level: Trader lên nhiều level trong lúc hồ sơ Dots bị giữ thì UC_7.3 gửi 1 lệnh tổng sang Dots hoặc Rippling (UC_7.3 BR_7.3.2), nhưng mỗi level vẫn là một sự kiện tài chính và một bản ghi payout riêng.Mỗi bản ghi payout gọi POST /api/ledger/record một lần và, nếu trả qua Dots, tạo một Journal Entry, với số tiền của riêng level đó. receipt_hash của các event là cùng provider_transaction_id của lệnh tổng. VD: Level 2 $1,000, Level 3 $2,000, Level 4 $3,000 được trả bằng 1 lệnh $6,000; UC này ghi 3 event Polygon và 3 Journal Entry ($1,000, $2,000, $3,000).
BR_7.4.4Journal Entry QuickBooks cho payout Dots: Chỉ ghi payout trả qua Dots (trader contractor). Payout trả lương W-2 qua Rippling do tích hợp Rippling và QuickBooks tự ghi.Middleware chỉ ghi số tiền gross ngay lúc payout thành công: không tính phí chuyển tiền, phí đổi tiền hay tiền bị giữ lại. Việc đối soát do kế toán Stack Trading làm trong QuickBooks.Gọi POST /v3/company/{realmId}/journalentry để tạo Journal Entry, không dùng đối tượng Expense. Đây là lệnh đẩy một chiều.Quy tắc trường: Amount luôn là số dương (QuickBooks từ chối số âm); PostingType là "Debit" hoặc "Credit"; DetailType luôn là "JournalEntryLineDetail"; JournalEntryLineDetail.AccountRef.value là ID của tài khoản trong Chart of Accounts.TxnDate, Line[].Description và PrivateNote không bắt buộc. Bỏ TxnDate thì QuickBooks lấy ngày hôm nay. Description có thể ghi User ID: [user_id].Gửi lỗi thì thử lại tối đa 3 lần với lỗi mạng hoặc 5xx, không thử lại lỗi 4xx; vẫn lỗi thì gửi Slack alert vào #ops-treasury (Prod C0BRCCMN1MG, Test #test-ops-treasury C0BRCBMGTC2) và tiếp tục flow (E_7.4.3).
BR_7.4.5Trader hiện trên sổ công khai bằng gì (trader_id): Không bao giờ ghi user_id (UUID nội bộ) lên blockchain.Dùng Discord username dễ đọc của trader, VD trader_steve hoặc lily_trades_FX_123, nếu trader đã liên kết Discord qua lệnh /link. Không dùng discord_user_id dạng số, vì sổ công khai để chứng minh việc trả tiền: cộng đồng nhận ra được username trong server, còn dãy số thì không.Trader chưa liên kết Discord thì dùng platform_username.Lệnh /link hiện chỉ lưu discord_user_id. Lệnh này phải lưu thêm Discord username vào bảng Users để dùng ở đây. Tên cột do BE chốt.Dữ liệu on-chain không sửa được, nên giá trị này phải đúng ngay từ dòng đầu tiên.
BR_7.4.6Tiền hoàn phí Level 3 ghi chung với tiền thưởng: Trader Futures lên Level 3 nhận tiền thưởng và tiền hoàn phí market data của Level 1–2 trong cùng một lệnh. Lệnh này được ghi chung thành một khoản, cả trên Polygon và trong QuickBooks. VD: tiền thưởng $1,000 và tiền hoàn phí $275 thì metric_value là "$1,275 Bonus Cleared", và Journal Entry ghi 5035 với 1102 cùng số $1,275.

8. Open Items

Không còn hạng mục mở. Chi tiết: QnA_init_docs.md.

9. Phân chia trách nhiệm

Hạng mụcSotatek buildStack Trading OpsBên thứ 3
Viết và deploy smart contract lên Polygon Mainnet✅—Polygon
Endpoint POST /api/ledger/record, Ledger Retry Queue✅—Alchemy
Giữ private key owner wallet, nạp gas, tài khoản Alchemy—✅—
Bước Zap Flow 5 "Immutable Ledger Logging"✅—Zapier
Bước Zap Flow 5 gọi webhook POST /financial/qbo-log-payout sau khi Dots trả thành công✅—Zapier
Lệnh Discord /link lưu thêm Discord username vào Users✅—Discord
Endpoint POST /financial/qbo-log-payout, gửi Journal Entry sang QuickBooks Online✅—QuickBooks
Cung cấp ID tài khoản trong Chart of Accounts và quyền kết nối QuickBooks—✅—
Ghi sổ QuickBooks cho payout W-2 qua Rippling——Rippling (tích hợp sẵn với QuickBooks)
Đối soát phí và tiền trong QuickBooks—✅ Kế toán Stack TradingQuickBooks

Changelog

DateVersionUpdated itemBeforeAfterNotes
2026-10-12v1Initial document——Bản tiếng Việt để BA re-check, viết theo template UC_8.1.1. Câu hỏi còn mở xem QnA_init_docs.md — chưa đưa vào UC. QnA bổ sung so với spec V7: (1) QuickBooks song song — Zapier V7 §Flow 5 không có bước GL; A-65: "the QuickBooks API push must run concurrently with the Immutable Ledger update… Do not drop the QuickBooks integration." (2) Retry — A-30 / Adrian Q6: "retry queue with exponential backoff… must not drop the event."
2026-10-12v1Thêm mục "API & Tác vụ nền"; Stage 1, Stage 2, Pre-conditionsAPI và retry queue chỉ mô tả rải rác trong luồng; không có spec Input/Output dạng bảng; retry queue không được định nghĩa như một tác vụ nềnThêm API-1 (POST /api/ledger/record — auth, input type, output), API-2 (recordMetric() + event + revert), API-3 (QuickBooks Journal Entry), JOB-1 (Ledger Retry Queue — chạy liên tục, hàng chờ bền vững). Thêm pre-condition gas cho owner wallet. Trigger ghi theo payout_status = 'Confirmed'Theo yêu cầu BA: UC phải ghi đủ API và tác vụ nền. Nguồn: RFQ V7 §3.2, §3.6.1; A-30; A-65 ("internal journal entry"). Xử lý khi QuickBooks lỗi vẫn mở ở QnA N-01.
2026-10-12v1Basic Flow Stage 1, Stage 2Tên API trong luồng không nhất quán, QuickBooks chỉ ghi chung "QuickBooks Online API"Mỗi bước gọi API ghi rõ mã + tên (API-1 POST /api/ledger/record, API-2 recordMetric(), API-3 QuickBooks — tạo Journal Entry, GET /public/ledger)Theo yêu cầu BA: API phải xuất hiện ngay trong basic flow.
2026-10-13v1Stage 1 metric_value, Post-conditions, BR_7.4.3 (mới)metric_value = "Payout Cleared" — chuỗi cố định, không kèm số tiền. Chưa có rule về payout gộp nhiều levelmetric_value = "$[Payout_Amount] Bonus Cleared". Thêm BR_7.4.3: mỗi level một bản ghi, 1 event Polygon + 1 Journal Entry QuickBooks / levelKhách đã trả lời: A-97 — "Update the metric_value string to dynamically include the actual dollar amount and use the word "Bonus" instead of "Payout"." A-68 · A-96 — không gộp; 3 level → 3 dòng ledger + 3 bút toán QuickBooks.
2026-10-14v1Toàn UC — viết lại theo khuôn UC_8.1.xCó bảng Thuật ngữ; mục "API & Tác vụ nền" liệt kê 3 API + 1 job: API-1 POST /api/ledger/record, API-2 Smart contract call recordMetric(), API-3 QuickBooks Online (Journal Entry), JOB-1 Ledger Retry Queue; Basic Flow tham chiếu mã API-n / JOB-1; lỗi QuickBooks chờ chốt ghi trong bảng API-3Bỏ bảng Thuật ngữ (giải thích ngay câu dùng lần đầu). Bỏ mục "API & Tác vụ nền": còn 2 API đúng như nguồn — POST /api/ledger/record (Zapier → Middleware) và QuickBooks Online API (Journal Entry). Gọi contract.recordMetric() qua Alchemy RPC là bước 2.3 bên trong xử lý POST /api/ledger/record (như UC_8.1.1 Stage 1 bước 6); chữ ký hàm + event chuyển vào BR_7.4.1. Ledger Retry Queue là nhánh [If …] tại Stage 1 bước 2.3, đặc tả (worker chạy liên tục, hàng chờ bền vững, báo Ops khi quá số lần) chuyển vào BR_7.4.2. Revert ví không phải owner và JWT sai thành nhánh [If …] trong bước. Thêm mục Open Items (N-01 — xử lý khi QuickBooks lỗi, trước nằm trong bảng API-3)Theo yêu cầu BA: mô tả và thứ tự như UC_8.1.1 / UC_8.1.2. Nội dung nghiệp vụ và BR ID giữ nguyên. Sửa số API cho khớp nguồn: Zapier Integration V7.pdf §Flow 5 Immutable Ledger Logging chỉ có 1 endpoint POST /api/ledger/record; RFQ_ Stack Trading Prop Tech V7.pdf §3.2 Record Immutable Ledger ghi contract.recordMetric() là logic bên trong endpoint này; QuickBooks theo QnA A-65.
2026-10-14v1Description, Trigger, Stage 1Điều kiện chạy: payout_status = 'Confirmed'Điều kiện chạy: Dots / Rippling nhận lệnh thành công, có provider_transaction_id; không chạy khi timeout hoặc payout_status = 'Failed'Theo UC_7.3: bỏ trạng thái Pending / Sent / Confirmed (đề xuất [ASSUMPTION] A-26, khách không chốt). Không đổi nghiệp vụ.
2026-10-15v1BR_7.4.1, Pre-conditions, Stage 1 bước 2.3BR_7.4.1 mô tả chi tiết code contract: không dùng state variable (tiết kiệm gas), chữ ký đầy đủ hàm recordMetric(...), chỉ owner wallet được ghi / ví khác revert "Unauthorized to write to ledger". Bước 2.3 có nhánh [If ví gọi không phải owner wallet]BR_7.4.1 chỉ giữ: một contract trên Polygon PoS Mainnet, deploy đúng code V7 §3.6.1, ánh xạ input → event, receipt_hash, dữ liệu on-chain vĩnh viễn. Ý "chỉ owner wallet ghi được" chuyển vào Pre-conditions. Bỏ nhánh revert ở bước 2.3Khách đã cung cấp nguyên code Solidity (RFQ_ Stack Trading Prop Tech V7.pdf §3.6.1 — "The exact required Solidity implementation"), Sotatek chỉ deploy đúng code; chi tiết bên trong code không cần đặc tả lại. Middleware luôn ký bằng owner wallet nên nhánh revert không xảy ra trong luồng. Không đổi nghiệp vụ.
2026-10-29v1.1Toàn UC — cấu trúc lại theo khuôn UC_1.8.7Description ghi chi tiết cách ký transaction, Alchemy RPC, retry queue; các nhánh lỗi [If …] nằm trong bước; bước 2 có bước con 2.1 đến 2.5; bước đánh số lại từ 1 ở mỗi Stage; BR_7.4.1 có bảng ánh xạ riêngDescription chỉ ghi tổng quan. Mục đánh số 1 đến 9; §5 chia 5.1 ghi Immutable Ledger, 5.2 ghi QuickBooks; bước đánh số liên tục 1 đến 8 (bước con cũ 2.1 đến 2.5 thành bước 2 đến 6). Thêm bảng §6 Exceptional Flows (E_7.4.1 đến E_7.4.4). 3 BR gom vào bảng §7, bảng ánh xạ input sang event viết thành câu trong BR_7.4.1. Overview thêm dòng API và Cron Job task. Mọi BR đều được refer từ bước hoặc exception liên quan. Giữ nguyên anchor BR_7.4.1 đến BR_7.4.3, UC_7.4-OIBA yêu cầu viết dễ hiểu như UC_1.8.7, không đổi nghiệp vụ
2026-10-29v1.2§5.1 bước 2 · §6 E_7.4.2Middleware kiểm tra chữ ký Zapier JWT khi nhận POST /api/ledger/record; chữ ký sai thì từ chối (E_7.4.2)Bỏ bước kiểm tra chữ ký và E_7.4.2; bước 3 đến 8 đánh lại thành 2 đến 7, E_7.4.3 và E_7.4.4 thành E_7.4.2 và E_7.4.3BA chốt 2026-10-29: yêu cầu bảo mật chung, khách không trả lời riêng cho flow này thì không đưa vào UC
2026-10-29v1.3BR_7.4.3"Mỗi level một bản ghi, không gộp": mỗi level được trả bằng lệnh riêng"Ghi sổ tách theo từng level": UC_7.3 gửi 1 lệnh tổng, UC này vẫn ghi 1 event Polygon và 1 Journal Entry cho mỗi level; receipt_hash là cùng provider_transaction_id của lệnh tổngTheo UC_7.3 v1.2, BA chốt 2026-10-29
2026-10-30v1.4Overview (Description, API) · Post-conditions · §5.2 Stage 2 (bước 7 đến 9) · BR_7.4.3 · BR_7.4.4 (mới) · §9Middleware gọi QuickBooks Online API cùng lúc với bước 1 cho mọi payout; input user_id, số tiền Gross, ngày, Account là "General expense account"; Chart of Accounts qua ClickUpChỉ payout trả qua Dots (Path A, B). Sau khi bước Dots của Flow 5 trả thành công, Zapier gọi webhook mới POST /financial/qbo-log-payout kèm số tiền; Middleware gửi Journal Entry 2 dòng qua POST /v3/company/{realmId}/journalentry: Debit 5035 Trader Performance Bonuses, Credit 1102 DOTS. Payout Rippling (Path C) do tích hợp Rippling và QuickBooks tự ghi. Thêm BR_7.4.4 (chỉ ghi gross, quy tắc trường). RACI: Stack Trading cung cấp ID Chart of Accounts và quyền kết nốiTheo "QuickBooks Integration Specification" khách gửi, chỉ lấy phần cho Flow 5: §1 (Gross, Rippling Exclusion), §2 (Payload), §4A (Trader Performance Bonuses). Bỏ các phần không liên quan: checkout, Deferred Revenue, Flow 7 separation
2026-10-30v1.5BR_7.4.2 · BR_7.4.4 · E_7.4.3 · §8 Open Items (N-01)Ghi Polygon quá số lần thử thì "báo Operations", chưa có mẫu; QuickBooks lỗi chưa chốt cách xử lý (N-01)Polygon quá số lần thử: Slack #ops-dev mẫu [LEDGER SYNC FAILED] …. QuickBooks lỗi: thử lại 3 lần, mỗi lần chờ lâu hơn, chỉ với lỗi mạng hoặc 5xx, không thử lại lỗi 4xx; vẫn lỗi thì Slack #ops-treasury mẫu [QBO SYNC FAILED] … và tiếp tục flow. Đóng N-01Khách trả lời câu hỏi về cách xử lý lỗi Flow 5. Kênh #dev_ops khách ghi đã đổi tên thành #ops-dev theo CR-15.2
2026-10-30v1.6§5.1 bước 1 (trader_id, metric_value) · E_7.4.1 · E_7.4.4 (mới) · BR_7.4.5, BR_7.4.6 (mới) · §9trader_id là user_id; chưa chốt: tiền hoàn phí Level 3 ghi chung hay tách (A-105), lệnh lỗi rồi Ops trả tay có ghi Polygon không (A-82), khoản $0 có ghi không (A-35), trader hiện bằng gì trên sổ công khai (A-98)trader_id là Discord username dễ đọc, chưa liên kết thì platform_username, không ghi user_id; lệnh /link lưu thêm Discord username. Tiền hoàn phí Level 3 ghi chung với tiền thưởng. Lệnh lỗi rồi Ops trả tay: không ghi Polygon. Tiền thưởng $0: không ghi, so giá trị, không hardcode levelA-105: BA chốt 2026-10-30. A-82, A-35, A-98: khách đã trả lời

On this page