Blockchain Protocol and Security Analysis Methodology

Release: Version 3.0

---

Document

Field	Description
Creators	Hacken OU
Subject	audit; security analysis; layer 1; layer 2
Description	The methodology described herein provides specific guidance on how to plan and execute an audit of Layer 1/Layer 2 protocols developed by the Hacken OU. This document will enable everyone to get an understanding of an audit and realize how to be prepared for this process.
Author	Nino Lipartiia | L1 Audits Technical Lead, Hacken OU
Contributor	Tanuj Soni | Senior L1 Auditor, Hacken OU
Contributor	Bartosz Barwikowski | L1 Researcher and Auditor, Hacken OU
Date	October 15th, 2025
Rights	Hacken OU

---

Part 1. Background to the Layer 1 Protocol Audit and Analysis

Overview

The Blockchain Protocol and Security Analysis Methodology has been developed in response to Hacken’s customers’ needs and is grounded in years of experience auditing blockchain protocols. This document aims to provide Hacken’s customers and the broader community with a clear understanding of the audit process and its deliverables, helping enhance the quality of Layer 1 and Layer 2 development while mitigating risks of malicious attacks, fund loss, and network compromise.

How Does the Audit Help?

A blockchain protocol audit helps ensure the long-term security, stability, and reliability of the network by identifying design flaws, implementation errors, and potential attack vectors before they can be exploited. It provides developers with clear, actionable insights to strengthen protocol resilience, improve code quality, and address security gaps, while giving stakeholders assurance that the system aligns with industry best practices and is built on a secure and reliable foundation.

Alignment with International Standards

Hacken performs all audits and technical assessments in accordance with the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment and the Penetration Testing Execution Standard (PTES). These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Part 2. Blockchain Protocol Audit and Analysis Phases

Layer 1/Layer 2 Blockchain Protocol Audit and Analysis process consist of the following phases:

1. Preparations for the audit (Onboarding)
2. Code review and testing
3. Reporting
4. Remediation check

Preparations for Layer 1/Layer 2 Audit

Before the audit, clients should review their projects to ensure all planned features and functionalities are correctly implemented. This internal review helps identify and resolve basic issues in advance, saving auditors’ time and allowing them to focus on deeper security analysis. As a result, the audit becomes more efficient, targeted, and yields higher-quality outcomes.

Functional Requirements

Providing clear functional requirements is essential to understand the customer’s objectives and to ensure that the project is developed according to plan. The primary objective is to clearly define the goals and expected outcomes of the new protocol.

Functional requirements should be clear, simple, and unambiguous, outlining all expected behaviors and characteristics of the system. They should cover:

• Core functionality – what the system is expected to do;
• Performance requirements – expected throughput, latency, and scalability;
• Security features – mechanisms that ensure data integrity, confidentiality, and fault tolerance;
• Usability – how users or other systems will interact with the protocol;
• Compatibility – integration with other systems, networks, or protocols.

Technical Description

A detailed and comprehensive overview of the project’s technical aspects and requirements is essential. This section should include clear and well-structured information covering the following points:

• Architecture overview – a general outline of the system structure and component relationships.
• Technologies used – programming languages, frameworks, libraries, and tools employed in the implementation.
• Unique elements – any non-standard components, functionalities, algorithms, or design approaches.
• Security model – security assumptions, trust model, validator design (permissioned or permissionless), validator lifecycle, administrative entities and their permissions, integrated precompiles, and other relevant aspects.
• Deployment details – local node setup and network deployment instructions.
• Testing procedures – guidance on running unit, integration, fuzzing, and other relevant tests.
• Component implementation – high-level description of each component’s functionality and notable implementation details.
• System diagrams – visual representations of components and their interactions.
• Design rationale – analysis of design advantages and limitations, along with the motivation behind key architectural decisions.

Documentation for Local Setup and Execution

The Customer is responsible for configuring a functional development environment for the project. Comprehensive documentation detailing how to build, run, and operate the network locally is required to ensure the audit can be conducted effectively.

Comprehensive Test Cases

Comprehensive test cases are essential to demonstrate and verify the intended behavior of the blockchain protocol under both normal and edge-case conditions. Well-structured test coverage helps validate consensus logic, networking, state transitions, and other critical components.

By providing these test cases, clients:

• Offer auditors complete visibility into the expected protocol behavior and design assumptions.
• Facilitate the identification of untested paths, edge cases, and potential security vulnerabilities.
• Clarify the intended operation of complex modules, allowing auditors to focus on areas of the highest risk.
• Enhance audit efficiency by minimizing ambiguity and enabling deeper, more targeted security analysis.
• Assist auditors in implementing additional or custom tests when necessary, ensuring thorough verification of security-critical logic.

Code Style and Best Practices

We strongly recommend adhering to official code style guidelines and properly formatting the code before submitting it for audit.

• Ensure the code follows the official style guide of the respective programming language.
• Verify that the entire codebase builds and runs successfully without compilation or linter warnings.
• Resolve all TODO and FIXME comments prior to submission, ensuring no unfinished or temporary code remains.

The Audit Lifecycle

1. Onboarding

During the onboarding stage, auditors collect and review all materials provided by the customer — including the protocol design documentation, whitepapers, in-code and on-site documentation, and any other relevant resources. This process ensures a thorough understanding of the protocol’s functional requirements, business logic, and security assumptions.

The customer must provide these materials, along with the complete codebase and the specific commit hash to be audited, prior to the audit kick-off. Any additions or modifications to the audit scope will not be accepted once the onboarding phase has commenced.

2. Code Review and Testing

This main audit phase encompasses manual line-by-line code review, static analysis, and dynamic end-to-end testing. Together, these methods ensure comprehensive coverage of the protocol’s logic, implementation, and runtime behavior.

2.1 Manual Line-by-Line Code Review

This is the core of the audit process and aims to ensure that the implementation is secure, logically sound, and aligned with the intended protocol design. During this stage, auditors:

• Validate the logical correctness of all components and their adherence to the specified business logic.
• Ensure compliance with industry best practices and internal documentation.
• Identify subtle bugs, edge-case errors, inconsistencies in the implementation, or misuse of cryptographic primitives.
• Detect logging or data-leak vulnerabilities and unsafe error handling.
• Review inter-module communication to identify logic gaps, state desynchronization, or race conditions.
• Assess the security impact and exploitability of all identified findings.
• Verify the correct implementation and usage of cryptographic primitives, key management, and randomization sources
• Conduct peer reviews within the audit team to ensure accuracy and consistency of findings.

2.2. Static Analysis

Static analysis supports the manual review by automatically scanning the source code for quality, consistency, and security weaknesses without executing it. This step includes:

• Running linters, analyzers, and SAST tools to detect code quality issues and potential escalation paths to security vulnerabilities.
• Reviewing third-party dependencies for known security flaws, version risks, or integrity concerns.
• Identifying gaps in test coverage and, when necessary, implementing targeted tests to validate critical logic.
• Evaluating compiler or build warnings and their potential implications for runtime behavior.
• Checking for unsafe language constructs, memory management flaws.

2.3 Dynamic Testing

Dynamic testing involves executing the blockchain protocol in a controlled local network environment to observe its real-time behavior and resilience. Auditors simulate multi-node operation to validate the protocol’s functionality, consensus, and fault tolerance under realistic and adversarial conditions. This includes:

• Validating block proposal, propagation, and verification across participating nodes.
• Verifying consensus participation, leader election, and block finality.
• Assessing node synchronization and state consistency after reboots or network delays.
• Validating transaction execution, ordering, and state transition correctness.
• Simulating edge cases and malicious validator behavior (e.g., equivocation, double proposals, censorship).
• Performing load and stress testing to evaluate performance and system limits.
• Developing Proof-of-Concept (PoC) exploits to demonstrate the impact of confirmed vulnerabilities.
• Implementing fuzz testing for components handling untrusted input (serialization/deserialization, message parsing, virtual machine operations, etc.).
• Optionally instrumenting nodes to collect runtime metrics (CPU, memory, latency) to identify performance bottlenecks.

---

This comprehensive approach allows auditors to assess the reliability, performance, and security of the protocol from multiple perspectives, from code-level correctness to network-level behavior, ensuring that the system is both robust and resistant to real-world threats.

3. Reporting

All findings are documented and delivered through Hacken’s reporting portal:

• Clients gain real-time access to audit results without waiting for the final report.
• This approach provides flexibility, allowing early discussions, prioritization, and remediation planning.
• Clear and structured reporting ensures that vulnerabilities and recommended actions are easy to review and address effectively.

Upon completion of the code review, analysis, and testing phases, the auditors prepare a comprehensive preliminary report documenting the audit results. The report typically follows the structure below:

• Introduction
• Audit Summary
• System Overview
• Risks
• Findings and Recommendations
• Disclaimers and Appendices
• Scope

For High and Critical issues, the methodology requires including Proof of Concept (PoC) test cases in the audit report. A Proof of Concept is a concrete test or exploit scenario demonstrating how a vulnerability can be triggered under real conditions. This approach ensures that severe issues are both verifiable and actionable for development teams.

4. Quality Assurance

The Quality Assurance (QA) phase is a dedicated step to ensure that each audit is thorough, consistent, and meets Hacken’s quality standards. The assigned lead auditor oversees this process, independently reviewing the findings and verifying the overall audit workflow.

During this phase, the lead auditor:

• Validates findings – Confirms that identified vulnerabilities are accurately described, correctly classified by severity, and reproducible.
• Checks consistency – Ensures that all sections of the audit adhere to the established methodology, reporting format, and internal standards.
• Reviews recommendations – Verifies that suggested mitigations are practical, actionable, and aligned with security best practices.

5. Remediation Period

After the preliminary audit report is delivered, clients have 20 business days to review the findings and implement fixes according to the recommendations and severity classifications.

When submitting fixes for retesting, the customer must:

• Implement each fix in a separate commit or pull request, distinct from others.
• Merge all fixes into a single branch and provide the final remediation commit hash to auditors.
• Ensure the code compiles successfully and the local network runs without issues.
• Base the final remediation commit directly on the initial audit commit, with no additional features or unrelated changes in between.

If these conditions are not met, the auditing team—subject to approval by the lead auditor—may decline retesting if rule violations prevent proper verification.

Early visibility through the reporting portal allows teams to track progress, clarify issues, and coordinate remediation efficiently.

6. Review of Fixes and Final Report

Once all fixes are implemented and the final remediation commit hash is submitted:

• Auditors verify that every issue has been properly addressed.
• A final, comprehensive report is prepared, documenting all findings, remediation actions, and recommendations for future improvements.
• The final report serves as the official record of the audit and may be shared with stakeholders, investors, or the broader community.

Part 3. Blockchain Protocol Audit Coverage

This section outlines the primary components assessed during a blockchain protocol audit. It provides a non-exhaustive overview of key subsystems and their main security focus areas.

Consensus Security

Consensus Algorithm Review

• Finality and safety – verification of finality mechanisms, fork-choice rules, and safety guarantees.
• Validator lifecycle – selection, rotation, slashing, and reward logic validation.
• Economic security – correctness of staking, incentives, and penalty mechanisms.
• Byzantine fault tolerance – validation of BFT algorithm implementation and tolerance thresholds.

Consensus Attack Resistance

• Centralization Risks – analysis of validator or mining power distribution, hardware or stake concentration, reliance on specific entities, and their impact on network security and censorship resistance.
• Majority (51%) attacks – resistance to validator or miner collusion.
• Nothing-at-stake and long-range attacks – enforcement of slashing and rollback prevention.
• Eclipse and Sybil attacks – peer discovery, node isolation, and identity verification.
• Fork handling – conflict resolution and canonical chain selection.
• Governance mechanisms – secure proposal execution and validator participation in governance.

Network Security

P2P Communication Security

• Message integrity and validation – format, signature, and replay protection.
• Connection security – peer authentication, session encryption, and authorization.
• Protocol compliance – correctness of message formats and state-machine logic.
• Error handling – graceful recovery from malformed or unexpected network input.

Network Attack Resistance

• Eclipse and partition attacks – network topology resilience and peer diversity.
• DoS and flooding – rate limiting, queue handling, and peer banning mechanisms.
• Man-in-the-middle protection – authentication, encryption, and transport security.
• Performance and scalability – message propagation efficiency and throughput limits.
• Resilience and recovery – handling of network failures, re-synchronization, and reconnection logic.

State Management

State Transition Validation

• State consistency and integrity – validation of transition rules and detection of corruption.
• Synchronization and recovery – state sync mechanisms, checkpoints, and rollback safety.
• Storage management – pruning, compaction, and long-term data persistence.

State Attack Resistance

• State corruption or desynchronization – unauthorized or inconsistent modifications.
• State exhaustion – prevention of unbounded growth and storage abuse.
• State manipulation – rollback, replay, or unauthorized overwriting of state.

Virtual Machine Security

Architecture Review

• Execution model – validation of opcode behavior, instruction scheduling, and state-transition logic.
• Gas and resource accounting – metering accuracy, DoS resistance, and prevention of resource exhaustion.
• Memory and storage safety – bounds checking, stack limits, and context isolation.
• Commit and revert logic – correctness of state-update and rollback handling.
• Determinism – consistent execution across all nodes under identical inputs.

Attack Resistance

• Resource exhaustion – protection against excessive CPU, memory, or storage use.
• Opcode and edge-case testing – validation of arithmetic, cryptographic, and control-flow operations.
• Reentrancy and call-stack safety – defense against recursive or nested-call exploits.
• Serialization and parsing – verification of bytecode decoding and ABI handling.
• Fuzz and differential testing – detection of nondeterminism or hidden logic flaws.
• Sandbox isolation – enforcement of separation between VMs, system contracts, and host calls.
• Time and randomness handling – consistency and determinism of time- or randomness-related logic.

Economic Security

Token Economics Review

• Token supply and distribution – fairness, transparency, and immutability of issuance logic.
• Inflation and deflation models – correctness and precision of monetary calculations.
• Staking and rewards – accuracy of reward, penalty, and slashing mechanisms.
• Governance and incentives – secure voting, delegation, and incentive alignment with network health.

Economic Attack Resistance

• Governance exploits – prevention of proposal hijacking or vote manipulation.
• Incentive misalignment – detection of mechanisms encouraging harmful validator behavior.

Cryptography and Key Management

Cryptography Review Focus

• Cryptographic primitives – selection of algorithms and parameter security.
• Signature schemes – correctness of signing, verification, and aggregation logic.
• Randomness – generation quality and unpredictability.
• Key management – secure storage, rotation, and access control.
• Hashing and commitments – correctness of Merkle or other hash-based structures.

Cryptographic Attack Resistance

• Cryptographic misuse – weak parameters, nonce reuse, or insecure hash functions.
• Signature forgery – resistance to replay or malleability attacks.
• Entropy weakness – predictability of random or pseudo-random sources.
• Key compromise – protection against leakage or unauthorized use of private keys.

Client Implementation and Configuration Security

Review Focus

• Configuration management – verification of secure defaults, peer limits, and logging settings.
• Dependency integrity – validation of third-party libraries, versions, and build reproducibility.
• RPC and API exposure – enforcement of authentication, authorization, and rate limits.
• Build and release process – code signing, deterministic builds, and binary verification.
• Monitoring and observability – implementation of meaningful metrics, logs, and diagnostic tools.

Attack Resistance

• Denial-of-service – resilience to malformed inputs, transaction flooding, and protocol-level abuse.
• Unauthorized access – prevention of RPC or administrative endpoint exploitation.
• Dependency compromise – protection against malicious or tampered libraries.
• Configuration weaknesses – mitigation of unsafe runtime or network parameters within the node software.

Cross-Chain and Bridge Interaction

Review Focus

• Message verification – correctness of proofs, signatures, and data integrity.
• Relayer trust model – access permissions, assumptions, and fallback logic.
• Asset accounting – correctness of mint, burn, and lock mechanisms.
• Replay protection – safeguards against duplicated or outdated messages.
• Synchronization – consistency of state updates across connected chains.

Attack Resistance

• Replay and double-spend – prevention of reused or forged proofs.
• Message tampering – defense against falsified or altered cross-chain data.
• Relayer compromise – risk mitigation for colluding or malicious relayers.
• Asset desynchronization – recovery from inconsistent or delayed state updates.

Part 4. Appendices

Appendix A: Issues Statuses

During the audit process, each issue can be assigned one of the following statuses:

Appendix B: Vulnerabilities Severity Formula

The severity of each identified vulnerability is determined using a standardized formula that assesses its impact and likelihood. This methodology ensures a consistent, transparent, and objective evaluation across all findings.

Stay in Touch

We’re excited to share our expertise and help you build a safer web3 future. If you have any questions, feel free to contact us.