We verify on-chain claims independently.
When a project says its reserves are backed, its payouts are bounded, or its code cannot overspend, we re-derive that from raw ledger data and publish what could and could not be proven.
What that means in practice
- Every figure is recomputed from the ledger, never taken from a dashboard, an export or the counterparty's own report.
- Results are pinned to a specific ledger index and cross-checked against more than one independent node. Disagreement between nodes is reported, not smoothed over.
- Anything we could not establish is written down as unproven. Absence of a finding is never presented as a clean result.
What we do
Hook review
A Xahau Hook read line by line against the behaviour you state it has. Findings, a testnet reproduction wherever one is possible, and residual risk stated plainly. The report reaches you unedited.
Independent verification with a published evidence record
Your stated properties proved within a stated bound, a testnet reproduction, and a verification record that carries its evidence rather than asserting a result. The bound is part of the record: we write down what the prover explored and what it did not reach. A proof with no stated bound is a claim.
Proof of reserves and supply consistency
Holdings re-derived from raw chain data across at least two independent sources, fail-closed, pinned to a ledger. Attribution is reported separately from balance, because a gap in one is not a shortfall in the other.
The eight questions we can answer today
Eight read-only XRPL verifiers, each built to answer one question and refuse the rest. The refusal is the point: a tool that answers the question next door is how a reader ends up trusting something nobody checked. Each one below says what it will not tell you.
The issuer says N tokens exist. Are they on the ledger?
Supply re-derived from raw ledger data across at least two independent operators, pinned to a ledger, reconciled against the issuer's reported figure.
Will not tell you the token is backed. It compares two numbers.
The issuer says it cannot freeze or seize my tokens. Can it?
The issuer's on-ledger control profile, checked against its public policy claim, flag by flag.
Will not tell you whether they will. Only what the protocol permits.
What can an issuer do to an MPT I hold, and can it grant itself more power later?
The same question for Multi-Purpose Tokens, including whether powers can be added after issuance rather than only at it.
Says what is possible, never what is intended.
The payment says 1,000. Did 1,000 arrive?
An XRPL payment's Amount is what the sender was willing to send.
With a partial payment the amount delivered can be a fraction of it, and integrations that read
the wrong field credit the wrong number.
Will not tell you a payment was legitimate. Only what landed.
Is the price this protocol reads fresh, and does anything independent agree with it?
On-ledger XLS-47 oracles checked for staleness and cross-oracle deviation. A single uncorroborated feed is reported as single-source rather than as agreement.
Will not tell you the price is correct against the real market. Freshness and agreement only.
Is this account set being emptied right now, and can I evidence it?
Watches for the on-chain signature of a mass drain and, on trigger, produces a forensic reconciliation closed against independent providers.
Cannot prevent a drain. If the keys are already compromised the attacker produces valid transactions and the ledger accepts them.
This gate says only approved holders can act. Does the protocol enforce that?
Separates a rule the ledger itself enforces from one an application merely asserts. Four verdicts, never collapsed into pass or fail, including the case where the gate is real but this subject does not satisfy it.
Answers enforceability, not whether the rule is the right rule. A gate can be perfectly enforced and still be the wrong gate.
Is this account in the population exposed by the XRPH weak-key defect?
A defensive scan of public key material and history against the signature of the September 2026 wallet drain.
Reports risk. Never claims a key is compromised, never claims a key is safe, and contains no code that derives, guesses or brute-forces a key.
One of the eight is published above as a complete, signed, re-runnable record. The other seven are run on request against your accounts and your claim; there is no published artifact for them yet, and this page is not implying otherwise.
What we will not do
We do not issue a verification record for something we could not verify. We do not soften findings, and we do not remove them at a client's request. Where something needs a chain to settle it and the chain cannot, we say it is unverified rather than dress it up.
A worked example
In July 2026 we verified a Ward Protocol lending lifecycle on XRPL Devnet: nine semantic checks recomputed from the chain, one residual disclosed.
Re-deriving a later Ward verification record in September, we found a stale reserve constant in our own issuing script. The published ratio was wrong; the verdict was not. That is recorded beside the record, and Ward was told.
Devnet later purged the pinned ledger. That record can no longer be reproduced by anyone, including us, and Ward publishes it on their own site marked exactly that way.
A verification record that quietly stops being checkable is worth less than one that tells you it has. We would rather ship the second kind.
Three verification records issued to date. Two remain reproducible today.
The RLUSD supply record is the one you can check without asking us for anything: the signed artifact and the pinned key are both published, and the verification is four lines of stock OpenSSH. Read it, or check it yourself →
Also published with its signature and key: the Delegate Watch baseline, a snapshot of who could sign for a watched set of XRPL accounts before delegation activates. Read it, or check it yourself →
Reproduced Hooks: for deployed Xahau hooks, whether the on-ledger bytes match a public source commit, with the source and the ledger reads named so anyone can re-check them. Not an audit, and not a safety claim. Read the registry →
Kairo Vault Technologies GK · 合同会社 Kairo Vault Technologies
Corporate number 8010003051230 · Tokyo, Japan
Enquiries: dane@kairovault.com
Entity details: for-banks.html