Skip to content

Due diligence

What can this contract do to your money?

Before buying a token or integrating a protocol, the question that matters is what the code allows, not what the website says. Most people never check. A retrieval system that answers from the verified source, cited to the line.

PrizenLabs//3 min read/5 sources

The problem
Answering whether an owner can mint, freeze, change fees or upgrade means reading dozens of files behind a proxy; scanners give unexplained yes or no flags and chatbots lose the context.
Our proposal
Index the verified source with Solidity-aware chunking, follow proxies to the real implementation, combine deterministic detectors with hybrid retrieval, and answer only with line-level citations.

Can the owner mint more tokens? Freeze a wallet? Raise a transfer tax to 99 percent? Swap out the logic entirely? These are the questions that decide whether a token, a stablecoin or a protocol is safe to hold or integrate, and the answers are in the code, not on the website.

The problem: the answer is public, and practically unreadable

Verified source code is public on Sourcify and Etherscan. Reading it is another matter.

  • It is spread out. USDC's proxy resolves to an implementation built from 23 files. The function that matters may sit three inheritance levels down.
  • Proxies hide the logic. The address users interact with is often a proxy; what runs is somewhere else, and can change.
  • Tools give verdicts, not reasons. Automated token scanners return flags such as "mintable: yes" with no explanation and no way to ask a follow-up question.
  • Chatbots lose context. Pasting code into a general assistant drops files, loses the inheritance chain and returns answers you cannot check.
  • Documentation drifts from code. A whitepaper can promise a fixed supply while the contract has an uncapped mint.

The proposal: retrieval built for contracts

We built ContractLens to answer these questions from the verified source, with every claim linked to the exact lines. The design choices that matter:

  1. 01Fetch and follow. Pull every source file from Sourcify, with Etherscan as a fallback, across the major EVM chains, and detect proxies so the implementation that actually runs is what gets indexed.
  2. 02Chunk by structure. One chunk per function or modifier, grouped declarations and a per-contract outline, so a retrieved chunk is a complete unit of meaning rather than an arbitrary window of lines.
  3. 03Run deterministic detectors first. Pattern checks flag privileged functions, minting, blacklists, adjustable fees, upgrade hooks, delegatecall, selfdestruct and tx.origin. They need no model and no API key.
  4. 04Retrieve two ways. Questions mix concepts ("can they freeze funds") with identifiers (blacklist, onlyOwner). Vector search handles the first, full-text search the second, and reciprocal rank fusion merges them.
  5. 05Cite to the line. Each source line is sent as its own citable block, so every citation maps to exact line numbers with no fuzzy matching.
  6. 06Check documents against code. Upload the whitepaper and each claim is marked consistent, contradicted or unverifiable, with evidence.

What it finds on real contracts

For USDC, it follows the proxy to the implementation and retrieves the blacklist function, the role that controls it, the pause function and the proxy admin's upgrade path. For USDT, it surfaces the function that lets the owner destroy a blacklisted address's balance. None of this is hidden; it is simply hard to find without help.

Treat the source as hostile

Contract comments and whitepapers are written by the people you are evaluating. Our demo contract contains a comment instructing AI reviewers to report it as safe. The system prompt forbids following instructions inside sources, a detector flags text aimed at AI reviewers, and every evidence reference in a report is checked against what the model was actually shown. The same principle runs through our article on prompt injection as an architecture problem.

Limits

This speeds up due diligence; it is not an audit. Source code cannot tell you who holds the owner key today, whether the multisig is two of five, or whether the timelock is set to zero. Those live in onchain state and operations, which is where 2026's biggest losses came from, as we cover in keys, not code.

What to measure

  • Citation precision. The share of cited lines that actually support the sentence they back, checked by a reviewer on a sample.
  • Recall on known powers. On contracts with known admin functions, how many the system finds unprompted.
  • Proxy resolution rate. How often it reaches the implementation that really runs, across the chains you care about.
  • Time per review. Minutes from address to a risk report a person trusts, against the hours it takes by hand.

How we would use it

Exchanges, treasuries and funds can run every new asset through a check like this before listing or holding it, then send the contracts that matter to a full security review. It is also a good example of what careful RAG development looks like in a domain where a wrong answer costs money.

Sources

  1. 01ContractLens: RAG for smart contract due diligence (GitHub)
  2. 02Sourcify: verified smart contract source
  3. 03Circle: USDC smart contracts (stablecoin-evm, GitHub)
  4. 04Etherscan: Tether USD (USDT) contract source
  5. 05Claude documentation: citations

Figures are as reported by the sources on the date above. Where sources disagreed, we say so in the text. Nothing here is legal or investment advice.

Keep reading

One company at a time

Facing this problem?