Document integrity check: verify a sealed file against its seal.
Drop a document sealed in a Vault and paste the seal you downloaded from its record. Your browser computes the file's SHA-256 - the file is never uploaded - and sends only that fingerprint and the seal to Property Vault, which checks the seal's signature against its published keys. An inclusion proof from a record's export can be checked further down - rehearsal on XRPL testnet.
Check a Vault ID.
Someone has given you a Vault ID, such as PV-GB-LDS-004512, and you want to know it is real before you rely on it. Enter it here. The answer is only whether the ID names a live record, which asset class it is, and when its record was last sealed. It never shows an address, an owner, a Vault Score or a document: to see inside a Vault you need a link from its owner.
Hash, seal, root, memo, check.
Today: a SHA-256 file check, and a seal signed with Property Vault's key. Launching: a daily public timestamp - in rehearsal on the XRPL testnet now, mainnet on the roadmap, subject to approvals - so you will not have to take our word for it.
Hash
The file is hashed with SHA-256 on upload and given an integrity receipt. The hash fixes the exact bytes and reveals nothing.
Seal Live in pilot
The hash, the document, its version and the seal time are signed with Property Vault's key; the seal names the key by id and downloads from the record.
Daily Merkle root Launching
Each day's keyed commitments fold into one Merkle tree; its 32-byte root stands for all of them. Rehearsal on XRPL testnet.
Ledger memo Launching
The root goes to the XRP Ledger in one AccountSet memo from Property Vault's anchoring account - testnet in rehearsal, mainnet on the roadmap, subject to approvals. Nothing identifiable.
Public check Launching
Anyone with an inclusion proof rebuilds the path from the commitment to the root - below, in the browser, no network - and compares the root with the transaction on the anchor page.
Illustration of the method; anchoring is in rehearsal on the XRPL testnet.
Check an inclusion proof - rehearsal on XRPL testnet.
Integrity anchoring runs as a rehearsal on the XRPL testnet: Merkle roots of keyed commitments are written to the test network, which can be reset, and listed on the public anchor page; mainnet anchoring is on the roadmap, subject to approvals. A record's export carries the documents, their SHA-256 fingerprints and their seals - and no inclusion proof until its manifest has been anchored; after that it also carries one (pv-anchor-proof-v1): the keyed commitment of its manifest, the Merkle path to that day's root, and the testnet transaction the root was written in. Paste one here. Your browser recomputes the path with SHA-256 - nothing is sent anywhere - and says whether the commitment is in the root. Comparing the root with the ledger transaction is a visit to any XRPL testnet explorer (or the public anchor page); this page does not do it for you.
What a match proves - and what it does not.
A document integrity check answers one question, with certainty.
A match proves
- The file is unchanged. Byte for byte, it is the file whose fingerprint is in the seal.
- Property Vault signed that fingerprint. The signature checks against our published key, chosen by the key id. Until mainnet anchoring, that is our signature - tamper-evident, not independent.
- With an anchored proof (rehearsal on XRPL testnet): it existed by the anchored day. The timestamp is the ledger's, not ours.
- With an anchored proof: a later change would show. Rewriting any commitment would no longer match the published root.
A match does not prove
- Who issued it. Issuer and evidence grading live in the Verified History, the asset provenance record, off the ledger.
- That the work was good. A hash says nothing of quality.
- The Vault Score - a verification score - whether the documents exist, who issued them and that they are unaltered since issue; never a valuation, a credit input or a judgement of the work. It is computed off-ledger.
- Title or ownership. The ledger holds a pointer or attestation, never title; the statutory register wins. See Vault ID, the digital asset identity.
When to run a document integrity check.
Whenever a sealed document leaves the Vault it was sealed in and someone else has to rely on it. Four moments, each with the Pro workflow that carries the document and its status today.
Buying or selling a home
A buyer's solicitor who receives a building regulations completion certificate through the Sale-Ready Passport (launching in Yorkshire) checks the sealed document against its seal before relying on it. See material information for estate agents and conveyancers.
An insurance claim
A claims handler reading a Claim Evidence Report (launching) under an insurer scope sees sealed documents; the check confirms each file is the one that was sealed, and when. See insurance claim evidence for insurers.
A loan against an asset
The Collateral Report for lenders is in development: each answer in it links to its sealed evidence, and this check lets a credit team confirm a document is unaltered since issue. The lender decides; Property Vault never approves lending. See collateral verification for lenders.
A pre-owned sale
A Provenance Passport (launching) carries the authentication and service documents a dealer issued; the next buyer or auction house runs the same tamper-evident document check on each one. See auction house provenance and dealer records.
Verify a file hash without this page.
A seal is pv-seal-v2: an Ed25519 signature over pv-seal-v2|vault|document|version|n|sha256|sealedAt, with the public keys listed by id at /.well-known/pv-seal-keys.json (published, live in pilot). An inclusion proof is pv-anchor-proof-v1, algorithm sha256-pairs-v1: node = SHA-256(left ‖ right) over raw bytes, an odd level duplicates its last node; it carries batchId, network, root, txHash, ledgerIndex, leafIndex, commitment and siblings with sides. Rehearsal on XRPL testnet; the Vault API lists each anchor batch publicly.
-
sha256, key id and seal time in every seal - Merkle path (inclusion proof) with every export whose manifest has been anchored - rehearsal on XRPL testnet
- Readable from any public XRPL node
Document integrity check: common questions.
What is a document integrity check?
A document integrity check confirms that a file is, byte for byte, the one that was sealed: its SHA-256 fingerprint is recomputed and compared with the fingerprint written in the seal. On this page that comparison happens in your browser. If the seal is a signed pv-seal-v2 seal, Property Vault also checks the signature against its published key. A match proves the file is unchanged since it was sealed; it does not prove who issued it or that the work was good.
Is my file uploaded when I check it?
No. The file is hashed on your device with Web Crypto and never leaves it. Only the 64-character fingerprint and the seal you pasted are sent to Property Vault's seal check, which answers valid or not and reveals nothing else. No account is needed.
What is a SHA-256 file check and why does it prove anything?
SHA-256 turns any file into a fixed 64-character fingerprint. Change one byte and the fingerprint changes completely, and no two different files are expected to share one. So if your file produces the fingerprint written in its seal, it is the sealed file; if it does not, it is a different file or it has been altered. The fingerprint reveals nothing about the file's contents.
What does a “not valid” result mean?
Either the file's fingerprint differs from the one in the seal, or the seal's signature does not verify, or its key is unknown or revoked. Do not rely on the document as sealed; ask the professional who issued the record for the original. A “not switched on yet” message means only the comparison on your device was made, because the online seal check is still launching.
Can I verify a file hash without this page?
Yes. Any SHA-256 tool gives the same fingerprint, so you can check the document hash against the seal yourself. The seal format and the public keys (at /.well-known/pv-seal-keys.json) are published so that anyone can check a signature. Once daily anchoring to the XRP Ledger is live, the Merkle path in each seal will let you compare it with the public anchor from any XRPL node, without Property Vault - the design is set out in the Vault API, the verified records API.
Seal the documents that prove what you own.
Fingerprinted on upload; signed seals and daily anchoring are launching. Free for owners.