Database ledger, treasury settlement
The delivered design uses a database ledger and signed ERC-20 transfers. An earlier vault-contract design was superseded.
Case 03 · Commission & payout system
Ambassador Program
Each payout has to trace back to the commission that earned it.
I built the commission and payout system behind the Phil Ambassador Program: attribution, a commission ledger, member APIs, treasury transfers and the member and operations interfaces.
Result
The program backend and backoffice API reached production in September 2026. Member and admin interfaces were delivered to development; production promotion is a separate release step.
My part
What I did
Commission earnings must remain explainable from the original activity through to the final transfer. Retries, pending transactions and concurrent claims must not silently produce duplicate payouts.
01
Commission accounting
Built network attribution, commission accrual and the ledger behind member earnings.
02
Treasury payments
Implemented payout reservation, KMS-signed token transfers, transaction tracking and receipt reconciliation.
03
Product surfaces
Built member views and operations tooling, connecting eligibility, balances, payout history and administrative appointment.
How it worksSimplified walkthrough. No live transactions.
Follow the money from earning to receipt
Business events + referral network
Qualifying activity is associated with the correct ambassador network before a commission is accrued.
Activity → attribution → commissionEvery commission needs a business source.Example state, not live data
- Ledger
- Accrued
- Transfer
- Not submitted
- Member view
- Earnings
PostgreSQL ledger
Commission entries are kept in the database ledger. A payout reserves the relevant balance transactionally.
Accrued → reservedConcurrent payout requests must not reserve the same earnings.Example state, not live data
- Ledger
- Reserved
- Transfer
- Prepared
- Member view
- Reserved balance
Treasury + AWS KMS
The treasury transfer is signed through AWS KMS. The transaction is identified before broadcast so submission and later reconciliation refer to the same payment.
Reserved → submittedThe ledger balance and treasury transfer are separate concerns.Example state, not live data
- Ledger
- Reserved
- Transfer
- Submitted
- Member view
- Payment pending
Receipt monitor + member API
The monitor checks the transaction receipt and reconciles the payout status shown to the member.
Submitted → receipt → final statusA pending transaction is not presented as a completed payment.Example state, not live data
- Ledger
- Paid
- Transfer
- Receipt confirmed
- Member view
- Payment complete
Trade-offs
Decisions I made
Make status useful to the member
Separate available earnings, reserved funds and transaction state so the interface can explain where a payment is in the process.
Links and records
See the work
Implementation walkthrough
The ledger-to-treasury flow above
Reconstructs the delivered accounting and payout architecture from the implementation records.
Release scope
Backend shipped; interfaces in development
September release records distinguish deployed APIs from the development-stage member and admin screens.
Status follows the September 2026 implementation and release records. Ambassador appointment is managed through the backoffice.
Backend and backoffice API in production; member and administrative screens delivered to development.