Institutional DeFi risk research, checked on-chain.
Professional risk assessment and continuous monitoring of DeFi protocols for investment funds, asset managers, custodians and other financial institutions, sold as corporate licences, an API and integration into their risk systems.
We check what actually runs: deployed code against its audits, with the unaudited parts reviewed by us. DeFi specialists set the method; several frontier AI models read each protocol at a depth no human team can reach. No one did this before us.
Test stand: test.defi-research.com (opens in a new tab)
What it is and how it earns
A risk research and data service for financial institutions. Corporate licences, the API and integration bring recurring revenue; per-protocol reports are the entry point; the free public catalogue builds trust and brings leads. Paid reports and subscriptions for active DeFi users add a second revenue line.
-
Corporate licences
3 tiers annual licences for institutions- Team: reports and alerts for a small fund.
- Institutional: API, continuous monitoring, integration into risk systems.
- Enterprise: custom coverage, an SLA, a dedicated or on-premises deployment.
-
Per-protocol reports
$2+ per protocol, one price for all- A report on any protocol, ordered when needed.
- The entry point before a licence.
-
Free public catalogue
100 protocols, free to read- Top 50 open to everyone; next 50 free with registration.
- Builds trust in the method and brings institutional leads; active DeFi users who read it buy reports and subscriptions.
Where this goes next: Roadmap.
Why the product matters
Four reasons: the deployed-code check, the data we collect, anti-slop controls, depth and coverage.
Audits checked against deployed code
UniqueAn audit describes the code that was reviewed. We check the code that is deployed today.
- Fixed and verified
Audit findings confirmed fixed in the live code.
- Outdated
Audits that no longer match, because the code changed after them.
- Not covered
Deployed code no audit covers, weighted by criticality. We review it ourselves.
How the check works
Audit findings are grouped and re-checked against the deployed code, up to 50 open findings per protocol. Each contract is matched to its verified source on the chain where it runs.
Data we collect
Collected before analysis starts. Items marked On-chain check use contracts and balances read on-chain, plus measured market, governance and L2 data. Even official sites and trusted aggregators are sometimes out of date or wrong, so we check the facts that matter against the deployed contracts and say in the report where a stated value differs. Direct on-chain reads of multisig signers and timelocks are still being added.
Measured, not taken on trust.
-
Every contract matched to its source on its own chain On-chain check
How
Deployed bytecode is matched to its source through Sourcify, on the network where the contract runs, and the deployment date is recorded. Addresses come from the protocol's docs and repositories; a block explorer is the fallback when Sourcify has no match.
-
Admin keys: who can pause, upgrade, mint or move user funds On-chain check
How it is rated
We record who holds each key: a multisig, a timelock or a single address. Sources are DeFiScan permission reviews where available, audit findings on privileged roles and the docs, checked against the deployed contracts. If one key or a two-signature multisig can move user funds without delay, the overall rating is capped.
-
Risk of underlying protocols flows into the score On-chain check
How the dependency graph works
From the token composition behind the project's deposits (DefiLlama data) and our own scores of the protocols that issue those tokens. If a material share rests on a protocol we rate weak, the dependency score is capped.
-
Vote concentration and L2 maturity, measured On-chain check
What is measured
The top-10 voter share over the last five proposals, read from Governor contracts on-chain or from Snapshot, and quorum where the contract exposes it. L2 maturity comes from L2BEAT, for each chain that holds a material share of deposits.
-
Exit liquidity, depegs and yield spirals in numbers On-chain check
What is measured
- Exit liquidity: how much of the deposit token sells within 2% price impact, from DEX route quotes.
- Depegs: four years of daily prices of the protocol's own tokens.
- Yield spirals: whether returns loop through the protocol's own token.
-
Compensation funds read on-chain, not from the docs On-chain check
How a fund counts
By its balance relative to deposits, by how it pays out (automatic, pausable or by vote) and by its payout history.
-
15,000+ audits from 150+ firms in one base
Processing
Each audit is linked to its protocol, and auditors are tiered by reputation. Junk and automated scans are filtered out. Findings are extracted with their severity and status, ready to be checked against the code.
-
Docs, GitHub, ranked articles and a year of Reddit and YouTube
Sources
The protocol's site, docs and GitHub; articles ranked by reliability; a web search with source checks; Reddit and YouTube over the last 12 months for incidents and complaints. Research reports, including Blockworks (ex-Messari). Aggregator ratings such as DeFiSafety, CertiK and DeFiScan count as supporting evidence only.
Anti-slop
How wrong AI output is kept out of a report.
No match, no fact.
-
Author and reviewer from different model families
How models are chosen
One frontier model writes each step; a model from another family reviews it and can send it back. A step ends only when it is accepted or stopped. Models are picked by blind A/B tests with an independent judge.
-
Every quote checked by code against the stored source
How
Each claim carries an exact quote. Code looks it up in the stored copy of the source and rejects the claim if the quote is not there.
-
Scores are arithmetic: same inputs, same score
How
The model picks a level from quoted evidence; code computes the score with a versioned rubric.
-
Weak sources cannot set a rating; missing data stays a gap
How
A forum post or an unknown blog cannot support a level on its own. Missing data is shown as a gap, not filled with a guess.
-
A person decides when a source cannot be reached
How
The decision is recorded with its reason. Gaps are never hidden.
Depth, coverage and plain language
-
18
factors in 5 risk dimensions
Which
Code security, economic security, governance, team transparency and track record, plus a cross-analysis of risks at the seams: dependencies, bridges, oracles.
-
5,500+
protocols we can analyse: no ceiling
Compared with others
Teams that do real analysis, not just automated scripts, cover up to about 200 protocols.
-
3 lines
and a colour rating for a quick read
Then
The full analysis with sources follows for professionals, in the reader's language, with graphics instead of walls of text.
Competitors and us
The two common ways to rate DeFi risk today, next to ours. Open “Examples” to see who works each way.
- Strength
- Acceptable
- Weakness
| Criterion | defi-research.com |
Automatic scores
|
Manual reviews
|
|---|---|---|---|
| Who reads the protocol | Strength: Deep research by several frontier AI models, checked by DeFi specialists and supplemented with all existing audits and articles | Weakness: Formulas over metrics and scans | Acceptable: Specialists, by hand |
| Audits checked against deployed code | Strength: Yes | Weakness: No | Weakness: No |
| Protocols covered | Strength: No ceiling: 5,500+ protocols with TVL can be analysed | Strength: Broad | Weakness: Up to about 200 |
| Where the score comes from | Strength: A versioned rubric over quoted evidence; code does the arithmetic | Weakness: A formula over metrics | Acceptable: Analyst judgement |
| Evidence behind a rating | Strength: An exact quote for every claim, matched by code against the stored source | Weakness: The input metrics | Acceptable: The analyst's write-up |
| Updates | Strength: By event: a new deployment, a new audit | Strength: Automatic re-run | Weakness: A new manual review |
| Cost of one report | Acceptable: Model tokens plus small API fees | Strength: Low | Weakness: Specialist time |
Examples are named for orientation. Each column describes the approach in general, not every provider in it.
Why institutions will buy
Funds, asset managers, custodians, DAO treasuries, insurers and vault curators that hold or plan DeFi positions need professional risk assessment and continuous monitoring. We serve the jobs they already do; annual licences give a higher average contract and regular revenue. Active DeFi users who come to the free catalogue add a second, smaller line: paid reports and subscriptions.
-
Due diligence before entering a protocol
What they get
A full report on any protocol, ordered when needed: deployed code checked against audits, admin keys, dependencies, exit liquidity, governance. Every claim is quoted from its source, ready for the investment memo.
-
Continuous risk monitoring with alerts
How
Reports are refreshed by event, such as a new deployment or a new audit. A client is alerted when the risk of a protocol it holds or depends on changes.
-
Integration into risk-management systems
How
Scores, factors and evidence come as data through the API, so risk systems, dashboards and AI agents read them directly instead of copying from documents.
-
Limits, allocation committees and reporting
Why it fits
Scores are arithmetic from a versioned rubric: the same inputs give the same score, a consistent basis for exposure limits per protocol. Quotes and sources behind every rating can be cited in committee papers and in reports to clients and boards.
-
Reasons to renew every year
Why would a client renew?
Protocols and the projects they depend on change all the time, and frequent security incidents can change the risk picture fast, so monitoring is a continuing need. We keep adding research methods, while stronger models keep improving research quality.
-
The free catalogue brings leads
How
100 protocols researched in depth and free to read show the method in public and build trust. Registration opens the next 50 protocols and turns readers from institutions into contacts for a licence. AI assistants that find and cite the reports widen the reach.
Why costs are low and development is fast
A development cycle built entirely on AI agents, with more reliable code
How it works
Agents plan, write, review and test the code. Reliability comes from structure: models from different vendors check each other, critical steps run as fixed workflows in code, and a product bug closes only after a test-stand run shows it fixed.
Orchestration
- A coordinator agent runs the cycle from a task board: it splits work into tasks, starts author–reviewer pairs and merges the results.
- Each task runs in its own isolated git worktree; tasks run in parallel within per-engine limits.
- Shared resources (the full test suite, the test stack, golden evals) are guarded by locks.
- A watchdog restarts stalled waits and starts the next queued task, so capacity stays busy.
Cross-model review
- Every change is written by one model and reviewed by a model from another vendor: OpenAI GPT writes code and Anthropic Claude reviews it; for plans and research the roles swap.
- Reasoning effort is set by risk: higher for security, money, concurrency and migrations.
- The reviewer follows a review spec for the task and returns findings with severity, confidence and a verdict; up to 3 fix rounds.
- A third model breaks ties. Reviewers also flag unneeded complexity.
Deterministic flows where it matters
- Review, bug-fix (with a research step) and task-plan cycles are state machines in code, not free-form chat: fixed steps, round limits, decision points.
- They resume where they stopped after a restart.
- Every commit passes a scripted gate: rebase on the shared branch, affected tests, secret scan. Any failure stops it. Only the coordinator commits.
- Test-stand runs follow one scripted path with start checks: one try, no blind retries.
Plans before risky code
- Cross-component seams, concurrency, migrations, security, money and large tasks start with a plan that fixes contracts: signatures, data, owner.
- The other model reviews the plan. Small tasks and bugs go straight to code.
Memory and context
- Agents start from self-contained task files with the goal, constraints and binding decisions copied in, not from long chats.
- Durable memory lives in files: owner decisions (verbatim, dated), handoff notes, the board, a worklog, a log of every model A/B test, and the coordinator's rules.
- After context compaction the coordinator re-reads its rules before acting; the summary must list every live cycle and its next decision.
- Sub-agents are forked only while context is small; otherwise a fresh agent gets a short brief.
Proven on test stands
- Two test stands run the real pipeline end to end on real protocols.
- Every run is triaged by a template: stages, errors, data completeness, alerts, time and tokens.
- Every product bug is tracked and closes only when a stand run shows it fixed, not at commit.
- Fixes ship together in one build; the stands are never left idle.
Measured, not assumed
- Model choices are backed by recorded A/B runs.
- Spend is tracked against the result of each stand run; an expensive path that keeps failing is stopped and changed.
Autonomy on a short leash
- The person sets direction and priorities, decides open questions, holds the secrets and approves production rollout, done by hand from a runbook.
- Everything else, including approving task plans after agent review, runs without waiting for a person.
- In production an operations agent is the first line, a coordinator agent the second, the person the third.
-
Plain code wherever code is enough
Where
Parsing, quote checks, on-chain reads and scoring run as code, with no model tokens.
-
Low-cost models collect, frontier models analyse
Why
Expensive models are used only where depth pays off: the deep analysis and the review.
-
Each step gets only the files it needs
Why
A step reads digests, a findings ledger and the relevant code, not everything. Fewer tokens, better answers.
-
Updates by event, not full re-runs
How
A report is refreshed by events, such as a new deployment or a new audit.
-
A run costs model tokens plus small API fees
Exact figure
The measured figure comes from our test stand.
How it works
Four stages from raw sources to a published report.
-
1
Collect
Deterministic code and low-cost modelsAudits, docs, code, articles and on-chain data, cross-checked.
What is collected
- Audit reports from the sites of 150+ audit firms, with their findings and fix status.
- Articles and research reports, including the Blockworks archive, and posts on X, Reddit and YouTube, ranked by source reliability.
- The protocol's site, docs, governance forum and GitHub.
- Contract addresses on every chain, verified source code (Etherscan, Sourcify) and contract creation dates.
- Deployed code compared with GitHub and with the audited commits; how much of the code the audits cover.
- Dependencies: backing assets, oracles, issuers and the chains the protocol runs on, with their own scores.
- Governance: voting venues (Snapshot, on-chain Governor) and how concentrated the votes are.
- Market data: TVL and its history, token composition, depeg history and DEX exit depth.
- Chain risk: rollup stage and exit window (L2BEAT).
- Incidents, and loss-cover funds: their balances and whether they are paused.
- Multisig signers and timelocks from docs and audits; direct on-chain reads in progress.
-
2
The Brain
Frontier models, author and reviewerEight steps, each with an author and a reviewer from another model family.
-
3
Inside one step
Shown for a complex protocolDrafts, code checks and review rounds; the score comes from code.
-
4
Translate and publish
Any language, on the site and through the APICode checks that numbers, names and addresses survive translation.
Roadmap
Six steps, each built on the previous ones: from free research to zero-trust capital placement for institutions.
-
1
Step 1. Research on 100 protocols
In production: November 2026All open and many closed sources, every audit and on-chain data, for 100 protocols: the top 50 open to everyone, the next 50 for registered users. Public coverage, feedback, trust in the method and first institutional contacts.
-
2
Step 2. Any protocol, corporate licences, API
In production: December 2026Step 1 plus any protocol on request, from $2 per protocol, subscriptions for active DeFi users, and corporate licences for institutions: monitoring, alerts, data through the API and integration. Tiers are set mainly by the number of protocols covered and the level of integration.
-
3
Step 3. Full audits by our system
In production: February–April 2027Paid audits ordered from us: on top of the collected data, a swarm of strong agents audits the whole system. The results can exceed those of audit firms.
-
4
Step 4. Safety of a specific position
In production: March–May 2027Projects split into assets (stablecoins, other tokens), protocols and chains, and protocols into their vaults and pools. Safety is scored for a specific placement of funds, not only for a project: an institutional feature that rates each position in a fund's or custodian's portfolio.
-
5
Step 5. Yield data
In production: May–July 2027Expected or exact yield of a specific DeFi placement over a given term.
-
6
Step 6. Zero-trust capital placement
In production: July–September 2027Built on Steps 4 and 5, an institutional feature: a client's funds placed and moved very fast. Transactions are calculated and built server-side, then checked on the client's side by deterministic checks and, if the client wants, by its own agents.