How it works

A certificate you can check without trusting us

A property check turns the public record about one address into a certificate that is sealed, versioned and anchored on Bitcoin, so that anyone can prove what was known, and when, without trusting this service.

1. The check

Enter an address. The service resolves it to a location, then reads every register it can reach in parallel: HM Land Registry price paid data, planning.data.gov.uk for heritage and planning constraints, the Environment Agency for flood risk, PlanIt for planning applications, the Mining Remediation Authority for coal mining areas, the EPC register, Ofcom for connectivity, Companies House when a company owns the title, and the title register itself once HM Land Registry Business Gateway access is in place.

Every fact is tagged with where it came from and how much weight it carries:

Around forty plain-English rules then turn the facts into findings (red, amber or informational), a verdict per section, and one overall line a buyer, agent or lender can act on.

2. The seal

The finished check is written out as canonical JSON (sorted keys, no whitespace) and hashed with SHA-256. That hash is the seal printed at the foot of every certificate. The verify page recomputes it from the stored data on every visit; if a single character has changed, the seal no longer matches. The exact bytes that were hashed can be downloaded, so the seal can be checked with any SHA-256 tool.

3. The version chain

A seller declaration does not edit the certificate; it creates a new version. The new version's sealed bytes include the previous version's seal, so the versions form a chain. Rewriting an earlier version would change its hash and break every later seal. All versions and their proofs stay available.

4. Anchoring on Bitcoin

A seal proves the content has not changed. It does not, on its own, prove when it was made: the operator could back-date a record. Anchoring fixes that.

  1. Every 10 minutes, every seal that has not yet been anchored is collected into a batch.
  2. Each seal is given a random nonce and hashed again, so the public servers in the next step never see the seals themselves.
  3. The batch is built into a Merkle tree, using the OpenTimestamps reference algorithm, and only the tip is sent onwards.
  4. The tip goes to public OpenTimestamps calendar servers (4 of them, run by different operators). Each aggregates tips from many users and commits them to the Bitcoin blockchain in a single transaction every few hours. Their immediate reply is a Anchoring proof.
  5. Later, the service asks the calendars for the finished proof. Once a Bitcoin block header is in it, the seal is Anchored in Bitcoin: the block's timestamp is an upper bound on when the certificate existed, secured by the whole Bitcoin network rather than by us.

Each seal gets its own standard .ots proof file. It contains the seal's nonce, its path through the Merkle tree, and the calendar's path into the Bitcoin transaction. Nothing about the property, and nothing about any other seal, is revealed by it.

There is no token, no smart contract and no fee. The blockchain is used for the one thing it is uniquely good at: an immutable, globally witnessed clock.

5. Verifying without us

Download the sealed bytes and the proof from any certificate's verify page, install the reference client, and run:

pip install opentimestamps-client
ots verify -f <sealed.json> <seal.ots>

The client recomputes the SHA-256, follows the proof, and reports the Bitcoin block that commits to it. With a local Bitcoin node it needs no third party at all; without one it asks a public block explorer for the block header.

What it is not

It is not legal advice and it does not replace conveyancing. Anchoring proves that a certificate existed at a time; it does not make the registers it was drawn from correct. Items marked Unavailable were not checked, and the certificate says so. Register data is used under the Open Government Licence and each source's own terms.

Check a propertySee recent checks