Is MX Useful to Blockchain?

The previous post in this set established that MX is not a blockchain and does not need one. That is one direction of the question. This post takes the other: when somebody is using a chain, does MX add anything useful? The answer depends on what they are using the chain for.

Two different jobs at the same record

Take any single piece of evidence a chain is being asked to hold: a verifiable credential, a notarised document hash, a land-title entry, a supply-chain attestation. There are two jobs to do with it.

The first is verification: is this record genuine, who put it there, and has it been altered since? A well-designed chain answers all three with cryptographic certainty.

The second is discovery and use: where does an agent or system find this record, what does it mean, who is allowed to act on it, and how does it relate to other records? A chain answers almost none of those questions, because that was never its job.

MX is built for the second job. When a chain is the bearer of a record, MX is the layer that turns it into a record other systems can find and use.

What an on-chain record looks like to a machine

From a machine's point of view, a typical on-chain record is a hash, a signature, a timestamp, the address of whoever put it there, and maybe a URI pointing somewhere else for the actual content. That is enough to verify it. It is not enough to act on it.

What is missing from the on-chain blob, every time:

• A discoverable title and description in a form a search index or AI agent can consume.
• Provenance: who created the underlying thing, when, against which version of which standard.
• A content type, so an agent knows whether it is looking at a credential, a contract, an invoice, or a photograph.
• Relationship metadata: what does this record amend, supersede, depend on, or attest to.
• Permissions and intended use: who is supposed to read this, and for what purpose.
• Localisation: which language, which jurisdiction, which schema version.

A chain does not carry any of those because putting them on the chain would be wasteful and impossible to update. MX puts them in the document the record points at and exposes them in a form a machine can discover and read.

Where MX plugs in

The integration is simpler than it sounds. The on-chain record carries a URI; the document at that URI is an MX-described object; an agent that follows the URI finds a record it can structurally understand. The chain still does the verification; MX does the description. Neither has to know much about the other.

Three patterns recur:

Hash-anchored documents. A document is hashed; the hash plus a signature goes on the chain; the document lives on a normal web server with MX metadata. An agent fetches the document, verifies the hash against the on-chain entry, and uses the MX structure to understand what it has just verified.

Linked credentials. A verifiable credential issued under W3C VC-Data-Model 2.0 includes a status field that can point at a chain entry. The credential itself is a JSON-LD object that MX patterns describe (issuer identity, valid-from, valid-to, schema reference, attestation chain). An agent reads the credential, checks status against the chain, and uses the MX-exposed metadata to know what the credential is for.

Indexed registries. An on-chain registry (of titles, of companies, of identifiers) is fine for proof-of-record. It is hostile to discovery. An MX-described mirror, refreshed from the chain on every commit, gives search indexers and AI agents something they can actually read, with the chain entry as the source of truth they verify against.

Worked example: a verifiable credential

Imagine a professional certification issued to a contractor. The issuer wants tamper-evidence; the contractor wants portability; a hiring platform wants to verify the certification quickly and a recruiter wants to find people who hold it.

A chain entry can do tamper-evidence and revocation status. By itself it cannot do "find me everyone certified to install medical-grade gas systems in Scotland with their certification valid through 2027". That second query is a discovery problem. The credential document, hosted as JSON-LD with MX-described provenance, audience, and validity metadata, is what the discovery layer reads. The chain is what the verification step checks against. Together they answer both questions; either alone answers half of one.

Worked example: a public register

A land registry on a chain solves a real problem: nobody can quietly alter a title. It introduces another: how does anyone find a title, parse the parcel boundaries, see what easements apply, or relate a title to its planning history?

The chain answer is "we will publish indexes off-chain". As soon as that decision is made, the off-chain index has all the same problems the rest of the web has, and benefits from the same solutions. MX-described title documents, with provenance back to the chain entry, give search, audit, and AI access without putting any of that on the chain. The chain still owns the proof. MX owns the access.

What MX does not do for chains

To stay honest about scope:

• MX does not validate on-chain signatures. That is the chain's job and the verifier's job; MX records the result, it does not produce it.
• MX does not arbitrate forks. If two chains disagree about the history of a record, neither MX nor REGINALD has an opinion. The chain that the document references is the chain whose authority counts for that document.
• MX does not run smart contracts. A smart contract that has read access to MX-described content reads it the same way any other client does.
• MX does not store on-chain data or replicate the chain. The registry holds attestations about documents; the chain holds the chain.

Within those limits, MX is straightforwardly useful to any application that uses a chain as a record system. The two layers do different jobs at the same record and stay out of each other's way.

Read the rest of the set

What Blockchain and Crypto Have to Do with MX sets out what MX is and is not. NFTs and MX is the worked case where token-on-chain and content-off-chain meet. MX and Cryptocurrency: Drawing the Line closes the set with the case where MX has nothing useful to say.