Hira reconciles every hot-wallet movement, withdrawal and admin action against independent onchain truth — and turns any gap between intent and settlement into an accountable exception.
For centralized exchanges, OTC desks and brokerage VASPs that hold their own keys.
The penalty was for what monitoring didn’t see. The thefts went through approval paths nobody watched. Same blind spot — your own operations.
Deterministic policies over your own ledger and the chain — Hira monitors and flags; your desk decides.
An onchain movement with no matching backend event is exactly what a compromised signer looks like — the highest-severity signal in the system.
Explore the walkthroughYou author the thresholds — per asset, wallet tier and desk — and every breach arrives with a reviewer and a deadline attached.
Explore policy packsRate-of-change policies per wallet, asset and hour — a drain pattern breaches long before the balance goes to zero.
Explore the walkthroughEvery roleGrant, rotation and pause held against policy — the role grant comes before the theft, and this is where it’s caught.
Explore the exception modelWhen a policy breaks, Hira opens an exception — severity, assignee, SLA clock — and records every state change immutably. When the examiner asks who reviewed the March 14 flag, the answer is one link, not a week of spreadsheet archaeology.
Explore the exception modelThe board holds only breaches of policies you wrote — a threshold crossed, a movement unmatched, a role granted off-schedule. No vendor risk scores, no black-box typologies. Queued by SLA, so the desk works the clock, not the noise.
See how exceptions are workedA routine cold-to-hot ETH transfer went out for signing. The signing interface had been manipulated: authorized signers approved a transaction that rewrote the wallet’s logic and redirected the funds — the largest theft in crypto’s history, through the exchange’s own approval path. Roughly $160M was laundered within 48 hours.
Real incident. Illustrative detection — Hira did not monitor this system.
track() is asynchronous, fail-open and server-side — it never sits in your withdrawal path and never adds latency a customer can feel. Instrument one flow in an afternoon; start with large-transfer review on withdrawals and expand control by control.
Read the SDK docsimport { Hira } from '@hira/sdk'; const hira = new Hira({ apiKey: process.env.HIRA_KEY, }); hira.track('transfer', { amount: '250000.00', asset: 'USDT', fromAddress: '0x9f4…cold-vault', toAddress: '0x71a…hot-01', correlationId: 'cw_20260705_0091', });
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 withdrawal your backend never intended, a hot-wallet balance drifting from your ledger, a role granted at 3am — 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.
Deterministic controls on your own flow — reconciled against the chain, resolved on a clock.