That was the punch.

WHAT YOU BUILD WHEN THE TOOLS DON’T EXIST YET

Most growth operators in DeFi assume the analytics infrastructure exists first and they slot into it. That holds at Aave. It held at Uniswap circa 2021. It didn’t hold at Liqwid in 2023, and it doesn’t hold in most non-Ethereum ecosystems today. You build your own observation layer or you’re presenting allocators confidence intervals you can’t actually back up.

What started as a Python script and a Slack webhook — running every morning at 5:30 UTC because i needed to know what had shifted before i was caffeinated enough to find it myself — became defi-intel.

I published it as an MCP server. It’s live on Smithery.

WHAT IT ACTUALLY DOES

DefiLlama is brilliant. Everyone uses it. It has four core data tools. defi-intel has eleven, and the seven that aren’t in DefiLlama are the ones that matter most in an allocator conversation:

Governance proposals. Live voting state for the protocols you’re tracking. Not the TVL — the actual governance posture. Who’s proposing what, at what quorum, and what happens to the protocol’s risk parameters if it passes. I got blindsided by a Liqwid parameter vote once that i should have caught two days earlier. That doesn’t happen if you’re running governance signal.

RWA attestation scores. The defi-intel MCP integrates with rwa-attest directly — the same attestation engine i built to score BlackRock BUIDL, Superstate, and Maple on-chain. If you’re evaluating RWA collateral for a lending protocol or a fund allocation, you get verifiable scores, not vibes.

Live X/Twitter narrative. Via Grok x_search. Not sentiment analysis applied to day-old data. Live. The narrative velocity that precedes price action — in theory. In practice it's the signal that tells you whether the next week is noise or structure. I can't point to a Bloomberg story I beat just yet. But what i can tell you is that I stopped being surprised.

The one-call operator brief. This is the output format that doesn’t exist anywhere else: TVL + yields + stablecoins + governance + market narrative compiled into a single NotebookLM-ready document on demand. Your fund analyst reads it in four minutes. Your founder reads it before the board call. It’s the DeFi equivalent of a Bloomberg terminal morning brief, without the $24,000/year subscription.

THE PART I GOT WRONG

I thought the internal tool was the product.

It’s not.

The pattern is the product — the judgment about what to monitor, how to weight competing signals, and how to synthesise them into something a non-technical allocator can act on in a 15-minute meeting window. That judgment took two years of Cardano growth operations to calibrate.

I published it as an MCP because the barrier to building your own version is real — Dune still doesn’t have every protocol, xAI’s x_search requires a live API key the DeFi analytics world hasn’t caught up to yet, and the governance data infrastructure for anything outside Ethereum is still fragmented. defi-intel is a one-install solution for researchers, protocol contributors, and fund analysts who need operator-grade DeFi intelligence without building the stack themselves.

It runs on no enterprise subscription. It costs the compute you’re already paying.

Install it on Smithery: smithery.ai/servers/defibabylon/defi-intel

Full tool list and self-host instructions at github.com/defibabylon/defi-intel

That was the problem I built this to solve.

THE PROBLEM — scoring without attestation produces opinion, not evidence

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.

FOUR PROPERTIES — all enforceable in code, none optional

1. The policy is signed and versioned

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.

2. Each proof is signed by the agent that produced it

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.

3. The orchestrator signs the assembly, and the chain is tamper-evident

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.

4. Differential re-attestation, not just snapshotting

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.

WHAT THIS LOOKS LIKE — an actual signed attestation for BlackRock BUIDL

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 COMPARISON — what changes when attestation is cryptographic

WHERE THIS IS GOING — and what the first 8 scores found

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.

About the author

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.