Settle LPs, validators, and users exactly—across chain and fiat.
Cross‑domain mismatches (off‑chain books vs on‑chain payouts) and micro‑fee drift shouldn’t exist. We release only the proven set—bound to on‑chain headers/receipts and fresh approvals—so replays match bit‑for‑bit.
Who this is for
CEX / hybrid exchanges & Web3 platforms
Splitting trading fees, staking yields, or rebates with LPs, validators, and users across on‑chain and fiat rails.
Where pain shows up
Off‑chain vs on‑chain mismatches, re‑runs that change cents/wei, micro‑fee rounding drift, finality not tied to payouts, heavy audit lift.
Outcome we target
Wei/penny‑exact, cross‑domain‑verified disbursements; replayable transcripts; approvals fresh/in‑quorum; clean audits.
What you get (in plain English)
No micro‑fee drift
Integer math + late quantization + deterministic carry—sub‑cents/wei assigned once per window.
Cross‑domain proof
Bind payouts to on‑chain headers/receipts (SPV) and sealed transcripts; auditors can replay and verify.
Safer policy changes
Canary + digest equality across versions; promotion only on equality; rollback bounded to a window.
Before → After (at a glance)
Traditional stack & flow (before)
- Off‑chain: matching engine + warehouse fees (Snowflake/BigQuery/Spark) with FP math & per‑trade rounding
- Payout rails: on‑chain programs/custody wallets and/or ACH/SEPA/PSPs
- Back office: subledger/ERP + spreadsheets, monthly close tools
Re‑runs shift cents/wei; finality not tied to payout; no replay‑proof that “this batch exactly equals those inputs.” Audits are heavy.
Overlay architecture (after)
- Deterministic engine: single‑writer logs/partitions; fixed fold order; i128 accumulation.
- Late quantization + carry‑ledger: round once at finalization; ≤½‑ULP bound; assignments recorded.
- Transcript + output_digest: content‑addressed, replayable evidence; require digest equality.
- Acceptance gate: Finance ACK + CT (KYC/OFAC/Tax) + optional SPV headers/receipts; freshness & quorum.
- Cross‑domain adapter: verify on‑chain block header / custody receipt inside the same audited pipeline.
How it works (60 seconds)
1) Ingest & compute
Normalize maker/taker fees, rebates, staking rewards into ordered logs with idempotency; compute deterministically in integers.
2) Window close
Advance a monotone watermark; fold in a fixed order; late quantize; assign carry deterministically; seal transcript & digest.
3) Authorize & disburse
Require replay equality + acceptance success (ACK/CT and optional SPV). Release only the ALLOW set; HOLDs reason‑coded.
Keep your rails—no rip‑and‑replace.
Hourly cadence (example)
- T+0–55m: Ingest & compute deterministically
- T+55m: Window close (watermark, fold, quantize, carry)
- T+56m: Authorize(window_id) — equality + acceptance
- T+57m: Disburse ALLOW (on‑chain or ACH/PSP); HOLDs reason‑coded
- Next window: Late trades/chargebacks land here
Acceptance policy (example)
Required proofs
- ACK (Finance reserves) — window‑level
- CT (KYC/OFAC/Tax) — principal/cohort‑level
- SPV (optional) — on‑chain block header/Merkle proof or custody/bank receipt headers
Freshness & quorum
- Freshness: ACK ≤ 60m; CT ≤ 24h; SPV ≤ 60m
- Quorum: 2 of 3 (Finance, Compliance, Ops)
If unmet
- HOLD with reason:
STALE_PROOF,INSUFFICIENT_QUORUM,INVALID_SIGNATURE - Owners alerted; re‑check without mutating outputs
Fits your stack
Keep what works
Keep your on‑chain programs/custody wallets and/or ACH/SEPA rails, plus your ERP/subledger. We add a pre‑release gate.
Add three fields
window_id— identifies the payout windowoutput_digest— ties to the sealed transcript (replay equality)provider_batch_id— tx batch hash / custody receipt / PSP batch reference
One pre‑release call
Right before you post transfers or create the ACH/PSP batch:
POST /authorize { window_id }
→ ALLOW roster + HOLD roster with reason codesPath A — On‑chain (programmatic)
- Execute on‑chain batch for ALLOW set
- Record
provider_batch_id(tx batch hash) - POST
/proofswith SPV headers/headers_hash to close the loop
Path B — Off‑chain (ACH/PSP)
- Create PSP/ACH file from ALLOW set
- Include
window_idin memo; capture batch ref asprovider_batch_id - Optional: SPV receipt from custody/bank after execution
Data intake options: S3/GCS/SFTP, read‑only DB view, Kafka/Webhook — adapters provided.
Where these fields go
- On‑chain/PSP batch metadata:
window_id,output_digest,provider_batch_id - GL/subledger custom fields:
custbody_payout_window_id,custbody_output_digest,custbody_provider_batch_id,custbody_transcript_url
Technical details (for software engineers)
View endpoints, SPV, data contracts & mappings
API surface
Gate release and fetch evidence:
// Verifies replay digest equality + acceptance matrix (freshness & quorum) → Returns: ALLOW roster + HOLD roster with reason codes
// Push CT/ACK/SPV payloads; we verify signatures & freshness and update decisions
// Sealed transcript + output_digest for replay & audit
SPV (simple proof of validity)
- On‑chain: block header + Merkle proof (chain_id, height, root)
- Custody/bank: receipt headers (batch id, totals, timestamp, signature)
- We bind these to the same
window_idandoutput_digestfor cross‑domain proof
Data contracts (minimal)
event_id,ts_occurred,principal_id,instrument,currency,amount_minor,source_type(maker_fee|taker_fee|rebate|stake_reward|refund|adjustment),chain_id?
// Finance ACK (window-level)
{ "window_id":"2025-09-05/17:00", "reserves_ok":true, "signer":"fin-ops@...", "expires_at":"2025-09-05T18:00:00Z" }
// CT (principal/cohort-level)
{ "principal_id":"LP-99102", "status":"cleared", "expires_at":"2025-09-06T00:00:00Z" }
// SPV (optional, window-level)
{ "window_id":"2025-09-05/17:00", "provider_batch_id":"TXB-88919", "totals_minor":"123456789", "headers_hash":"0x..." }// Add to payout metadata & GL: window_id, output_digest, provider_batch_id, transcript_url
Worked micro‑example
// Hourly window W: $12,345.67 fees to 3 LPs; LP-B CT stale i128 accumulate → late quantize → carry-ledger (2 sub-cents assigned deterministically) Seal transcript → output_digest=0xabc... → Authorize(W) // HOLD(LP-B, STALE_PROOF); ALLOW LP-A/C Execute on-chain batch → provider_batch_id=0x...; POST SPV headers_hash Persist window_id/output_digest/provider_batch_id in subledger/ERP
Results teams aim for
Replay equality ≥ 99.99%
Windows where digest(replay) == digest(transcript).
Wei/penny‑exact outcomes
Late quantization + deterministic carry assigns sub‑units once; no drift on micro‑fees.
Time‑to‑release (p95)
Minutes from watermark close to authorized disbursement once proofs are fresh.
Reason‑coded blocks
Counts by reason (DIGEST_MISMATCH, STALE_PROOF, etc.) visible per window.
Migration safety
Promote only on digest equality across versions; canary and rollback bound risk.
Targets are set together during a pilot; they are goals, not guarantees.
Risks & mitigations
See risks & how we handle them
- Late/missing proofs → auto‑HOLD; re‑check without mutating outputs.
- Policy/migration defects → digest mismatch; canary + rollback; bounded exposure.
- Hot markets/partitions → versioned shard function; promote only on digest equality.
FAQ
How do you reconcile off‑chain accounting with on‑chain payouts?
We bind the same window_id and output_digest to both the sealed transcript and the on‑chain/custody receipt via SPV headers, so a replay can prove equality end‑to‑end.
Will we need new payout rails or smart contracts?
No. Keep your contracts and rails. We add a pre‑release gate and a tiny SPV receipt to tie the payout back to the transcript.
What about re‑runs that used to change wei/cents?
Integer math + late quantization + deterministic carry mean a re‑run produces the same outputs bit‑for‑bit. If not, it won’t authorize.
Pilot in 30 days
What we’ll ask in discovery
- Which markets/LP cohorts and rails (on‑chain vs ACH/PSP) are in scope?
- Where do off‑chain vs on‑chain totals differ today, and by how much?
- What must be true before cash moves? Who signs off?
Next step
Pilot a cohort for N hourly/daily windows; measure equality, reasons, and time‑to‑release.