RWA & TOKENIZATION

Catch drift between attestations.

Hira reconciles your fund register and reserve instructions against onchain supply — every mint, burn, and redemption — so drift surfaces per event, not per quarter.

For tokenized funds, treasury-product issuers, and fund administrators that own their contracts.

500,000 units minted — no instruction
Supply Parity Policy
Hard BreachOpenSLA
Portfolio
Issuance Controls
Opened
4 Jul
AKAmira Khanc60d94ab
NAV feed stale for 3 pricing windows
Oracle Freshness Policy
Soft BreachOpenSLA
Portfolio
Fund Token Ops
Opened
4 Jul
STSophie Tran1e73da5f
Mint signed by key outside approved set
Mint Authority Policy
Hard BreachOpenSLA
Portfolio
Issuance Controls
Opened
4 Jul
ECEthan Coled15c72e9
BUILT FOR GENIUS Act · enforcement Jan 2027 MiCA · daily reserve reconciliation MAS PSA AUSTRAC · live Jul 2026
Why now

Your attestation is monthly. Your risk is per-block.

~$24B
in tokenized real-world assets onchain by mid-2025 — roughly doubling year over year
— rwa.xyz, 2025
99%
of TUSD’s attested reserves sat in a speculative offshore fund by the time the SEC acted, per the SEC’s complaint — while attestations kept publishing
— SEC v. TrueCoin & TrustToken, Sept 2024
~59%
of 2025 onchain losses were access-control and operational failures — not code bugs
— Hacken, 2025

The assets are institutional now. The failure mode is still an admin key and a stale snapshot.

The controls

Every mint authorized. Every drift caught. Every holder eligible.

Detective controls on the four failure modes that actually take tokenized assets down. Hira monitors and flags — your preventive stack stays in the settlement path.

Mint authority

From unmatched mint to open exception — inside the block window.

Every token created onchain must trace to a mint your back office emitted — an unmatched mint raises an exception the moment it settles.

Explore the incident walkthrough

Asset-token parity

Two snapshots that only agree by luck — reconciled continuously.

Supply, reserves and register are three ledgers that drift silently — Hira checks them against each other on every event.

Explore parity policies

Redemption integrity

Requested and settled matched — or the gap stays open.

A redemption is clean only when the onchain burn matches your books — stuck or oversized ones surface with a clock on them.

Explore the exception model

Eligibility & admin actions

Proof the preventive layer is holding — every day.

Whitelists are enforcement, not evidence — Hira independently verifies holders stay eligible and every upgrade maps to an intended admin.action.

Explore admin controls

Put a name and a clock on every breach

Assigned in seconds. Resolved on a deadline. Recorded forever.

A parity breach that lives in a Slack thread dies in a Slack thread. In Hira, every breach opens as an exception — assignee, severity, SLA countdown, append-only record. When the auditor asks what you knew and when, the answer is already written.

Explore the exception model

Clear the drift before the attestation date

The attestation window, run as a live queue.

Between attestations, drift accumulates: a late burn, a misposted reserve movement, a lapsed eligibility. The board turns that backlog into columns, so you walk into every attestation with the exceptions closed and the working papers written.

See how exceptions are worked
NAMED INCIDENT — ILLUSTRATIVE WALKTHROUGH

The unauthorized mint that created $200M in one transaction.

Gala Games · May 20, 2024
$200M

A single unauthorized address called mint on Gala Games’ token contract and created five billion GALA — roughly $200 million — in one transaction. No contract bug: the mint function did exactly what it was told, by an address whose admin access nobody had revoked. Around $21 million was sold before the address was blocklisted.

— Gala Games disclosures; onchain record, May 2024
block 19,876,102 — mint 5,000,000,000.00 observed onchain · no matching mint event → exception opened: Unmatched mint · severity critical
+2s — parity policy re-evaluates: supply exceeds last reserve.snapshot by 8.2% · second breach linked to the same exception
+8s — escalated to on-call risk owner · every step on the record
Open · SLA 1h · critical

Real incident. Illustrative detection — Hira did not monitor this system.

Detection here assumes the issuer’s backend was instrumented — the point is the mechanism: an onchain mint with no first-party instruction is undetectable to chain analytics, and unmissable to reconciliation.

Policy packs

Coverage that maps to the rulebooks.

One call. A second reader for your register.

You already log every mint instruction and reserve movement internally — track() just gives that log a second reader. Nine typed event types, decimal-string amounts, server-side only; instrument it in days while your issuance stack is still being built, not retrofitted after launch.

Read the SDK docs
reserve-service.tsstreaming
hira.track('reserve.snapshot', {
  reserveBalance: '412874390.55',
  circulatingSupply: '412110204.00',
  custodian: 'bny-mellon',
  attestationRef: 'ATT_2026Q2_F1',
  correlationId: 'rs_20260705_0900',
});
FAQ

Questions risk teams ask.

What does Hira actually watch?

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.

How is this different from Chainalysis or TRM?

Keep them — they screen counterparties against public chain data, and they’re good at it. They’re structurally blind to your own operations: whether a mint was authorized by your back office, whether your register matches your token holders, whether an upgrade was meant to happen — 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.

Does Hira sit in our transaction path?

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.

We already publish attestations and run proof of reserve — why continuous?

An attestation proves reserves existed at a moment; it doesn’t tie any individual mint or redemption back to an authorized instruction. The SEC’s TrueCoin settlement showed attested backing can be materially misstated for months between snapshots (SEC, Sept 2024). Hira reconciles per event and hands your attestor a period with zero unexplained breaks — continuous reconciliation makes the attestation stronger, not redundant.

Get started

Know your register and the chain agreed — the whole time.

Detective controls for tokenized assets — reconciling your register, your reserves, and the chain on every event.

More use cases