PRODUCTION FOUNDATION · MAKER PAYOUT ACCOUNTING

The money ledger and the payout clock are two different things.

v0.12.24 adds payout-destination change security on top of the verification, immutable ledger and transfer queue foundations. A destination change now forces reverification, a 24-hour cooling-off period, risk review and invalidation of safe-to-cancel prepared transfers before the new destination can activate.

TEST NOWApply migration 0022; run the ledger, verification, transfer and destination-security self-tests; then use a QA Maker to prove a destination change invalidates prepared transfers, forces reverification, cannot skip cooldown/risk review, and only activates after every gate passes.

PRODUCTION LATERReal KYC/KYB/tax provider onboarding, authenticated verification events, real payout accounts, provider transfer API/webhooks, provider-authenticated destination-change requests/review, retry policy, negative balances/reserves, finance-admin MFA, reconciliation and tax statements remain gated.

SERVER LEDGER + SCHEDULER

Can Clara calculate proceeds without letting timing rewrite money?

The disposable self-test proves 5% fee math, New/Established/Trusted timing anchors, frozen historical policy, hold priority, explicit refund allocation, immutable ledger evidence and provider-release guarding.

VISIBLE QA MAKER

Inspect a real server-backed Maker balance

Start a QA Maker session first. Changing the QA tier affects future payout schedules only; it intentionally does not rewrite an existing order’s frozen policy.

QA trust tier for future fixture orders

Open Maker Finances →

MAKER PAYOUT ONBOARDING · VERIFICATION READINESS

Can Clara block money until the Maker is actually payout-ready?

This layer stores verification state, requirement codes and provider references only. It intentionally has no field or action for raw SSNs, tax IDs, bank routing/account numbers or identity-document images.

Start a QA Maker session and load verification state.

PAYOUT EXECUTION QUEUE · STAGING ONLY

Can Clara prepare exactly one provider transfer without letting stale money escape?

Use an authenticated QA Maker with at least one Available payout schedule. The QA destination contains no real banking data; it exists only to prove destination readiness, transfer freezing, idempotency, retry and provider-paid evidence.

Load execution state to inspect prepared transfers.

PAYOUT DESTINATION SECURITY · v0.12.24

Can a payout destination change survive account-takeover pressure?

The current destination cannot be swapped directly. A change request freezes the proposed destination identity, invalidates prepared transfers that have not reached the provider, forces payout reverification, enforces a 24-hour cooling-off period, requires risk review, and blocks activation while a provider-submitted transfer is in flight.

Load destination security state after setting the initial QA destination ready.

TEST NOW

Payout foundation checks

Record only what you actually prove on clarawidetest.

PRODUCTION LATER

Real-money + finance operations gates

Green QA proves accounting/scheduling behavior, not that ClaraWide can move money.

ISSUE LOG

Record payout defects

OPEN FINDINGS

Payout blockers

RECENT SERVER RUNS

EVIDENCE BACKUP

Export or reset this QA layer

Payout boundaryPassing v0.12.24 proves server-owned payout-verification readiness, safe data minimization, immutable Maker-order accounting, graduated timing, exact transfer preparation, destination snapshots, pre-submission reconciliation, and a non-bypassable destination-change security/cooling-off workflow before activation. It does not prove real KYC/KYB/tax provider connectivity, bank settlement, regulatory review, tax reporting, negative-balance recovery or production finance authorization.