Hive  /  Ondo · Tokenized RWA Attestation
For Ondo Chain validators, Global Markets issuers, and the institutions running tokenized treasuries

Ondo built the L1 for tokenized RWAs.
Hive ships the receipt envelope underneath.

Ondo Chain uses a permissioned validator model. Ondo Global Markets lists over 200 tokenized U.S. stocks. USDY runs on five chains with $740M outstanding. The SEC's tokenized stock framework lands this week. Here's what Ondo doesn't ship today: a record of every mint, burn, bridge, and counterparty action that the SEC, the local regulator, the broker-dealer, and the holder can each read their own piece of. That's the layer Hive built.

4-part attestation SEC-ready Ondo Chain compatible LayerZero bridge aware ViewKey selective disclosure
See a signed receipt in 60 sec Talk to Hive
$2.5B+
Ondo TVL · Feb 2026
$740M
USDY outstanding · 5 chains
200+
GM tokenized U.S. securities
4
Independent attestation gates
A · Ondo Chain
SHOD as the validator policy gate
Six-hop outbound discrimination on every transfer
B · Global Markets
ViewKey for SEC + local regulator
One receipt, three lenses per GM token event
C · USDY
Cross-chain mint/burn receipts
Burn on Ethereum ↔ mint on Solana, one envelope
D · SWEEP
CFO-grade fund event receipts
State Street + Galaxy seed, audit-ready from day one

AOndo Chain: SHOD as the validator-side policy gate

Ondo Chain uses a permissioned set of validators to stop front-running and protect institutional trades. SHOD does that same job at the receipt layer. Six checks run on every transfer: sanctions, jurisdiction, scope ceiling, counterparty risk, time-of-day, and policy proof. All six have to pass, or the receipt won't sign. The validator never has to make a decision call. The result is mechanical, signed, and any regulator can check it offline later.

What gets signed

Every transfer on Ondo Chain carries a SHOD route before the validator commits.

  • Gate 1: Sanctions. Checks OFAC, EU, and UK lists against the sender, the receiver, and any beneficial-owner chain that did:hive can trace.
  • Gate 2: Jurisdiction. Matches the buyer's KYC residency against the issuer's offering rules (Reg S, Reg D, and local equivalents).
  • Gate 3: Scope ceiling. Uses the HAHS hire-time scope receipt. The token can't do anything the issuer never authorized.
  • Gate 4: Counterparty risk. Sets an exposure ceiling per counterparty, signed by the issuer's risk engine.
  • Gate 5: Time-of-day. Enforces underlying-market hours for GM tokens and the redemption window for USDY.
  • Gate 6: Policy proof. Uses a SpectralZK zero-knowledge proof to show the issuer's compliance policy ran, without revealing the policy itself.

The validator sees pass or fail. The regulator can see the full record on request. A front-runner sees nothing, because the gates run before the trade commits, not after.

BOndo Global Markets: ViewKey for the four regulators that care

Take a GM token tracking AAPL. A U.S. broker-dealer holds the underlying stock. A Cayman or BVI issuer wraps the token. A buyer in Singapore or Germany has a local regulator who wants to see the trade. And the SEC, under the May 2026 framework, wants a trail it can verify on-chain. Right now each of those four groups sees a different slice through a different reporting pipeline. With Hive ViewKey, all four read the same signed receipt. Only what they're allowed to see changes.

One receipt, four lenses

Issue once. Every regulator gets exactly what they are allowed to see, nothing more.

  • SEC lens. Sees trade size, the U.S.-person check result, the broker-dealer of record, the settlement chain, and the gate results. No buyer personal data.
  • Local-jurisdiction lens. Sees the buyer's KYC tier, residency, offering eligibility result, and local-tax flag. No counterparty position data.
  • Broker-dealer lens. Sees the underlying security's CUSIP, lot size, mark-to-market reference, and hedge attribution. This is the full operational view.
  • Holder lens. Sees their own trade confirmation with cost basis, accrued yield (for USDY), and a hash they can check and post to their own wallet.

Same JSON. Same signature. Four different decryption keys, each scoped to what that regulator is entitled to. ML-DSA-65 plus Ed25519. Verifiable in a browser at thehiveryiq.com/verify.

CUSDY: cross-chain mint and burn, one signed envelope

USDY sits on Ethereum, Solana, Mantle, Sui, and Aptos. The Ondo Bridge runs over LayerZero. Today a burn on Ethereum and a mint on Solana are two events in two different log streams that an auditor has to reconcile manually. Hive ships a single four-part receipt that binds the burn-tx hash, the bridge-message hash, the mint-tx hash, and the off-chain NAV-at-bridge-time into one envelope. The auditor reads one record. The regulator reads one record. The holder reads one record. Reconciliation goes from a workflow to a verification.

What the envelope binds

Burn on chain A, mint on chain B: one signature, no orphan events.

  • Source-chain burn: tx hash, block, burner address, amount, and NAV at the time of the burn.
  • Bridge message: LayerZero message ID, source endpoint, destination endpoint, and message hash.
  • Destination-chain mint: tx hash, block, mint recipient, amount, and NAV at the time of the mint.
  • Off-chain reconciliation: a NAV-delta attestation, fee accrual, and a SpectralZK proof that the bridge policy ran correctly, without revealing the policy.

If the destination mint never lands, the envelope never signs. If the burn was for the wrong amount, the envelope never signs. The receipt is the reconciliation.

DSWEEP: CFO-grade fund event receipts, audit-ready from day one

Ondo announced the SWEEP tokenized fund with $200M seed from State Street and Galaxy Asset Management. A fund of that profile launches into a PCAOB and SEC audit environment from day one. The traditional answer is a custodian-of-record statement, a transfer-agent log, and a separate fund accounting line. Hive collapses those three into a single four-part receipt on every subscribe, redeem, NAV strike, and distribution. The auditor verifies offline. The CFO closes the books faster. The regulator gets a feed they can verify without trust.

Fund events that get signed

Every state transition the fund cares about, signed and bound to the underlying.

  • Subscription: LP identity (via did:hive, never raw personal data), subscription amount, NAV at strike, and the fund-of-record attestation.
  • Redemption: LP identity, redemption amount, NAV at strike, and the sweep account debit hash.
  • NAV strike: underlying portfolio composition hash, valuation source attestation, NAV value, and the strike timestamp.
  • Distribution: payout per LP, withholding flags, tax-jurisdiction lens, and the receipt-of-funds hash.

This uses the same shape as USDY and GM. One verifier at thehiveryiq.com/debugger reads every Ondo event, no matter the product.

EEconomics: priced per event, not per seat

Hive isn't per-seat software. Receipt pricing reflects the workflow and evidence volume. Any operator revenue share requires a separate agreement identifying the eligible operator and payment basis; it is not an automatic property of every receipt.

USDY event
$0.10 per mint/burn/bridge receipt
GM token trade
$0.25 per signed trade confirm
SWEEP fund event
$1.00 per subscribe/redeem/NAV strike

Volume tiers available. Negotiate the floor on the contract, not the per-transaction price.

FWhy this lands now

GGet in touch

The fastest way to evaluate is to run the live A2A demo against a synthetic GM-token issuance. Two agents transact, both sides hold the receipt, you verify it in a browser at thehiveryiq.com/verify. End-to-end, sub-250ms.

Ondo built the rails. Hive signs the receipts.

Four-part attestation on every tokenized RWA event. SEC-ready. Audit-ready. You can check it in a browser. It drops right in on Ondo Chain, Global Markets, USDY, and SWEEP, with no schema change.

new in the canon · runnable on this page

Compare the token record on both sides

These receipts add a checkable bridge between an onchain token event and its offchain record, with the screening context kept beside the event. They answer in production right now, and the runs below prove it end to end.

ledger.parity

Compare an onchain token event with its offchain record

This receipt lets an issuer, transfer agent, or operations team compare two named records for the same token event. Each side is observed at a named cursor and time, then a separate registered attestor key commits a fingerprint over the agreed fields. The service recomputes whether those two fingerprints match within the declared timing window. A divergence stays explicit when a mint, redemption, bridge event, or register update needs investigation. Compliance, risk, and legal can review the comparison without receiving account balances or holder data.

What it does not do. It does not disclose positions, balances, holder identities, or account identifiers, and it cannot confirm that either fingerprint correctly represents the record it names because it has no read access to that record. It does not decide which record is right, assign fault, judge whether the token action or register update was proper, or effect or reverse settlement; a late window only says the observations were too far apart for a decisive comparison.

POST /verify/ledger-parity · case pass, a clean record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/ledger-parity · case diverge, the two records disagree

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/ledger-parity · case fail, a forged record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

screening.attestation

Keep the screening run with a tokenized treasury action

This receipt preserves how a counterparty screening result was produced for a tokenized treasury action. It binds the named screening engine, ruleset version, primary list, supplemental lists, and their declared versions to a protected counterparty identifier. It also records the screening time against an external reference, the drift bound, the signing authority requirement, the stated verdict, and its validity period. That gives compliance and legal a durable account of the particular run alongside the token event. A matched result remains connected to its screening context for the team that must decide what happens next.

What it does not do. It does not show that any list is complete, accurate, current, free of omission, or properly published, decide that a counterparty is restricted, detect every false negative, or detect an engine that reports clear after its own matching computation found a match. It does not assess the program, rule thresholds, whether the screened lists or validity period suit any obligation, reveal the counterparty, list record, or match score, prove control of the commitment key or window secret, admit or reject a counterparty, or authorize, block, freeze, reverse, settle, report, or provide a legal, regulatory, or compliance conclusion.

POST /verify/screening-attestation · case pass, a clean record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/screening-attestation · case matched, a name matched the list

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/screening-attestation · case fail, a forged record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

Every run above posts a verified request body from this domain to the open verify route and prints what came back. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That is on purpose. Nothing on this page is a production issuance, a customer record, or an endorsement. Patent Pending.