OFM money, ledger, and payouts domain

Status: owned by OFM-MONEY; urgent map and evidence campaign complete; report is read-only research, not implementation authorization. Date: 2026-08-29

Executive decision

HALO should own the truth and liability workflow from platform sale to reconciled creator/referral/staff statement. A payout provider may move money, but it must never become the ledger. The first product is therefore a server-authoritative, append-only money event and double-entry layer with explicit attribution, contract-effective splits, holds, approvals, partials, reversals, disputes, FX snapshots, and export. Buzz is the fixed coordination/agent plane for review threads and approvals; it does not own money records, balances, or permission decisions.

The existing HALO money surfaces are a useful operational shell—creator invoice cycles, manual payment receipts, referral remittances, payroll/attendance, recurring expenses, and a merged payment log—but they are not yet a ledger-grade source of truth. The recommendation is to characterize and preserve those workflows, then replace their floating, mutable calculations with a canonical money event → journal → statement path.

Persona and authority matrix

Authority rule: every money read or write resolves tenant, actor, role, resource, contract version, source event, idempotency key, and audit requirement on the server. A UI role, Buzz membership, or client-supplied actor identifier is not authorization.

End-to-end operating journey: gross sale to reconciled statements

1. Enter and preserve source truth. A platform report, webhook, or approved manual

import arrives with provider, account, source event/transaction ID, occurred-at and settled-at times, currency, gross, provider fee, net, creator/account identity and raw-file hash. Replays are idempotent; late, duplicate, out-of-order and amended reports remain visible rather than overwriting history.

1. Resolve identity and attribution. Match the platform account to a HALO creator;

link chatter/operator, campaign/content/custom request and referral only when there is evidence and an effective rule. Unmatched or conflicting sales enter an exception queue. A platform account, creator, and referral are separate identities.

1. Normalize money. Store integer minor units plus ISO currency and precision; retain

the provider amount and FX source/rate/time. Separate gross, platform fees, refunds, chargebacks, taxes, agency revenue and creator/referral/staff liabilities. Never use a live FX quote to rewrite a posted statement.

1. Apply effective terms. Select the contract/rate-card/commission rule effective at

the sale time. Calculate creator liability, agency share, referral commission and any approved chatter incentive as separate lines. A missing term blocks settlement; it does not silently become 50/50.

1. Hold and close. Keep pending/held funds distinct from earned/available funds until

the configured settlement window, refund window and evidence requirements pass. Close a period with a versioned snapshot; post corrections as reversing/adjusting entries.

1. Review and approve. Finance resolves data exceptions; a manager may confirm an

operational attribution; the owner or delegated approver approves a payout batch. Every decision records actor, reason, threshold, source evidence and policy version.

1. Issue statements and payable documents. Generate creator, referral and staff

statements from the same posted journal. Show source sales, fees, deductions, FX, opening balance, current-period activity, prior payments, remaining liability and dispute window. An invoice PDF is a view of the books, not a new balance.

1. Execute through a rail. Send only an approved, immutable batch to a bank/PSP/

payout provider with a client-supplied idempotency key. Store provider transfer ID, submitted/accepted/settled/returned status and evidence. A timeout is unknown, not paid; the operator must reconcile before retrying.

1. Handle partials, reversals and disputes. Apply each instalment to a payable;

record return, refund, chargeback, fee or write-off as a new journal event; preserve the original. Freeze the disputed line, notify affected personas, and reopen the exception if evidence or approval expires.

1. Reconcile and close/export. Compare platform settlement reports, bank/rail

statements, provider fees, HALO journal and outstanding liabilities. Produce a difference report and close only when every difference is accepted or owned. Export creator/partner statements, tax evidence, source files, journal, audit history and offboarding data without exposing other people’s records.

Failure states that must be first-class: duplicate/replayed import, unknown identity, conflicting attribution, missing contract, stale FX, platform fee mismatch, refund or chargeback after payout, partial transfer, rail timeout/return, missing receipt, expired approval, period lock conflict, cross-tenant access attempt and creator departure while a liability remains open.

Feature and sub-app tree (urgent map)

Money, ledger, and payouts
├── Ingestion and evidence
│   ├── platform report/webhook connectors and cursors
│   ├── raw immutable source archive + hashes
│   ├── import preview, mapping, dedupe and replay/dead-letter queue
│   └── provider settlement, bank and payout-rail adapters
├── Attribution and rules
│   ├── creator ↔ platform-account identity map
│   ├── chatter/campaign/content/referral attribution
│   ├── contract/rate-card/commission versions and effective dates
│   ├── fee, tax, hold, refund and chargeback policies
│   └── explainable calculation preview and exception queue
├── Canonical accounting core
│   ├── integer minor-unit money + currency/FX snapshots
│   ├── accounts, journal entries, postings and period locks
│   ├── creator/referral/staff liability subledgers
│   ├── agency revenue, expenses and clearing accounts
│   └── append-only audit, correction/reversal and idempotency primitives
├── Statements and payables
│   ├── creator statements and dispute window
│   ├── referral commission/remittance statements
│   ├── chatter incentive and staff payroll inputs
│   ├── invoice/approval/payout-batch workflow
│   └── creator/partner/self-service portal views with row-level scope
├── Reconciliation and close
│   ├── platform ↔ journal ↔ bank/rail three-way reconciliation
│   ├── unmatched/missing/duplicate/over/under payment queues
│   ├── partial, returned, refunded and chargeback handling
│   ├── period close, reopen and close checklist
│   └── exports, tax evidence, backup/restore and offboarding package
└── Shared primitives
    ├── tenant/actor/resource authorization
    ├── stable opaque IDs, typed links and event envelope
    ├── outbox/inbox, retries, replay and dead-letter controls
    ├── evidence attachments and retention/legal hold
    └── Buzz notification, thread and approval adapter (not money authority)

Current HALO coverage and gaps (read-only evidence)

This is an evidence map, not implementation authorization. repo/ was read only and no Convex seed/reset/migrate mutation was run.

Search vocabulary and coverage receipt (urgent map)

Search by the operating loop, not only “invoice” or “CRM”:

• Ledger/accounting: double-entry ledger, subledger, chart of accounts, journal

postings, liability accounting, creator royalty accounting, entertainment royalties, royalty statement, event-sourced ledger, period close, immutable correction.

• Marketplace/payout: marketplace seller payouts, creator payout, split payments,

connected accounts, escrow, reserves, payout batch, return/failed transfer, chargeback, platform settlement, three-way reconciliation, payout ledger.

• Commission/attribution: affiliate ledger, referral commission, sales attribution,

multi-touch attribution, revenue share, effective-dated commission rules, chatter incentive, partner remittance, clawback.

• Payroll/expenses: workforce payroll inputs, time-to-pay, attendance approval,

contractor payables, expense management, recurring expense accrual, tax forms, withholding, contractor statements.

• Money primitives: integer minor units, multi-currency accounting, FX snapshot,

decimal arithmetic, idempotent financial events, outbox/inbox, reconciliation queue, maker-checker approval, audit trail, export/offboarding.

• OFM/adjacent operators: OnlyFans agency finance, creator manager payout, fan

revenue operations, talent royalty accounting, music royalty portal, affiliate network reconciliation, creator marketplace escrow, subscription revenue recognition.

The completed campaign searched the local Foundry identity spine and curated corpus first, then GitHub repository search and source reads, first-party product/API/docs pages, operator signals, and the protected internal prior-art route. The receipt and evidence limits are below. Promoted GitHub repositories have direct gh api metadata; the one NOASSERTION candidate promoted for study has its actual license source inspected. Local lexical hits are candidate generators only.

Evidence notation and decision boundaries

The urgent map above is the domain design proposal. The campaign evidence below uses explicit labels:

• [FACT] directly observed in the read-only HALO clone, a protected internal file, a

GitHub API response/source file, or a first-party technical document.

• [VENDOR CLAIM] a product or marketing page's description of what the vendor says its

product does. It is useful workflow evidence, not independent proof of reliability, coverage, adult-industry acceptance, or legal suitability.

• [OPERATOR SIGNAL] an anecdote or discussion from a creator, manager, or adjacent

operator. It is a pain/edge-case signal, not a rate card or population statistic.

• [INFERENCE] a conclusion drawn from multiple sources.
• [PROPOSAL] a HALO design or sourcing recommendation.
• [OPEN] a claim that still needs direct evidence or a decision from the owner/legal

advisor.

No external source is allowed to redefine HALO's financial authority. A provider's dashboard, an agent's summary, a creator-submitted amount, or a current UI total is evidence to be validated, not a posted liability.

Money authority separation

Internal prior art and crossover

What the protected evidence actually proves

• [FACT] Oracle Streaming proof documentation records a product-cockpit one-press

multi-platform live path, real chat/tip readback into Convex, duplicate-ID protection, human presence, and a Chaturbate goal advancing from approved tip truth. The relevant bounded evidence is in apps/oracle-streaming/docs/PROVEN-LEDGER.html:44-59. The protected routes in apps/oracle-streaming/AGENTS.md and CLAUDE.md were read first; no launch, credential access, live action, or file edit was performed.

• [FACT] Oracle's event pattern is a unified operational cockpit: an external event

arrives with platform evidence, is deduplicated, is read back into application state, and may drive a visible goal or overlay only after the product recognizes it as real. This is useful evidence discipline, not proof of an OFM revenue ledger.

• [FACT] HALO already has model-facing surfaces in the read-only clone. src/App.tsx

routes creator profile, analytics, invoices, tokenized onboarding, contracts/signing, upload, AI voice, and Tasks & Rewards. The multi-step form validates a token/model type, renders four onboarding stages, and submits the tokenized record in src/components/onboarding/multi-step/MultiStepForm.tsx:26-75,129-189. Creator upload and creator-facing profile/invoice routes are also present.

• [FACT] The claim of a separate, already-built model app remains unresolved. The

route map proves existing onboarding/upload/signing-adjacent surfaces, but the read-only evidence does not identify a dedicated complete earnings/statement portal, separate repository, deployment, or production route. The honest status is therefore “existing model-facing HALO surfaces confirmed; claimed dedicated model app open,” not “the model app is missing” and not “the claim is proven.”

• [FACT] Tasks & Rewards is real prior art, not a placeholder: the page composes game

board, quests, chatter quests, supply depot/shop, player cards and manager controls. Existing research records append-only XP/bananas, shift/day scope, evidence, rerolls, purchases, ranks and leaderboards. This is relevant to truthful event-derived progress, but it is not compensation, payroll, or a creator entitlement ledger.

What can sensibly cross over

• [INFERENCE] One-action money operations. Oracle's low-cognitive-load button can

transfer to “preview and submit this approved payout batch,” “close this period,” or “resolve this exception,” provided the action is a server-validated command with a visible evidence checklist. It must not mean one click silently changes a split or marks an unknown transfer paid.

• [PROPOSAL] A shared event envelope. HALO and Oracle can converge on stable external

identity and provenance fields: source system, source account, external event ID, occurred-at, observed-at, currency, minor-unit amount, creator/account link, contract/rule version, evidence reference, schema version, dedupe key, and state. Separate adapters can emit that envelope without sharing schemas, credentials, or trust boundaries.

• [INFERENCE] Truth-grounded goals. Oracle's tip goal and HALO's XP/quest patterns

support one rule: a goal or reward may consume an approved authoritative event, never a client-supplied counter. A tip event can drive an Oracle goal; it cannot be treated as OnlyFans net sales, creator payable, agency revenue, or tax evidence.

• [PROPOSAL] Creator-visible progress. A later model surface can combine onboarding

status, content approvals, availability, custom-request state, statement periods, payout state and optional goals. It should expose only the creator's scoped records and keep chatter discussion, internal margin, credentials, and other creators' liabilities private.

• [INFERENCE] Human-readable proof is the common primitive. Oracle's proof-ledger

discipline maps well to money: every “paid,” “approved,” “goal complete,” or “ready” status needs an evidence link, actor, timestamp, and state transition. A status badge without proof must be non-authoritative.

What must not cross over

• [FACT] OBS/OME transport, streaming go-live, browser/readback details, platform

camera/microphone setup, and live-account safety gates are Oracle-specific. They are not a payout, OnlyFans messaging, or adult-platform authorization primitive.

• [FACT] Chat and tips are not OnlyFans messaging authorization, content permission,

or revenue truth. A shared event shape does not make platform policies interchangeable.

• [FACT] A shared Convex vendor does not imply shared deployment, auth, tenancy,

schema, retention, or legal trust boundary.

• [PROPOSAL] Do not put the financial journal inside Buzz, Oracle, a reward table, or

a payout provider. Link those systems through typed IDs and scoped adapters.

Ranked full-system and live-product candidates

These are ranked for the money operating loop, not brand awareness. The first three are statement/rule products; the next two are regulated payout/compliance candidates. None is allowed to replace HALO's liability journal without a separate legal, export, and reconciliation decision.

1. Melon — pilot as a creator-agency split sidecar

• Exact job/personas: Creator-agency revenue-share collection, creator-visible split

details, agency balances, invoices/cash-outs/payments, and third-party referral or service shares. Affects owner/finance, creator/model, account manager, chat/service team, and referral partner.

• [VENDOR CLAIM] Workflow evidence: Melon's product/help pages describe a split tied to

an agreement, platform earnings or cash-out detection, a creator's own bank/platform account, automatic charge/invoice, weekly agency payout, pending/completed states, carryover on insufficient funds, creator approval for percentage changes, and exportable cash-out history. See Melon product ↗, What is Melon? ↗, and Melon for creators ↗.

• Decision and authority: Pilot/buy only as a bounded rail/collection sidecar.

HALO owns the contract version, source event, canonical calculation, liability, statement, approval and reconciliation. Melon may execute an agreed collection/split flow and return evidence; it must not be the sole record.

• Stack/API/license/freshness: Proprietary hosted product; the reviewed evidence is

first-party web/help content, not source code or a public OSS license. Integration, API, adult-market acceptance, countries, bank rails, chargeback handling and data export require vendor diligence. Pages were current in the campaign's live search on 2026-08-29.

• Duplication/Buzz/confidence: High overlap with HALO creator invoices, referral

remittances, payment log and future payout batches. Buzz should carry a typed review link and exception thread, never provider credentials or an autonomous payment command. Confidence: medium for workflow fit; low until adult/country/legal/contract/export gates are verified.

2. Reprtoir — buy/study for contract and royalty statement semantics

• Exact job/personas: Multi-source royalty income/expense normalization, contract

rules, splits, advances/fees, statement periods, balances, errors/quarantine and a rights-holder portal. Affects finance, rights/contract owner, payee/creator and approvers.

• [VENDOR CLAIM] Workflow evidence: Reprtoir describes contract-associated

transactions, debit/credit operations, split/rate calculation, source-file normalization, chronological processing, quarantine/errors, period closing/locking, and detailed statements. See Royalty Accounting ↗, Royalty Accounting overview ↗, and royalty statement incomes ↗.

• Decision and authority: Study first; consider a bounded commercial pilot for

statement/rule design or an import sidecar. HALO retains creator identity, contracts, platform evidence, agency books, payables and final export. Reprtoir is not evidence that the vendor understands OnlyFans account ownership, adult consent, chat attribution, or agency departure liabilities.

• Stack/API/license/freshness: Proprietary commercial SaaS/docs; no source license

was claimed by the reviewed pages. Integration/export, API, retention, audit and pricing need diligence.

• Duplication/Buzz/confidence: High overlap with future contract-effective

allocations, statement generation, period locks and quarantine. Buzz can host finance review around a statement/version link. Confidence: high for adjacent statement patterns, low for OFM/legal fit.

3. Curve Royalty Systems — period-close and payee-statement study

• Exact job/personas: Label/publisher-style ingestion, payee/catalogue/contract

setup, sales/cost review, multi-currency calculation, statement creation, archiving, locking, balance management and payables.

• [VENDOR CLAIM] Workflow evidence: Curve's period guide describes setting up payees,

contracts, catalogue, sales and costs; loading a period; reviewing unreported sales; creating statements; then archiving/locking and exposing the result through a portal. See How to run a period and create statements ↗.

• Decision and authority: Study or buy a narrowly scoped pilot if HALO needs

proven statement-period UX. Do not install it beside HALO with overlapping creator, contract, invoice or balance authority. It is a royalty domain system, not proof of adult-industry payout eligibility or OnlyFans ingestion.

• Stack/API/license/freshness: Proprietary product/services; no OSS license or

public implementation was used as evidence. API, data export, versioning, support and offboarding require diligence.

• Duplication/Buzz/confidence: High overlap with period close, unreported source

queue, statement archive and payables. Buzz should link review evidence only. Confidence: medium-high for the period state machine, medium for adoption.

4. Tipalti — evaluate as regulated payee/tax rail after legal underwrite

• Exact job/personas: Payee onboarding, payment-method collection, tax-form/KYC

status, country-specific eligibility, mass payout execution and returned-payment handling. Affects finance/compliance, creators, referral partners, staff/contractors and the agency approver.

• [VENDOR/TECHNICAL EVIDENCE] Tipalti's payee FAQ and support material describe legal

and payment profiles, tax forms, country/payment-method requirements, “payable” versus incomplete states, KYC/document validation and reasons a payment can be returned. See Tipalti payee FAQs ↗ and the payee onboarding support route ↗.

• Decision and authority: Potential buy/integrate rail, never ledger. HALO should

generate an approved payable only after its own identity, contract, statement, sanctions/eligibility and maker-checker rules pass. Tipalti can own provider onboarding and rail statuses, while HALO stores the provider IDs, evidence and reconciliation.

• Stack/API/license/freshness: Proprietary service with first-party support/API

material; no OSS license. Provider coverage, pricing, API, webhook semantics, data residency, adult content underwriting and country support are open diligence items.

• Duplication/Buzz/confidence: Low desired duplication if kept behind a rail adapter;

high risk if its payee/profile becomes a shadow creator identity. Buzz can notify finance of blocked KYC or returned payments. Confidence: medium for the eligibility workflow, zero assumption that it accepts an adult OFM use case.

5. Trolley — API-first payout/tax alternative

• Exact job/personas: Recipient onboarding, payout methods, tax forms/reporting,

country-specific requirements, recipient status and payout API execution. Affects finance, creators, referral partners, contractors and approvers.

• [VENDOR/TECHNICAL EVIDENCE] Trolley's developer documentation exposes recipient

onboarding/activation requirements, payout APIs, tax/KYC/AML/DSA/INFORM-related material, country payment requirements and royalty-like recipient categories. The relevant starting points are Trolley developers ↗, Trolley API ↗, and global payout network ↗.

• Decision and authority: **Evaluate as a second rail option after country,

adult-industry, tax and merchant-of-record review.** HALO owns the payable, batch, provider mapping and reconciliation. Trolley's “recipient active” or “payout submitted” state is not a creator entitlement or a settled bank result.

• Stack/API/license/freshness: Proprietary hosted API/docs; no OSS license. Public

coverage numbers and performance statements are vendor claims. API idempotency, webhooks, retries, returns, chargebacks, data export and adult underwriting remain open.

• Duplication/Buzz/confidence: Adapter boundary can be clean; identity/payee

duplication is dangerous. Buzz can route an eligibility exception or payout return. Confidence: medium for API/eligibility shape, low for OFM fit until contractually verified.

6. Stripe Connect — reject as default adult-market rail; retain failure patterns

• Exact job/personas: Connected-account payment/transfer orchestration and dispute

handling for ordinary platforms, not an OFM-specific statement system.

• [FACT] Policy and technical evidence: Stripe's current restricted-business

material says it cannot work with adult content/services in the relevant restricted categories; legality alone does not guarantee support. Its Connect docs also show that separate charges/transfers can fail or require reversal and that disputes can debit or reverse platform-side transfers. See Stripe restricted businesses ↗, separate charges and transfers ↗, and Connect disputes ↗.

• Decision and authority: Reject as the default OFM payout recommendation. Use

only if Stripe gives explicit written approval for the exact lawful business model, countries, products, account structure and merchant-of-record responsibilities. Keep its transfer/dispute state machine as an adjacent failure-model reference.

• Stack/API/license/freshness: Proprietary API/service; no OSS license. The technical

mechanics are well documented, but the adult-policy gate supersedes generic Connect capability.

• Duplication/Buzz/confidence: It would duplicate a rail adapter only; never the

ledger. Buzz can carry a blocked-provider decision. Confidence: high on the need for the policy gate; no recommendation to use it for OFM money movement.

7. Paxum/Cosmo Payment — evaluate only as adult-market rail hypotheses

• Exact job/personas: Adult/cam creator withdrawal and intermediate wallet/card/bank

movement, potentially useful for creators or agency-owned payout routes.

• [VENDOR CLAIM] Paxum's business account/FAQ ↗

describes verified business accounts, receipt of platform payments and API/web operation; Cosmo Payment ↗ describes mass/instant payout and card/bank options in supported jurisdictions.

• [OPERATOR SIGNAL] Cam/capture community discussions report that provider timing,

intermediary fees, exchange rates, bank acceptance and country/account changes can vary. Examples include Stripchat payment delay ↗, safe payout and bank concerns ↗, and Canadian payout options ↗. These are anecdotes, not guarantees.

• Decision and authority: **Evaluate only after written provider, country, tax,

account-ownership, adult-policy and merchant-of-record review.** Never treat an adult-friendly anecdote as eligibility proof and never make the wallet the ledger.

• Stack/API/license/freshness: Proprietary services; no OSS license. API, settlement,

chargeback, reserve, account freeze and export terms are open.

• Duplication/Buzz/confidence: Keep behind a provider adapter; Buzz can route an

unknown/returned payout. Confidence: low-medium as a lead only.

Ranked verified GitHub candidates

The local corpus generated candidates; this ranking is based on direct source inspection and the GitHub API receipt below. A repository is a study donor or isolated experiment, not permission to re-platform HALO. License status is an adoption constraint, not a footnote.

1. pgr0ss/pgledger — simplest focused double-entry donor

• Exact job/personas: Account-based double-entry journal for finance and engineering;

useful to HALO's ledger implementer, finance approver and reconciliation worker.

• [FACT] Source evidence: The README describes PostgreSQL tables/functions/views,

balanced transfers, per-account currency, an event_at distinct from created_at, and transactional append/query behavior. The event_at distinction is especially relevant to late webhook arrival and reconciliation.

• Decision and boundary: **Study first; consider a bounded PostgreSQL ledger

experiment.** HALO's tenant/auth/contract/statement/payout policies remain the domain layer. It is not a drop-in Convex/TypeScript replacement and does not provide OFM attribution, tax, KYC, or provider rails.

• Stack/API/license/freshness: PostgreSQL SQL/functions with examples and Go-related

material; MIT. Direct API metadata and README/tree were checked on 2026-08-29.

• Duplication/Buzz/confidence: Potentially duplicates a future journal store; use one

source of truth only. Buzz links a journal/exception review, never writes SQL. Confidence: high for the focused data model; medium for integrating with HALO.

2. formancehq/ledger — programmable postings and account model

• Exact job/personas: A financial core for engineers building balances, postings,

multi-denomination flows, payments and payouts; useful to HALO finance/platform architects.

• [FACT] Source evidence: The README describes atomic multi-posting transactions,

account-based modeling, a Numscript transaction DSL, PostgreSQL, standalone service operation, a Console UI, and a log shipper for analytics.

• Decision and boundary: **Study; run a synthetic integration spike only if the

service boundary is justified.** It can inform canonical postings and external read models, but HALO still owns creator identity, effective contracts, attribution, statements, legal gates and provider reconciliation.

• Stack/API/license/freshness: Go service, PostgreSQL, HTTP API/Numscript and Docker

deployment; MIT; direct README, tree, metadata and license metadata checked on 2026-08-29. Production use is described as supported through its Kubernetes operator, which adds operational weight.

• Duplication/Buzz/confidence: High overlap with a new ledger service and deployment.

Buzz can be an approval/evidence surface. Confidence: high for ledger capability, medium for HALO fit due integration/operations cost.

3. tigerbeetle/tigerbeetle — safety-critical transaction primitive

• Exact job/personas: Durable debit/credit account and transfer primitive for

engineers who need strong financial transaction invariants; useful for the ledger reliability review.

• [FACT] Source evidence: The README describes accounts, debit/credit transfers,

pending/posting states and a financial-transactions database designed for mission critical safety and performance.

• Decision and boundary: **Study primitives; do not adopt as the complete OFM money

system.** It does not supply contract allocation, attribution, statements, tax/KYC, provider eligibility, creator UX or reconciliation policy.

• Stack/API/license/freshness: Zig database/service with client APIs; Apache-2.0;

direct API metadata and README/tree were checked on 2026-08-29.

• Duplication/Buzz/confidence: A second transaction engine beside Convex could

create split truth. Use only behind an explicit ledger authority decision. Confidence: high for primitive reliability claims as repository evidence, medium for adoption.

4. flash-oss/medici — approachable Node/Mongoose accounting pattern

• Exact job/personas: Node application developers modeling books, account hierarchies,

journals, balances, metadata and voids; useful to a HALO TypeScript implementer.

• [FACT] Source evidence: The README describes double-entry books, child transactions,

balancing to zero, account hierarchies, metadata queries, and voiding by adding an equal/opposite entry. It also calls out JavaScript numeric-precision limitations.

• Decision and boundary: **Study only; possibly use isolated test fixtures, not the

live authority.** Its accounting vocabulary helps design reversal/void semantics, but HALO must use integer minor units/decimal-safe calculations and add contracts, attribution, holds, statements, payables, tax and reconciliation.

• Stack/API/license/freshness: Node.js, Mongoose/MongoDB package; MIT; direct API

metadata, README and repository tree were checked on 2026-08-29.

• Duplication/Buzz/confidence: Would duplicate a ledger if embedded casually. Buzz

links review context only. Confidence: high for pattern, low-medium for production adoption.

5. juspay/hyperswitch — payments and reconciliation sidecar, not ledger

• Exact job/personas: PSP connector/orchestration, payment routing and reconciliation

for platform/finance engineers; useful if HALO eventually needs a provider abstraction.

• [FACT] Source evidence: The README describes a Rust composable payments platform,

multiple connectors, a Control Center and reconciliation with two-way/three-way, backdated, scheduled and customizable flows.

• Decision and boundary: **Integrate only as a bounded rail/reconciliation sidecar

after adult-policy and provider approval.** It cannot own creator entitlement, contract split, agency revenue, referral liability, statement or legal eligibility.

• Stack/API/license/freshness: Rust, API/service and connector ecosystem; Apache-2.0;

direct API metadata and README were checked on 2026-08-29.

• Duplication/Buzz/confidence: Its reconciliation layer can overlap a HALO adapter;

choose one provider status authority and always copy evidence into HALO. Buzz routes exceptions. Confidence: high for general payments capability, low for adult-market suitability.

6. spatie/laravel-event-sourcing — audit/event pattern donor

• Exact job/personas: Event-sourced aggregates, projectors and reactors for developers

needing past-dependent decisions, auditability and future reporting.

• [FACT] Source evidence: The README explicitly describes aggregates, projectors,

reactors, audit requirements, event replay and examples with account deposits/withdrawals.

• Decision and boundary: Study pattern, not a money system. The useful ideas are

append-only events, projections, replay and derived read models. HALO still needs balanced postings, immutable monetary corrections, contract versions, statement locking and payout reconciliation.

• Stack/API/license/freshness: PHP/Laravel package; MIT; direct API metadata, README

and tree were checked on 2026-08-29.

• Duplication/Buzz/confidence: Event sourcing can complement a journal but can also

create an unbounded second log. Buzz can display projector evidence. Confidence: high for audit/replay pattern, low for direct adoption.

7. LerianStudio/midaz — rich source-available ledger, legal gate

• Exact job/personas: Multi-tenant, multi-asset, double-entry core banking ledger with

accounts, portfolios, balances, fees, immutable transactions and a tracer/risk service. Useful to an architecture reviewer comparing ledger hierarchy and reservation states.

• [FACT] Source evidence: The README describes a Go monorepo, PostgreSQL/MongoDB,

RabbitMQ/Valkey infrastructure, multi-asset transactions, n:n postings, holds, optimistic concurrency, audit chaining and OpenAPI.

• Decision and boundary: **Study only until legal review; do not treat as ordinary

OSS.** It is much broader than HALO and would introduce a separate Go/infra/control plane. No source reuse or hosted service assumption follows from the repository.

• Stack/API/license/freshness: Go, PostgreSQL, MongoDB, RabbitMQ, Valkey, REST/gRPC;

GitHub metadata returned NOASSERTION. Direct license source inspection found Elastic License 2.0, including a restriction on providing it as a hosted/managed service and other license-key/notices conditions. This is source-available, not an unqualified MIT/Apache donor.

• Duplication/Buzz/confidence: Very high overlap with a canonical ledger service.

Buzz could surface risk/approval context only. Confidence: high for the license gate and README-visible shape, low for HALO adoption.

8. frappe/erpnext plus frappe/hrms — complete back-office reference, not a sidecar

• Exact job/personas: ERP accounting, invoices/orders/projects/assets plus HR,

attendance, payroll, taxation and employee lifecycle for finance/admin/HR.

• [FACT] Source evidence: ERPNext's README presents accounting, order management,

projects, assets, HR/payroll and self-host/managed paths. Frappe HR's README presents employee lifecycle, attendance, expense claims, performance, payroll and taxation.

• Decision and boundary: **Study or consider a deliberately bounded re-platform

decision; reject casual co-installation.** It cannot sit beside HALO while both systems own creators, contracts, invoices or staff pay. It also lacks the OFM-specific creator/platform identity, attribution, consent and departure semantics.

• Stack/API/license/freshness: Python/JavaScript Frappe applications with MariaDB/

Docker/self-host paths; both repositories report GPL-3.0; direct API metadata and README sources were checked on 2026-08-29.

• Duplication/Buzz/confidence: Extremely high overlap with back office, payroll and

accounting. Buzz remains the fixed collaboration plane. Confidence: high for breadth, low-medium for a HALO migration.

Patterns worth rebuilding in HALO

These are implementation-neutral patterns extracted from the candidates, not permission to copy a repository:

1. Source-first ingestion: raw statement/report archive, hash, source account, external

transaction ID, provider cursor and late-arrival state.

1. Effective-dated calculation: contract/rate-card version selected by event time,

with a human-readable explanation of every creator, referral, staff and agency line.

1. Balanced journal plus subledgers: every payable is a posting, not a mutable total;

creator/referral/staff balances roll up to the agency clearing and revenue accounts.

1. Pending versus posted versus settled: holds, refund windows and rail status must

not be collapsed into one paid boolean.

1. Quarantine and replay: bad identity, missing term, duplicate, FX mismatch,

provider return or partial batch becomes a resolvable object with a retry/replay path.

1. Period lock: close produces a versioned statement snapshot; corrections reverse or

adjust rather than silently rewrite.

1. Maker-checker payout: preparer, approver, threshold, evidence, idempotency key,

provider ID, unknown state and reconciliation result are explicit.

1. Creator-readable proof: a creator can see source-period, split basis, fees,

deductions, payments, carryover, dispute window and export without seeing internal margin or other identities.

1. Exit package: creator departure or account suspension preserves contract history,

open liabilities, source exports, payout evidence, disputes and revocation state.

1. One coordination link: Buzz threads, agents and approvals link to these typed

records; they do not copy balances or become a hidden workflow database.

Legal and product gates — not feature claims

These gates are product/legal decisions, not features to infer from a demo, README, or vendor logo. This report is not legal or tax advice.

Recommended HALO + Buzz composition

HALO owns

• A raw source-document/event boundary for platform reports, imports, provider statements

and bank/rail results.

• A canonical integer-minor-unit, currency-aware, append-only journal with explicit

accounts, postings, liabilities, clearing, holds, reversals, disputes, period locks and idempotency.

• Versioned creator/referral/staff rules selected by effective event time, with calculation

explanations and missing-term quarantine.

• Statement/payable views for creators, referrals and staff derived from the journal,

including prior payments, carryover, dispute window, evidence and export.

• Server-side actor/tenant/resource authorization, maker-checker payout approval, provider

adapter state, reconciliation queues and immutable audit.

• The model-facing money surface when the existing HALO model app is identified: only

scoped statements, payout status, dispute/export and contract basis, not internal margin, other creators, credentials or staff discussion.

Buzz owns and links

• Finance review rooms, payout-batch approval context, exception threads, handoffs,

notifications, agent summaries and decision receipts.

• Stable typed links to creator, source event, rule version, statement, payable, payout

batch, rail transfer and reconciliation exception.

• Agent read/recommend operations with server-side HALO commands for any consequential

mutation. An agent may draft or route; it may not approve its own payout.

Specialist sidecars may own

• Provider onboarding, tax-form collection, KYC/AML checks and actual rail execution,

subject to legal/product approval and export/reconciliation.

• Optional contract-signing, royalty-statement, or payment-reconciliation capability

when its boundaries are explicit and HALO remains authoritative.

Never create a split-brain pair

• Do not run Melon/Reprtoir/Curve/ERPNext/another ledger beside HALO with overlapping

creator balances and no declared system of record.

• Do not copy a provider's balance into a mutable invoice and call that reconciliation.
• Do not let Buzz, Oracle, Tasks & Rewards, an AI agent, or a payout service silently

allocate, settle, or rewrite compensation.

Build/buy/integrate/study/reject ledger

Phased proof plan — synthetic data first

No Convex mutation, payout, live provider action, credential access, deployment, or production data write is authorized by this plan.

Phase 0 — read-only characterization

• Freeze a source map of the current invoice, referral, payment-log, payroll and currency

paths in repo/; retain the current route/model-app evidence and unresolved claim.

• Create no records. Document current 50% fallback, float-number fields, mutable invoice

payment arrays, derived payment-log rows, weekly hand-entered sales, and absent provider adapters.

• Define one synthetic tenant with fictional creators, platform accounts, contracts,

chatters, referral partners, provider accounts and bank accounts.

Phase 1 — journal invariants

• Fixtures: one sale, duplicate replay, late arrival, out-of-order event, unknown creator,

missing contract, fee mismatch, refund, chargeback, FX conversion, partial payment, returned payment, unknown timeout and creator departure with open liability.

• Assertions: every posted transaction balances; no negative/ambiguous minor-unit

representation; external dedupe key is stable; raw source is immutable; reversals link to originals; provider “unknown” never becomes “paid.”

• Property tests: replaying any import twice produces one source event and one allocation;

correcting a rule creates a new adjustment rather than changing closed history.

Phase 2 — allocation, statements and close

• Golden vectors for creator split, agency share, referral commission, chatter incentive,

fees, deductions, refunds, chargebacks, FX snapshots and rounding.

• Effective-date fixtures: contract starts mid-period, changes percentage, expires, is

disputed, or is missing. Missing terms must block settlement.

• Generate creator/referral/staff statements from the same journal; lock a period, export

it, then apply a reversal in a later period. Verify opening/closing balances and carryover.

Phase 3 — provider sandbox contract

• Only after legal/product approval, use a provider sandbox or a non-production test

account. Test recipient incomplete/eligible/blocked, idempotent submission, duplicate webhook, timeout/unknown, return, partial, fee, chargeback/dispute and reconciliation.

• Validate data export, webhook signatures, retention, country/method matrix, adult

policy, tax/KYC evidence, merchant-of-record role and support escalation.

• Keep the provider adapter behind HALO's approved payout-batch command. No provider

login or credential is placed in Buzz or a client browser.

Phase 4 — shadow imports

• Import historical/synthetic platform and provider files read-only. Compare canonical

statements against current HALO invoice/referral totals without marking or sending a payout.

• Finance reviews every difference: source missing, term mismatch, rounding/FX, receipt,

departure liability, or current-UI error. Record the reason and expected correction.

Phase 5 — limited approved operation

• Only after Phase 0-4 pass and counsel/provider gates are signed, run a limited

non-production or explicitly approved cohort with maker-checker approval, immutable batch IDs, provider evidence and post-settlement reconciliation.

• Roll back by reversing/adjusting entries and stopping the adapter, never by deleting

posted money history. Export the complete evidence package before widening scope.

Campaign search and coverage receipt

Local corpus first

• [FACT] The RepoCard identity spine at

/Users/shaansisodia/SISO_Workspace/SISO_Agent_Base/research/repo-catalog/identity/identity.sqlite contains 1,358,200 repo cards in the local snapshot. The curated corpus at /Users/shaansisodia/SISO_Workspace/SISO_Research/siso-foundry/pipelines/github/awesome/catalog_full.sqlite contains 307,180 repo rows and 303,887 FTS rows.

• Query families covered double-entry/accounting/ledger, payment/payout/reconciliation,

royalty/commission/affiliate, creator/marketplace, payroll/HR/expense, FX/multi-currency, event sourcing, money primitives, and adjacent ERP/statement systems.

• Strong local candidates were pgr0ss/pgledger, flash-oss/medici, formancehq/ledger,

tigerbeetle/tigerbeetle, juspay/hyperswitch, spatie/laravel-event-sourcing, frappe/erpnext, frappe/hrms, firefly-iii/firefly-iii, beancount/beancount and LerianStudio/midaz. Curated FTS was especially noisy for creator/marketplace terms; this is why direct source and license checks outrank star counts.

GitHub search and source pass

• [FACT] Search families run included double entry ledger, creator royalty

accounting, marketplace payout ledger, commission payroll reconciliation, royalty management software, creator payouts, affiliate payouts, payment reconciliation, multi currency ledger, and payroll open source.

• Exact OFM/creator-royalty queries were sparse or dominated by small prototypes,

assignments and no-license repositories. Mature adjacent ledger and reconciliation sources were more informative than the literal OFM vocabulary.

• The cross-lane screened web-live shortlist was treated as candidate input only. This

lane independently demoted broad system shells such as Open Mercato ↗, erxes ↗, and Huly platform ↗ for money authority: they may help with multi-tenant/entity/team surfaces, but the money-specific journal, attribution, liability and payout proof were not established here. Their metadata and relevant license/source routes were independently checked before this note.

• [LIMITATION] The Perplexity/websearch route was unavailable because its

OPENROUTER_API_KEY was not configured. Built-in live web search, direct first-party pages/docs and direct GitHub API/source inspection were used instead. No vendor metric was promoted as independently verified.

Live product and first-party documentation pass

• Creator-agency split/payout: Melon.
• Royalty contract/statement/period close: Reprtoir and Curve.
• Payee onboarding/tax/KYC/country/payment methods: Tipalti and Trolley.
• Platform transfer/dispute failure and adult-policy boundary: Stripe.
• Adult/cam payout hypotheses: Paxum and Cosmo, with operator corroboration treated as

anecdotal only.

Operator/community pass

• [OPERATOR SIGNAL] Creator discussions repeatedly center contract existence,

percentage transparency, account control, what the agency actually does, fair division of platform fees/taxes, and safe exit. See Leaving My Agency ↗, another agency exit discussion ↗, and shared content cost division ↗.

• [OPERATOR SIGNAL] Cam/capture discussions describe payout delays, provider changes,

country/bank constraints, intermediary fees, and conflicting “instant” expectations. These support first-class unknown/returned/eligibility states, not a provider recommendation.

• [INFERENCE] The money product's strongest trust feature is not a faster “paid”

button; it is a creator-readable explanation that survives a platform outage, staff turnover, disputed split, provider return, and departure.

What are we still missing?

The first-principles outcome

The money department exists to answer, for every dollar: where did it originate, whose contract says what, what is held or disputed, who is owed, what has actually moved, what evidence proves it, and what survives a correction or exit. Today’s screen names—invoice, payment log, payroll, referral remittance—are only views into parts of that outcome.

Invisible work before and between screens

• A finance operator receives a platform export or bank notification, determines whether

it is gross, net, cash-out or settlement, maps a platform account to a creator, and preserves the raw evidence before editing a spreadsheet.

• A manager or chatter explains attribution, content/custom source, referral or incentive

context. The explanation needs actor, time, source and confidence, not just a changed percentage.

• Finance chooses the contract version, platform fee basis, hold window, FX rate/source,

tax treatment, rounding policy and statement period. These decisions are not visible in a simple invoice total.

• A payout operator handles missing bank details, KYC/tax blocks, partial funds,

returned/unknown transfers, duplicate provider callbacks, chargebacks and creator questions. A successful API response is not necessarily settled money.

• At close, someone matches platform settlement, journal, provider/bank statement,

outstanding payables, receipts, refunds and departures. The current payment log cannot prove that three-way match.

Handoffs and failures that still lose information

• Platform account identity can diverge from creator identity; a creator may have multiple

platforms, a changed handle, a suspended account, or a bank-only deposit.

• A contract may start mid-period, change after a dispute, expire, or be absent. The

current 50% fallback turns missing business truth into a payable.

• A sale can arrive late or twice; a refund/chargeback can occur after payout; an FX rate

can change; a provider can time out; and a creator can leave while money remains held.

• Staff turnover can erase why a split, write-off, manual payment or attribution decision

was made unless evidence and actor are durable.

• A provider may know KYC/tax status but not HALO's contract, statement or liability;

HALO may know the liability but not whether the rail settled. These are intentionally separate state machines.

Adjacent markets answer only part of the problem

• [INFERENCE from Reprtoir/Curve] Royalty systems show the value of contract-linked

calculation, source normalization, quarantine, period close/lock and payee statements. They do not prove adult platform ingestion, creator consent, or payout eligibility.

• [INFERENCE from Stripe] Payment rails demonstrate transfer/dispute/reserve failure

semantics and platform liability boundaries. Their generic connected-account feature does not solve the adult-policy gate or the agency's ledger.

• [INFERENCE from Tipalti/Trolley] Specialist payee systems show that tax/KYC/country/

method eligibility must be an explicit state machine. They do not replace jurisdictional advice, merchant-of-record decisions, or HALO source evidence.

• [OPERATOR SIGNAL] Creator discussions expose trust damage from opaque percentages,

unsigned terms, account-control fear, fee/tax confusion and delayed payouts. A creator portal must therefore expose contract basis, statement evidence, dispute/export and exit state, not only an amount.

Trust boundaries and surfaces still absent or unproven

• [OPEN] The actual claimed dedicated model-facing app, route, repository or

deployment. Existing HALO onboarding/upload/profile/invoice surfaces are real evidence, but the complete model earnings/statement experience is not yet characterized.

• [OPEN] A server-authoritative money authorization boundary. The inspected money

functions contain no ctx.auth guard in the relevant paths; role-shaped UI does not substitute for tenant/actor/resource authorization.

• [OPEN] A canonical platform sale/event source and account-identity map. The current

salesTracker is a weekly hand-entered grid, not a source-event ledger.

• [OPEN] Rule versioning and explainability across creator splits, referrals, chatter

incentives, fees, holds, refunds, chargebacks and FX.

• [OPEN] A statement/payable object that is derived from an immutable journal and

supports period lock, dispute, partial payments, carryover and later adjustment.

• [OPEN] A provider matrix for the actual countries, adult-business policies, payee

identities, tax forms, KYC/AML status, merchant-of-record role, reserves, returns and exports that HALO needs.

• [OPEN] A departure/suspension export that gives the creator and agency enough

evidence to settle open liabilities without exposing unrelated people or credentials.

What HALO should never build

• [PROPOSAL] Do not build a home-grown bank, PSP, KYC/AML decision engine, tax-law

engine, custody/escrow promise, merchant-of-record operation, or adult-provider allowlist from UI assumptions. Buy regulated capability where appropriate and keep policy/evidence/eligibility adapters in HALO.

• [PROPOSAL] Do not rebuild generic chat, streaming transport, or a second agent

collaboration product. Buzz is fixed; Oracle remains protected prior art.

• [PROPOSAL] Do not make gamification, AI output, or a provider balance equivalent to

compensation truth.

What would make it 10× better

• One synthetic-to-production-safe source event vocabulary and replayable ledger rather

than five manually edited totals.

• One calculation explanation visible to finance and creator, with contracts/effective

dates and no silent 50/50.

• One exception queue that treats unknown identity, term, FX, payout and reconciliation

states as work objects with owners, deadlines, evidence and escalation.

• One approval/batch flow that makes “submitted,” “unknown,” “returned,” “settled,” and

“reconciled” impossible to confuse.

• One export/offboarding package that can survive a provider shutdown, creator departure,

staff turnover or platform suspension.

• One Buzz-linked proof thread that lets humans review decisions quickly without granting

an agent or chat participant financial authority.

Negative findings and open questions

Negative findings

• No read-only evidence found of a verified HALO platform-sales ingestion table or

provider transfer adapter in the inspected money paths.

• No current evidence supports treating the invoice model, merged payment log, referral

remittance or payroll grid as double-entry truth.

• No candidate was found that safely combines OFM creator identity/consent, platform

attribution, contract-effective splits, double-entry liabilities, tax/KYC eligibility, adult-compliant payout rails, statements and departure export in one verified system.

• Literal “creator payout,” “affiliate payout” and “royalty” GitHub searches were largely

low-signal; popularity is not evidence of money state-machine fit.

• Stripe cannot be recommended for OFM money movement from generic Connect capability.
• Midaz cannot be classified as plain OSS from its GitHub NOASSERTION metadata; its

actual Elastic License 2.0 is a material hosted-service/legal gate.

• Buzz is a collaboration/agent substrate, not a money ledger. Oracle tip/event/goal

evidence is useful for provenance and truth-grounded UX, not OFM revenue truth.

Open questions for owner/legal/provider diligence

• What exact model-facing app was built: HALO route, separate repo, deployed product,

prototype, or claim? Which personas can view, approve, dispute, export and revoke?

• Is HALO principal, agent, service provider, merchant of record, or merely an

accounting/coordination layer for each platform and country?

• Which platform exports/APIs are lawfully available, at what cadence, with what account

ownership and terms? What is the source of gross versus net and cash-out versus earned?

• Which countries and adult-industry payout routes are in scope first? Which providers

will give written underwriting, tax/KYC responsibilities, support SLAs, reserves and export guarantees?

• Is the canonical ledger staying in Convex, moving to a dedicated PostgreSQL service, or

using one explicitly selected bounded ledger engine? Who owns migrations and audit?

• What are the exact contract rules for creator, referral, chatter and staff liabilities,

including hold windows, refunds, chargebacks, expenses, taxes and departure?

• What maker-checker thresholds and evidence retention are required, and which roles may

approve a write-off, release a hold, or retry an unknown transfer?

• Which model-facing statement fields are creator-visible, and how are disputes,

corrections, account suspension and offboarding exported?

GitHub verification and license ledger

The following rows were freshly verified with gh api repos/OWNER/NAME during this campaign. Stars and pushed_at are point-in-time metadata, not quality scores. Every named repository in the money ranking or cross-lane rerank has a row. For NOASSERTION, the actual license source was inspected rather than treating the API label as a license conclusion.

NOASSERTION source inspections

• LerianStudio/midaz: gh api repos/LerianStudio/midaz/license returned a source file

headed Elastic License 2.0. The text grants a non-exclusive license but prohibits providing the software to third parties as a hosted/managed service offering a substantial set of its features, and includes license-key, notice, patent and termination conditions. Classify it as source-available/Elastic, not generic OSS.

• erxes/erxes: gh api repos/erxes/erxes/license returned a mixed license source:

content outside the ee directory is AGPLv3, enterprise plugins have a separate license, and the file says erxes may not be hosted as a SaaS competing with erxes Inc. It is a legal review gate, not a drop-in commercial SaaS base.

For the SPDX-labelled rows, the GitHub API metadata was recorded and the repository README/tree was read for the promoted claims. License names are still subject to the repository's notices and any commercial/enterprise components; no code was copied, modified, launched or deployed from these repositories.