Hira compares the payouts your backend instructed with what actually settled onchain — and reconciles your reserve ratio daily, corridor by corridor.
For stablecoin issuers, cross-border payout operators, and B2B settlement platforms that own their contracts.
The money moved to production corridors; the failures moved from smart contracts to operations. Chain screening never saw either coming.
Four detective controls, evaluated continuously against your policies. Hira monitors and flags — it never sits in your payout path.
Every reserve.snapshot is reconciled against onchain supply — built for MiCA’s daily reconciliation and the reserve reports you certify under GENIUS.
Explore reserve controlsPer-corridor caps, counterparty ceilings and velocity windows — one oversized payout or a hundred fast small ones trip the same policy.
Explore threshold policiesEvery payout destination screened — including the indirect exposure that hides two hops into a corridor. Your team decides the action, on the record.
Explore sanctions screeningEach instruction matched to its settlement by correlationId — the payout that never landed and the transfer nobody asked for both surface.
Explore reconciliationWhen a policy trips, Hira opens an exception: what fired, who owns it, how long until the SLA breaches. Every comment and state change lands on an immutable record — the reconstruction an examiner asks for, already written.
Explore the exception modelExceptions land on a board your payout-ops team actually works: queued by SLA, filtered by corridor. An AU→PH break can’t hide behind EU→UK noise — and breaks per corridor becomes the metric your bank partners ask for.
See how exceptions are workedCircle disclosed that $3.3 billion of USDC reserves were stranded at Silicon Valley Bank as it collapsed. USDC — a fully-attested stablecoin — traded down to roughly $0.88, a 12% depeg, within hours. The reserves existed; the market just couldn’t see where they were fast enough.
Real incident. Illustrative detection — Hira did not monitor this system.
The failure wasn’t the depeg — it was the 48 hours in which nobody could prove where the backing sat. Continuous reserve telemetry is how an issuer answers that question in minutes.
You already emit these events internally — the SDK just gives them somewhere to go. One server-side call, nine event types, decimal-string amounts; detective-only and fail-open, so if Hira is ever unreachable your payouts still flow.
Read the SDK docsimport { Hira } from '@hira/sdk'; const hira = new Hira({ apiKey: process.env.HIRA_KEY, }); hira.track('payout', { amount: '87500.00', asset: 'USDC', corridor: 'AU-PH', toAddress: '0x8f3c…9a41', correlationId: 'po_20260704_1192', });
Two feeds. Your backend emits events through one server-side track() call — payouts, transfers, mints, redemptions, reserve moves, admin actions. Hira reads the chain independently and reconciles the two, then evaluates every event against your policies: thresholds, ratios, velocity, sanctions. Anything that crosses a line opens an exception with a named owner and an SLA clock.
Keep them — they screen counterparties against public chain data, and they’re good at it. They’re structurally blind to your own operations: an unauthorized mint, a reserve ratio drifting under 1.0, a payout your backend never instructed — all of it looks perfectly normal on chain. Hira compares your first-party backend events against independent chain state — the gap screening tools can’t see, because they never had your intent to compare against.
No — and that’s deliberate. Hira observes events and chain state out of band: it adds zero latency, never holds keys, and can’t fail closed on your flow. The SDK is fire-and-forget and fail-open — if Hira is ever unreachable, you lose visibility, not availability. Your existing systems keep deciding what moves.
Reserve ratio reconciled daily, every payout screened and matched, every breach on a clock — with the evidence written as it happens.