Crypto Due Diligence Checklist: A Live Lido Protocol Walkthrough

Locate and verify the deployed source

Start with the contract a user actually calls, not a repository homepage. Lido's deployment registry identifies Ethereum chain ID 1 as active and maintained. It gives the stETH and Lido proxy as 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84 and the StakingRouter proxy as 0xFdDf38947aFB03C621C71b06C9C70bce73f12999. We retrieved the registry and the chain data on September 4, 2026.

A verified proxy is only the first address. Its fallback executes code at an implementation address, so open the proxy view and resolve that target. The live stETH proxy points to 0x028271E30a695c0527A0C50cA30603feD004cDb0. The live StakingRouter points to 0xDD76927045435C7605cf6f5F978cfb8CABDb5F80. Both match the protocol registry, and Etherscan labels each implementation's source an exact match. Etherscan defines that result as source plus compiler settings reproducing the deployment conditions. It proves reproducibility of the displayed code, not its safety.

Next connect the implementation to the report. StateMind names final reviewed commit af095e48bbc1c3841c2c9936219c8461af01056b and states that deployed bytecode for each contract within its audited scope matched the build from that commit. That sentence is stronger than a project's unsupported audit claim because it joins a bounded report scope to deployed code. The boundary matters: the current LidoLocator implementation in the registry differs from the Locator address in the report's validated list. We can carry the match only across the addresses and contracts the report names.

1. Discover the protocol.
2. Record its official deployment registry with the chain and retrieval date.
3. At a saved block number, read both the live proxy target and its admin directly from chain data.
4. Verify the implementation source, since a verified proxy shell is not enough.
5. Match the implementation to a commit inside the report's stated scope. Preserve the report's exact scope wording.
6. Identify the contract or account that can exercise each privileged role now.
7. Stop on an evidence gap.

What 30 top protocol records actually expose

Discovery directories make useful starting lists. We tested how much of the evidence chain one current directory supplies before a reviewer leaves it. The result is a measurement of metadata availability, not a ranking of protocol security.

Method

Source

DefiLlama's public /protocols application programming interface (API)

Run date

September 4, 2026

Population rule

Require a URL and finite positive total value locked (TVL), exclude category labels exactly equal to CEX, Chain or Bridge, sort by TVL and take 30

Fields tested

Usable address, nonzero audits, nonempty audit_links, nonempty github and their intersection

Link check

Request all 19 audit URLs and count an HTTP 2xx response as reachable

Repository artifacts

seo/research/due-diligence-artifact-survey.py and seo/research/due-diligence-artifact-survey-2026-09-04.json, kept in the repository but not served on the site

Results

One address value was the literal string null, so it did not count as usable. The 16 records with links supplied 19 URLs. Seventeen returned HTTP 2xx, one Morpho URL returned 404 and security.makerdao.com failed domain name resolution during the run. Availability is the lowest bar. A reachable PDF may be old, unrelated to the live implementation or limited to a small component.

Limits

• An address may name only a governance token.
• The survey does not interpret DefiLlama's audits indicator or treat it as a report count.
• A missing GitHub field says nothing about whether a public repository exists elsewhere.
• HTTP 2xx proves retrieval in this run. It does not establish audit coverage, freshness or quality.
• TVL ordering changes. Exact category matching also leaves Canonical Bridge records eligible for comparison with earlier project surveys.

Read the audit report's findings table

The StateMind report covers work from March 17 through July 1, 2026. Its summary shows zero Critical, High or Medium findings and 45 Informational findings. Of those 45, 33 are Fixed and 12 are Acknowledged. Informational is a severity, while Acknowledged is a response status. Calling all 45 fixed would change the report.

MixBytes's Medium finding is the decision-relevant exception. It says EasyTrack factory changes are enacted independently of the Dual Governance upgrade. If the Dual Governance half is vetoed or stalls, the factory state can diverge from the live protocol and requires a follow-up governance action. The Acknowledged status means the item remains unresolved or was accepted without a code change under the report's definitions. It does not mean Fixed, and it does not mean harmless.

Read the disclaimer too. MixBytes does not present the report as a warranty, endorsement, investment opinion or proof that the code is free of defects. Our audit report field guide explains why scope must be read apart from severity and status. The practical rule here is to retain the acknowledged governance path as a condition in the decision, even though the other report has no Medium findings.

Enumerate admin functions, multisig and timelock

Admin key is too vague to review. Write each function, its access role, the registry or account that holds that role and the final signer or voting path. Lido's control map says all protocol proxy admins are set to the Lido decentralized autonomous organization (DAO) Aragon Agent and that upgrades require a successful DAO vote. A direct chain read of the StakingRouter admin returned the same Agent address, 0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c.

Normal governance has a default 3 day timelock before a proposal becomes executable. Dual Governance Veto Signalling can block motions for 5 to 45 days. Record both values with the proposal path they govern. A timelock is delay, not prevention, and the MixBytes finding shows why a reviewer must look for execution routes outside the main path.

The emergency Safes are separate from the proxy owner. On the snapshot date, the Activation Committee Safe required 4 of 7 owners, the Execution Committee required 5 of 7 and the Reseal Committee required 5 of 6. The Safe API also returned no enabled modules and the zero address as guard for those accounts. That snapshot supports the threshold table for that day; it does not make the committees equivalent to the DAO Agent.

CircuitBreaker demonstrates the narrower authority. Lido documents that it can pause selected contracts but cannot resume them. It does not manage funds and has no proxy. Its initial mainnet pause duration is 21 days. List that as a bounded emergency control rather than claiming that the multisig can upgrade everything. Monitoring should watch role and Safe owner changes. It must also cover modules, guards and implementation slots. The smart contract monitoring guide turns those fields into concrete alerts.

Token privilege functions

Token review should begin with every path that can change supply, balances or transfer availability. Lido's own superuser guide says stETH supply can change only through a documented set of paths. That limit is testable: search verified implementation code for mint, burn, share and rebase operations, then compare the callers with the role map.

Normal stETH issuance is tied to ether submission, and tokens are burned when redeemed. Privileged share paths still matter because they can change the balance-to-backing relationship in protocol accounting. A due diligence note should state the function beside its caller and bound. Attributing all minting to the team is inaccurate when the actual path is a named contract under a ratio ceiling. Denying all minting is also inaccurate when the oracle path exists alongside VaultHub and module paths.

This is also where source verification becomes operational. If an implementation changes, rerun the search for supply-changing functions and compare the role assignments. A clean audit of the earlier commit cannot answer for a new function added later.

Liquidity locks and KYC claims

A checklist item can be inapplicable without being passed. A liquidity lock check is useful for a token launch where a team seeds a pool and holds the liquidity provider token. It is the wrong model for Lido's core stETH mechanism, where stETH is minted on ether submission and burned through a redemption path. No generic locker badge can prove that exit works.

Lido's WithdrawalQueueERC721 documentation calls that contract a main entry point for exchanging stETH for underlying ether. The public risk disclosure adds the constraints a locker check would hide: withdrawal depends on protocol liquidity and Ethereum validator exits, while a secondary market exit depends on market depth and expected slippage at the exit size. Those are the exit tests to record for this protocol shape.

Know your customer (KYC) claims need the same category test. Lido's risk disclosure says the Foundation has no custody, anti-money laundering or KYC role and assigns compliance duties to institutional users. Lido's website terms separately impose eligibility and geographic restrictions on its interface. Those statements can coexist: one concerns the Foundation's protocol role, while the other concerns use of a website. Neither proves that every on-chain caller was identified.

Which firm signed the report

Report provenance needs two directions. The protocol should publish the file, and the named firm should corroborate it on infrastructure the firm controls. Lido's audit repository contains the StateMind and MixBytes PDFs. StateMind's public-audits repository carries its own copy of the July 2026 report. MixBytes's audits_public repository carries its own copy of the upgrade review. The paired copies make a fabricated upload to one project account less plausible.

Then inspect what was signed. The StateMind cover names Lido Staking Router V3, and the report names the final commit and engagement dates. MixBytes identifies itself as a blockchain security firm specializing in decentralized protocols and smart contracts. A logo copied into a PDF is not this evidence. Our fake audit report investigation guide covers report provenance across the named domain and repository in detail.

Firm identity also supplies context, not a safety grade. Compare the report's scope and methods with the firm's published work, then read the actual findings. The Certora company analysis shows how we separate a firm's methods from a client's marketing claim, while the audit company analysis hub provides the broader comparison set.

Decision summary

The Lido walkthrough reaches a documented deployment, not a conclusion that the protocol is safe. The stETH and StakingRouter proxy targets match the official registry. Their implementations have verified source. StateMind connects its bounded deployed scope to an audited commit, and the public role map identifies the main governance and emergency paths.

The resulting disposition is proceed with documented residual risk and monitoring. Upgradeability through the DAO Agent remains. Privileged paths remain for oracle reports and external shares, including rebases. Emergency Safes are bounded but mutable, and the acknowledged MixBytes finding preserves a governance-path exception. Withdrawal capacity and secondary liquidity can change after this review.

Set a loss limit before turning that disposition into an investment. If an unresolved exception exceeds the limit, the checklist says stop. If the evidence is sufficient, save the addresses, block number, report commit, role holders and link responses so the next review can detect change rather than start from memory. Security disclosures should feed that rerun; our disclosure policy guide explains which records a mature program should preserve. Automated extraction can shorten the work, but the evidence rule still applies; the AI and blockchain security overview places that use beside the risks of model-produced output. The wider member directory can then help verify the firms behind future reports without substituting membership for evidence.