The first time an institutional allocator asked me to prove — not explain, prove — that the reserve backing a yield token was actually what it claimed to be, I realised I didn't have an answer that didn't require them to trust my word. I had the whitepaper. I had the audit PDF. I could point to the issuer. None of it was independently verifiable without taking my word for the inputs.

That was the problem I built this to solve.

To be clear: the tech-literate corner of crypto already fills this gap, informally. A skilled person can go on-chain, read the contract bytecode, check the access controls, cross-reference the audit report against the deployed code. That works. It's what the best DeFi researchers do.

The problem is that it doesn't transfer.

When a TradFi allocator gets a credit rating, they get something they can hand to a risk committee — a structured output with a named methodology, a named agency, a paper trail back to the underlying data. The committee doesn't need to re-derive the analysis from scratch. The analysis itself is the deliverable.

When that same allocator relies on a tech-literate DeFi researcher, they get:

• One person's assessment, applied through their own mental framework

• No standardised, versioned policy that a second researcher would apply identically

• No cryptographic record of what the contract state was when they checked

• Nothing that proves to a third party — six months later — what was verified and when

• Nothing that scales across 91 protocols with consistent, comparable outputs

The individual expert can verify. They cannot make that verification transferable, comparable, or tamper-evident. That's the gap.

For a $50M institutional allocation, the risk committee needs the latter. Not because the expert is wrong — but because "my colleague checked it" isn't a risk framework.

A "trust policy" is a YAML or JSON document listing the rules a protocol must satisfy (e.g., "rule_001: contract has an assetIdentifier state variable"). The policy must be:

• Content-addressed: its hash is computed from the canonical bytes of the rules block, excluding its own signature and hash fields. The hash committed to disk has to match the hash recomputed from the file.

• Signed by a known policy author key, identified by a public key that's published separately (e.g., in a GitHub repo).

• Versioned: every policy carries policy_version (semver or git SHA). When the policy changes, old attestations don't silently lose their meaning — they remain valid against the old version.

If you can't tell which version of which policy was applied, you can't compare two protocols.

A real attestation engine doesn't have one "scorer." It has a set of sub-agents — one per data domain — each with its own keypair:

• Contract parser agent — reads on-chain bytecode, returns proof_elements about state variables, function modifiers, event emissions

• Market data agent — fetches oracle prices, returns proof_elements about price liveness and validity

• Admin policy agent — checks multisig configurations, timelock parameters, upgradeability surface

Every proof_element gets signed by the agent that produced it, before it's bundled into the attestation. The signature is over the canonical form of the proof_element (sorted keys, no whitespace, deterministic encoding), so a tampered byte changes the hash and breaks the signature.

This means: even if the orchestrator is compromised, the per-proof signatures from the sub-agents still tell you which inputs were authentic.

Once the sub-agents have produced their proofs, the orchestrator:

1. Assembles them into a result graph

2. Computes the canonical JSON of the full body (excluding its own signature)

3. Signs that body with the orchestrator key

4. Embeds the signature and the orchestrator's public key

When a new attestation supersedes a previous one (the protocol got re-evaluated because an input changed), the new attestation includes:

• supersedes_attestation_hash: the canonical content hash of the previous attestation, inside the signed body of the new one

This is the critical structural property. A soft reference like supersedes_id: "att-buidl-00002" is spoofable — anyone could swap the prior attestation file and the chain still "validates." But if the new attestation's signed body contains the hash of the prior body, swapping the prior file breaks the chain detectably.

Most trust scoring re-runs the entire scoring pipeline every time anything changes. That's expensive and loses the audit trail.

Differential re-attestation does this instead:

1. Load the previous attestation

2. Verify its signatures — fail closed if any sig is invalid

3. Detect which inputs have changed since the previous attestation (via inputs_hash recorded per proof)

4. Re-evaluate only the rules whose inputs changed

5. Carry forward the byte-identical original proofs for rules whose inputs didn't change — do not re-sign carried-forward proofs

6. Sign the new orchestrator-level body, embedding supersedes_attestation_hash

What this gives you: a continuous, append-only chain of trust statements. You can walk backward through the chain and verify every step. You can ask "when did rule_004 last change for BlackRock BUIDL?" and get a precise answer with cryptographic provenance.

Here's an actual signed attestation summary from a working engine, for BlackRock BUIDL:

{ "attestation_id": "att-blackrock-buidl-00003-aa2ca312", "attestation_seq": 3, "attestation_schema_version": "1.5", "protocol_slug": "blackrock-buidl", "policy_id": "rwa_compliance_v0_1", "policy_version": "v0.1.0", "policy_content_hash": "f574ef2f109376357f20fbd279c0a44ed15fde3d092ff671d7a1c7c83bc68d59", "supersedes_attestation_hash": "186674893f86ef364ac39fc13985baef4dbdb827e40c022f20a6d6ef032235cc", "timestamp": "2026-05-22T...", "results": [ { "rule_id": "rule_001_asset_id_presence", "status": "PASS", "proof_elements": ["...signed..."] }, { "rule_id": "rule_002_value_update_function_presence", "status": "PASS", "proof_elements": ["...signed..."] }, { "rule_id": "rule_003_owner_only_access", "status": "PASS", "proof_elements": ["...signed..."] }, { "rule_id": "rule_004_cfg_price_fetch_feasibility","status": "PASS", "proof_elements": ["...signed..."] }, { "rule_id": "rule_005_cfg_price_value_validity", "status": "PASS", "proof_elements": ["...signed..."] } ], "orchestrator_signature": "...ed25519 base64...", "orchestrator_public_key": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----" }

To verify it, anyone can:

1. Strip orchestrator_public_key and orchestrator_signature from the body

2. Canonical-JSON the remainder (sorted keys, no insignificant whitespace, UTF-8)

3. Verify the signature against the embedded public key using ed25519

If anyone has tampered with any field — a result status, a proof_value, a rule_id — the signature breaks. There is no "trust me" step.

The engine is open-source MIT (https://github.com/defibabylon/rwa-attest), exposed via Model Context Protocol (https://modelcontextprotocol.io/) so any AI assistant can call it. It currently attests 8 RWA protocols across three dimensions — technical trust (contract structure + verifiable on-chain backing), market trust (track record), admin trust (access controls + governance) — scored 0-100. Every attestation is anchored on Base mainnet. Re-verify independently.

Here's what the first 8 found:

Superstate scores 0 on technical. That's Sequoia-backed, Bloomberg-listed Superstate. The score isn't a judgement of Superstate's integrity — it's a statement about what "verifiable" means. Our method requires on-chain-fetchable proof of backing that any independent party can re-derive. Superstate doesn't expose that. "Trust the issuer" and "verify the issuer" are not the same claim. A trust framework that can't distinguish them isn't a framework.

Maple scores 0 on market despite $2.1B TVL and a clean technical score. The 2022 defaults happened. The market trust dimension reflects that. Technical governance is sound — that distinction matters, and most scoring tools collapse it into a single number.

If you're an allocator or operator who needs verifiable trust attestation for a specific protocol — or wants a custom trust policy built against your specific risk lens — DM @defibabylon on X.

Tashoma Vilini is Founding Growth Lead at Liqwid Finance (https://liqwid.finance), a Cardano lending protocol that peaked at $81M organic TVL. This article is grounded in that experience: when you've sat across from institutional allocators trying to explain why your protocol's risk parameters are sound, "trust me" stops being viable fast.