Balances, custody & payouts

A double-entry ledger in PostgreSQL is the live system of record: balanced journals, materialized balances that can never go negative, and atomic reservations that move buyer funds into a hold and settle or release them in one transaction. USDG deposits are verified on-chain and credited idempotently; inference charges capture from the reservation; supplier payout requests escrow pending operator settlement. Withdrawals work the same way: a request escrows the amount into a hold instantly (cancelable while pending), and an operator settles it on-chain back to the requester's verified wallet — refunds use the identical path.

A wallet login proves control of an address for authentication. It does not authorize the platform to move tokens. Payment and approval requests, if introduced, require separate explicit user actions and accurate transaction details.

Buyer funding on Robinhood Chain
  → confirmed service credit
  → bounded usage reservation
  → actual charge and release of unused reservation
  → supplier payable
  → approved on-chain payout

The provisional approach is small, capped prepaid service balances with segregated treasury controls. This is still custody; calling money ‘credits’ does not remove obligations. The operating jurisdiction, terms, refunds, withdrawal rights, and treasury arrangements remain decision gates.

• Append-only accounting records with corrections made through reversals, not silent edits.
• Exact monetary units, explicit rounding, and consistent asset/chain identifiers.
• Atomic reservations that prevent concurrent requests from overspending.
• Idempotency for deposits, requests, charges, refunds, and payouts.
• Reconciliation between on-chain funds, available balances, held amounts, and supplier liabilities.
• Auditable operator actions, separation of duties, exposure limits, and incident controls.
• No unrestricted treasury private key in the application container.

A contract-based escrow or payment channel can limit some operator discretion, but it introduces contract risk, audits, withdrawal rules, and difficult delivery/dispute questions. A transfer receipt does not prove that a model ran correctly or that an answer was useful.

If independent withdrawal rights or minimizing operator custody becomes a non-negotiable launch requirement, the financial design must be revisited before deposits open. That decision cannot be hidden behind a frontend wallet button.

1. Resolve jurisdiction, operating entity, custody, supplier terms, and refund/withdrawal policy.
2. Implement and test the ledger and chain-event reconciliation.
3. Establish restricted treasury signing and payout approvals.
4. Test failure and recovery paths in isolated environments and on testnet.
5. Complete security review and operational readiness checks.
6. Authorize a limited mainnet pilot with defined exposure caps and stop conditions.