Distributed ledger technology is moving deeper into institutional operations. Financial institutions, market infrastructures, enterprises, and public-sector organizations are evaluating or deploying DLT systems for payments, settlement, asset issuance, data coordination, and other important workflows.
As these systems move beyond pilots, security can no longer be evaluated only by asking whether the code appears correct. Institutions also need to know what happens when the complete system is running: when demand increases, a node behaves unexpectedly, an external dependency slows down, or an upgrade changes the way resources are consumed.
A weakness that looks isolated at the component level can become a system-wide availability problem. Transactions may be delayed, critical services may be interrupted, and recovery may take longer than expected. For a financial institution or another regulated entity, this is not merely an engineering concern. It can become an operational resilience, governance, and service-continuity issue.
CertiK developed Chain Scan to connect code-level security analysis with evidence of how DLT systems behave under real operating challenges.
Connecting Code-Level Findings with Runtime Evidence
Code review remains an essential part of DLT security. It evaluates logic, implementation choices, and known classes of vulnerability. But code review alone does not reproduce every interaction that emerges when multiple nodes, infrastructure dependencies, network conditions, and real workloads come together.
Chain Scan complements code review through automated static scanning, analyst validation of candidate findings, and controlled runtime testing. Static scanning helps identify potentially risky code patterns in the selected codebase, while runtime testing evaluates system behavior in an isolated, production-representative environment under adversarial and failure conditions.
Chain Scan identifies code-level weaknesses and tests how selected failure scenarios affect availability, consistency, and recovery.
Before production, the agreed assessment may include static scanning, runtime testing, or both. After deployment, the relevant scans and tests can be repeated on an agreed schedule and after material changes.
How Chain Scan Works
Every Chain Scan engagement is tailored to the architecture, repository, release context, and security and operational risk profile of the DLT system, node, or client being evaluated. Static code scanning and controlled runtime testing provide complementary evidence, with coverage defined by the agreed scope.
First, CertiK and the organization define the assessment scope and agree on the applicable Scan Plan and Test Plan. The scope identifies the public repository, branch, commit or release, relevant forks and packages, and version context. The plan defines the operating risks, failure scenarios, expected behavior, evidence requirements, and success criteria for the target environment.
Where static code scanning is included in the agreed scope, CertiK prepares the pinned source code and runs automated static analysis using known vulnerability patterns and related code variants. The analysis covers the target repository and, where relevant, related DLT clients, forks, and releases. CertiK analysts then assess candidate findings for severity and context, trace exact code locations, confirm exploitability, and remove false positives or duplicates.
Where runtime testing is included in the agreed scope, CertiK recreates the relevant production configuration in an isolated, representative environment, including multiple nodes, network topology, infrastructure services, and dependencies as needed. Chain Scan simulates heavy demand, component failures, dependency problems, abnormal network behavior, and operational changes. Tests establish normal behavior, introduce the selected condition, and observe the system afterward.
Finally, CertiK measures whether the system remains correct and available, how failures spread or remain contained, whether failover mechanisms work, and how quickly normal operation is restored. Validated code-level findings and reproduced runtime findings are documented with affected versions, evidence, and remediation guidance. Fixes can be verified through follow-up rescans and runtime retesting. In this context, continuous assurance refers to scheduled and change-triggered rescanning and retesting of the agreed scope.
The runtime-testing component of Chain Scan uses an isolated, production-representative environment to evaluate system behavior and support remediation and retesting. Static code scanning and analyst validation complement this workflow.
Depending on the agreed scope, runtime testing coverage can include:
- Consensus, timing, finality, and liveness
- Peer-to-peer networking and distributed messaging
- Compute, memory, storage, and resource-exhaustion behavior
- Cross-node consistency and deterministic execution
- RPC and external-service dependencies
- Infrastructure, topology, and network resilience
- Failover, recovery, and degraded-mode behavior
- Protocol upgrades, configuration changes, and mixed-version environments
The following examples illustrate complementary parts of this approach: controlled runtime fault testing in Besu, and automated code scanning with analyst validation in go-ethereum.
Evidence in Practice: Independent Research on Besu
Hyperledger Besu is an Ethereum client used across public and permissioned DLT environments, making it a relevant example for organizations assessing enterprise-grade distributed infrastructure.
Using Chain Scan, CertiK independently deployed a private multi-node Besu environment and applied adversarial fault scenarios across peer-to-peer, HTTP RPC, and WebSocket RPC surfaces. The research identified five high-severity availability vulnerabilities documented across four official security advisories. The issues were addressed in Besu 26.7.1. This was independent proactive research, not a client engagement. CertiK’s Besu research and the Besu 26.7.1 security release provide the public record.
In one scenario, a single peer could repeatedly trigger unbounded block-fetching work. When the condition was directed across enough validators in the tested topology, it could stall consensus. In another, oversized future proposals could exhaust memory and halt the commit quorum in a four-validator QBFT environment. Besu’s published advisories document the conditions and mitigations for the repeated block-fetch issue and the future-message buffer issue.
A system does not need to suffer asset theft or a cryptographic failure for the operational consequences to be serious. A resource-handling weakness at one point in the architecture can affect whether the wider service remains available.
Reproducible test harnesses helped the Besu team validate faults and confirm fixes, while creating a foundation for regression testing against later releases.
Evidence in Practice: Contributions to EVM communities
go-ethereum is a widely used Ethereum execution client supporting core L1 transaction, state, and RPC paths, making it a relevant demonstration of CertiK’s blockchain infrastructure expertise. CertiK’s broader public Ethereum research also spans mainstream clients including reth/revm, Erigon, Nethermind, and Besu.
Using Chain Scan, CertiK applied automated scanning to a pinned go-ethereum codebase and then had security analysts validate the candidate findings. The research identified several issues accepted by the go-ethereum community, with several follow-up pull requests merged upstream. The public record includes issue #31626, issue #32181, issue #32221, and issue #32935, together with PR #32222, PR #32794, and PR #32934. This was independent proactive research, not a client engagement.
The findings covered indexing behavior involving the Price slice and oracle.percentile, missing nil-pointer protection in scwallet and eth/downloader, subscription cleanup when errors occur, and incorrect numeric bounds in ImportHistory. The merged changes added defensive checks, improved cleanup behavior, and corrected the uint64 value used during receipt chain insertion.
Confirmed patterns can be reused in automated scans across related EVM clients, forks, and releases. CertiK’s public Ethereum research further includes a #3 ranking in the January 2025 ETH Attackathon with 20 valid reports across three client groups, followed by 15 valid reports across four clients in the September 2025 ETH Fusaka Upgrade Contest.
From Assessment to Continuous Assurance
A Chain Scan engagement establishes a version-specific security baseline and produces evidence for engineering, security, risk, and oversight teams. Static scan results and runtime test evidence provide a scoped record of the code and environment assessed, the conditions evaluated, identified weaknesses, and whether remediation was effective.
Depending on scope, deliverables can include:
- Scan and Test Plans aligned to the repository, release scope, architecture, and risk priorities
- Baseline and checkpoint reports with validated findings, affected versions, and coverage details
- Runtime execution results supported by logs, metrics, visualizations, and PASS/FAIL conclusions against agreed success criteria
- Delta reports covering new, open, resolved, and changed findings
- Remediation recommendations and verification of implemented fixes
- Reusable scan configurations, test environments or testing tools, and an agreed checkpoint and regression-testing schedule
These deliverables answer more than “Was the code scanned?” or “Was the system tested?” They show what changed since the previous checkpoint, which risks require action, how the system responded to disruption, and when assessment should be repeated.
Scheduled and change-triggered rescans and retesting matter because both codebases and operating environments evolve. New commits, releases, forks, protocol upgrades, dependencies, infrastructure, network participation, and configuration changes can introduce new risk or change the relevance of earlier findings. Evidence gathered before launch may no longer describe the system after a major upgrade.
At each static scanning checkpoint, Chain Scan rescans the full agreed scope, while commit changes guide comparison, prioritization, and reporting. For runtime assurance, CertiK recreates the relevant environment and reruns defined scenarios on an agreed schedule and after material changes.
Rather than accumulating all changes into one large review at the end of a development cycle, recurring scans and retests provide smaller review checkpoints and earlier feedback. Comparing results across versions and rerunning defined scenarios helps organizations maintain evidence that remains relevant as the system evolves.
Supporting Operational Resilience and ICT Risk Management
Financial institutions and other regulated entities already manage technology through the language of critical operations, business continuity, ICT risk, change assurance, control effectiveness, and recovery. Chain Scan connects code-level security findings and runtime test evidence to these established responsibilities.
The Basel Committee’s operational resilience principles emphasize the ability of banks to continue delivering critical operations through disruption, supported by severe-but-plausible testing and resilient ICT. The EU’s Digital Operational Resilience Act similarly places testing, remediation, and validation within a broader ICT risk-management program. These frameworks illustrate why evidence of system response and recovery matters to institutional governance. They do not make any single testing service a complete compliance program. Basel operational resilience principles and DORA Articles 24–25 provide the relevant context.
Chain Scan can provide repeatable technical evidence that supports an institution’s broader operational resilience and ICT risk-management program. It does not constitute regulatory approval or certification, replace legal or compliance review, or guarantee that every risk will be discovered.
Its value is more concrete: technology, risk, and oversight teams gain a clearer record of how a DLT system responds to disruption, whether identified weaknesses have been remediated, and whether resilience remains intact after upgrades and configuration changes.
Build Code and Runtime Assurance Into the DLT Lifecycle
For organizations relying on DLT infrastructure, confidence in code is necessary but incomplete. Institutions also need evidence that the system behaves as expected when real operating conditions challenge its assumptions.
Chain Scan supports the DLT lifecycle through scoped code scanning, runtime testing in isolated environments, and scheduled or change-triggered reassessment. These activities help organizations identify weaknesses, verify remediation, and maintain relevant security and resilience evidence as code and deployments evolve.
Contact CertiK at [email protected] to schedule a Chain Scan scoping session covering your target codebase, release context, and operational risk priorities.
