Permissionless Blockchain Recent Trends, Privacy Concerns, Potential Solutions and Secure Development Lifecycle ^†

Abstract

Permissionless blockchains have evolved beyond cryptocurrency into foundations for Web3 applications, decentralized finance (DeFi), and digital asset ownership, yet this rapid expansion has intensified privacy vulnerabilities. This study provides a comprehensive review of recent trends, emerging privacy threats, and mitigation strategies in permissionless blockchain ecosystems. We examine six developments reshaping the landscape: meme coin proliferation on high-throughput networks, real-world asset tokenization linking on-chain activity to regulated identities, perpetual derivatives exposing trading strategies, institutional adoption concentrating holdings under regulatory oversight, prediction markets creating permanent records of beliefs, and blockchain–AI integration enabling both privacy-preserving analytics and advanced deanonymization. Through this work and forensic analysis of documented incidents, we analyze seven critical privacy threats grounded in verifiable 2024–2025 transaction data: dust attacks, private key management failures, transaction linking, remote procedure call exposure, maximal extractable value extraction, signature hijacking, and smart contract vulnerabilities. Blockchain exploits reached $2.36 billion in 2024 and $2.47 billion in the first half of 2025, with over 80% attributed to compromised private keys and signature vulnerabilities. We evaluate privacy-enhancing technologies, including zero-knowledge proofs, ring signatures, and stealth addresses, identifying the gap between academic proposals and production deployment. We further propose a Secure Development Lifecycle framework incorporating measurable security controls validated against incident data. This work bridges the disconnect between privacy research and industrial practice by synthesizing current trends, providing insights, documenting real-world threats with forensic evidence, and providing actionable insights for both researchers advancing privacy-preserving techniques and developers building secure blockchain applications.

1. Introduction

The ecosystem serves an estimated 30–60 million monthly active users, though precise measurement remains difficult because individuals often control multiple addresses [1]. While illicit activity declined to 0.4% of transaction volume in 2024 from 0.9% in 2023 [2,3], this growth trajectory has brought privacy vulnerabilities into sharper focus.

A permissionless blockchain operates as a decentralised distributed ledger where any participant can read data, submit transactions, and participate in consensus without authorisation from a central authority. Prominent examples include Bitcoin, Ethereum, and stablecoin networks such as Tether (USDT), which enhance financial access for populations underserved by traditional banking. The transparency that enables public verification creates a fundamental tension: transaction histories, wallet balances, and asset flows remain permanently visible on public ledgers [4,5]. This openness enables accountability but exposes users to deanonymization, targeted attacks, and behavioural profiling [6].

Developer activity serves as a leading indicator of ecosystem health [7]. Figure 1 shows monthly active developers across blockchain networks from 2009 to 2022, reaching approximately 22,000 by 2023. Updated data from 2024 indicates continued growth to 33,000 monthly active developers working across 1.7 million repositories [8]. Developer activity serves as a leading indicator of ecosystem health [7].

Figure 2 shows monthly active developers across blockchain networks from 2015 to 2025, distinguishing between single-chain and multi-chain developers.

The data reveals developer growth from approximately 2000 in 2015 to peak activity of 35,000 in early 2023, followed by consolidation to 25,000 by mid-2025 [8]. The divergence between single-chain and multi-chain developers after 2020 reflects increasing blockchain ecosystem fragmentation and cross-chain development patterns.

Table 1. Popular Permissionless Blockchains.

Blockchain	Type	TVL	Transactions (Daily)	Protocols	Monthly Active Developers
Ethereum	Layer 1	94.4 B [10]	1.6 M [11]	1250 [10]	6244 [8]
BSC	Layer 1	7.58 B [10]	13.56 M [12]	882 [10]	150+ [8]
Base	Layer 2	5.06 B [10]	126 M [10]	616 [10]	1500+ [8]
Solana	Layer 1	12.77 B [10]	290 M [13]	299 [10]	6000 [8]
Polygon	Layer 2	1.22 B [10]	3.1 M [14]	604 [10]	1800+ [8]
Tron	Layer 1	6.42 B [10]	18 M [15]	37 [10]	500+ [8]
BTC	Layer 1	8.54 B [10]	535 K [16]	42 [10]	1200 [8]
Near	Layer 1	97 M [10]	4.4 M [17]	32 [10]	1000+ [8]

presents the leading permissionless blockchains by total value locked (TVL), daily transaction volume, and active developer count as of September 2025. All quantitative metrics follow definitions provided in Appendix B.

Despite substantial academic work on privacy-preserving techniques such as zero-knowledge proofs [18,19], ring signatures [20], and stealth addresses [21], a gap persists between theoretical solutions and production deployment. Recent security incidents demonstrate this disconnect: losses from blockchain exploits reached $2.36 billion in 2024 and $2.47 billion in the first half of 2025 [22], with over 80% attributed to compromised private keys and signature vulnerabilities rather than protocol flaws. Emerging trends, including Layer-2 scaling solutions, real-world asset (RWA) tokenisation, and institutional adoption, introduce new attack surfaces that existing privacy frameworks do not adequately address.

This paper provides a comprehensive analysis of privacy challenges in contemporary permissionless blockchains by examining emerging trends, documenting current threats through forensic analysis, and evaluating existing mitigation approaches. We extend our prior conference work [23] with three contributions:

• We analyse six emerging trends reshaping the blockchain privacy landscape: meme coin proliferation, real-world asset tokenisation, perpetual derivatives, institutional adoption, prediction markets, and blockchain-AI integration. We document how each trend introduces novel attack surfaces and privacy risks not addressed by existing frameworks.
• We systematically examine seven privacy threat categories through forensic analysis of documented 2024–2025 incidents: dust attacks, private key management failures, transaction linking, remote procedure call exposure, maximal extractable value extraction, signature hijacking, and smart contract vulnerabilities. Our analysis includes verifiable transaction data and incident timelines demonstrating attack patterns.
• We evaluate privacy-enhancing technologies—zero-knowledge proofs, zero-knowledge Ethereum Virtual Machines (zkEVMs), ring signatures, stealth addresses, and permissioned frameworks—examining their trade-offs in performance, developer accessibility, and deployment barriers. We propose a Secure Development Lifecycle framework incorporating lessons from documented incidents to bridge the gap between academic privacy research and industrial practice.

Section 2 reviews related work on blockchain privacy. Section 3 examines recent trends including meme coin proliferation, RWA tokenisation, perpetual derivatives exchanges, national cryptocurrency reserves, and prediction markets. Section 4 analyses specific privacy threats in permissionless networks. Section 5 evaluates potential solutions through privacy-improving cryptography and architectural approaches. Section 6 presents the SDLC framework with role assignments and measurable security controls. Section 7 discusses formal verification methods, and Section 8 addresses post-quantum cryptographic considerations. Section 10 concludes.

2. Related Works

This section summarises the related works on privacy preservation in permissionless blockchain networks and some alternative solutions for that. In [24], the Punishment Not Reward (PnR) blockchain architecture was proposed to address the issue of balancing privacy and openness in permissionless blockchain networks such as Ethereum and Bitcoin. The author suggested two methods, denial of service to the application and/or revocation of anonymity, as alternatives to the traditional reward-based approach for block creation to maintain the network’s privacy. The EVM and Solidity have previously dominated development and transaction processing, but Solana has recently gained prominence, with the low network cost of the Solana transaction fee and the rise of meme coins.

These privacy concerns not only challenge user privacy and cause security issues, but also affect the performance of the blockchain, creating situations like backlogs, and leading to the fork of the blockchain and other issues. For example, dust attacks entice users to interact with a fake smart contract, and numerous dust attacks reduce the performance of the blockchain, creating problematic issues. In [25], a way was suggested to identify and prevent such things.

Saad et al. [26] identified multiple privacy attack vectors on the surface of the blockchain. A comprehensive investigation was done, which included aspects such as attacks associated with mathematical techniques used for creating the ledger, attacks associated with peer-to-peer architectures such as the 51% attack, and attacks associated with the application configuration of blockchain, such as wallet theft, double spending, etc.

In [27], a qualitative comparison was presented for privacy-preserving methods of engineering data. The methods include proxy encryption, homomorphic encryption, ZKP, and a trusted execution environment. The result indicates that approaches that rely on a trusted third party to preserve participant privacy do not provide sufficiently strong guarantees that sensitive data would not be exposed in modern data ecosystems. In [28], a privacy-preserving healthcare framework using Hyperledger Fabric was proposed, implementing zero-knowledge proofs through the Idemix suite to ensure patient data privacy with features such as anonymity and unlinkability. In [29], a systematic review of the current state-of-the-art in privacy-preserving research solutions and mechanisms on blockchain was presented, which also discussed challenges in blockchain scenarios such as post-quantum computing resistance, malicious-curious TTPs and regulatory challenges. Table 2 shows the results of the comparisons of the most closely related solutions for privacy concerns without permission. In one proposal, the present authors implemented a prototype of the PnR architecture on Hyperledger Fabric, a system with 4 nodes working on virtual machines as independent nodes. Subsequent work extended this architecture with NFT-based authentication mechanisms for decentralised autonomous organisation governance [30], demonstrating how accountability and privacy can coexist through selective anonymity revocation. In [4], some information on the privacy issues associated with blockchain is provided, and the privacy threats on blockchain are analysed, along with existing cryptographic defence mechanisms, such as anonymity and preservation of transaction privacy. Furthermore, the authors summarised some typical implementations of privacy preservation mechanisms in blockchain.

Paper [5] listed several privacy issues in blockchain and the methods of protecting privacy in blockchain, such as a mixing service, ring signatures, confidential transactions, non-interactive zero-knowledge proofs, smart contract privacy, etc. The development of on-chain and off-chain ecosystems is growing rapidly, and some of the protection methods are not state-of-the-art. There are more threat models and more concerns now. In [6], Henry et al. demonstrated, foresight in identifying access privacy as a critical vulnerability in blockchain systems. The authors focused specifically on network-level privacy challenges, particularly the risks associated with transaction announcement and retrieval patterns that could compromise user anonymity when cryptographic privacy measures were in place. Their critique of relying solely on Tor for blockchain privacy protection proved prescient, as subsequent research has validated many of their concerns about the inadequacy of general-purpose anonymity networks for blockchain applications.

A comprehensive analysis of privacy challenges across permissionless and permissioned blockchains, including smart contract innovations and architectural approaches, was presented in [31]. Though the paper addresses only one facet of blockchain privacy, it establishes important groundwork for understanding how network-level adversaries could undermine the privacy guarantees that early blockchain adopters assumed were inherent to pseudonymous systems.

Table 2. Comparison of Related Solutions with our proposed PnR DAO using Hyperledger Fabric Developed.

Related Solutions	MS 1	ZKP 2	HLF 3	RS 4	SA 5	PE 6	zkEVM 7
[32]		✓		✓		✓
[5]		✓		✓		✓
[24]		✓
[29]		✓	✓	✓		✓	✓
[28,33]			✓
[34]					✓
[6,35,36]						✓
[27]				✓
[4]		✓	✓	✓		✓	✓
PnR DAO in Hyperledger Fabric Version	✓	✓	✓	✓	✓	✓	✓

¹ MS: Multi-Signature. ² ZKP: Zero-Knowledge Proof. ³ HLF: Hyperledger Fabric. ⁴ RS: Ring Signature. ⁵ SA: Stealth Addresses. ⁶ PE: Privacy-improving. ⁷ zkEVM: Zero-Knowledge Ethereum Virtual Machine.

Table 2. Comparison of Related Solutions with our proposed PnR DAO using Hyperledger Fabric Developed.

Related Solutions	MS 1	ZKP 2	HLF 3	RS 4	SA 5	PE 6	zkEVM 7
[32]		✓		✓		✓
[5]		✓		✓		✓
[24]		✓
[29]		✓	✓	✓		✓	✓
[28,33]			✓
[34]					✓
[6,35,36]						✓
[27]				✓
[4]		✓	✓	✓		✓	✓
PnR DAO in Hyperledger Fabric Version	✓	✓	✓	✓	✓	✓	✓

¹ MS: Multi-Signature. ² ZKP: Zero-Knowledge Proof. ³ HLF: Hyperledger Fabric. ⁴ RS: Ring Signature. ⁵ SA: Stealth Addresses. ⁶ PE: Privacy-improving. ⁷ zkEVM: Zero-Knowledge Ethereum Virtual Machine.

3. Emerging Trends in Permissionless Blockchain Ecosystems

Since Bitcoin’s 2009 launch, the blockchain industry has evolved through the ICO boom (2017–2018), DeFi summer (2020), NFT markets (2021), and most recently Layer-2 scaling solutions and institutional adoption (2023–2025). We have witnessed the ICO bubble, the NFT boom, exchange mining, airdrop hunting, the DeFi summer, the Layer-2 wars, social chains, Play-to-Earn economies, Polymarket, nations accepting crypto as a reserve, and the rise of DePin networks. Each stage of adoption introduced new concepts, architectures, and attack surfaces. In the current phase, emerging trends such as Solana-powered meme coins, real-world asset (RWA) tokenisation, perpetual exchanges, and decentralised trading platforms are reshaping blockchain dynamics. Meanwhile, the rapid integration of artificial intelligence is introducing both opportunities and novel vulnerabilities. This section explores these evolving trends and the corresponding security challenges they bring to permissionless blockchains.

3.1. Meme Coin Proliferation on Solana and Speculative Market Dynamics

Solana’s high throughput (65,000+ transactions per second) and low costs (<$0.01 per transaction) enabled the proliferation of speculative tokens [37]. By October 2025, Solana-based meme coins reached $11.4 billion market capitalisation, creating conditions where token creation requires minimal capital or technical knowledge, while platforms like Pump.fun processed more than 250,000 new token launches weekly, generating monthly revenues exceeding $40 million [38].

The scale reveals privacy risks beyond financial losses. Dogwifhat achieved a peak market capitalisation of $3.5 billion before declining over 60% [39], while newer tokens such as Fartcoin demonstrated gains exceeding 1600% within weeks [40]. Transaction transparency enables behavioural profiling through address clustering techniques [41] that link seemingly independent wallets through common input heuristics. Temporal analysis of trading activity provides insights into user decision-making processes, while integration with social media platforms creates correlation opportunities when users inadvertently link digital identities to wallet addresses. The accessibility of the SPL token standard has led to documented patterns of rug pulls, honeypot tokens preventing sells, and coordinated pump-and-dump schemes across social platforms. The regulatory vacuum surrounding meme tokens eliminates traditional recourse mechanisms, leaving investors with limited options following fraud or market manipulation while malicious actors exploit blockchain pseudonymity.

3.2. Real-World Asset Tokenisation and Verification Gaps

The tokenised real-world assets expanded by 85% year on year to reach $15.2 billion by December 2024, excluding the stablecoins [42]. Including fiat-backed tokens, the total market approached $230 billion by mid-2025, with Tether’s USDT and Circle’s USDC representing 93.5% of this segment [43]. The tokenised treasury sector grew 539% between January and December 2024, reaching $5.6 billion in total value locked., with BlackRock’s BUIDL fund capturing 44% market share [42,43]. Over 119 issuers actively tokenise assets spanning private credit, commodities, real estate, and government securities [42]. Figure 3 illustrates the exponential growth trajectory of tokenised real-world assets from July 2021 to October 2025.

Maintaining links between on-chain representations and off-chain assets remains a challenge. Unlike native cryptocurrency tokens whose value derives entirely from network consensus, tokenised assets depend on external verification mechanisms [45] to ensure that the claimed backing exists. Chainlink’s Proof of Reserve system uses oracle networks to verify collateral through automated queries to custodian banks [46], yet these systems remain vulnerable to custodian malfeasance, regulatory changes that affect ownership, and coordination failures between verification parties. Enterprise tokenisation platforms process sensitive information about asset ownership and transaction histories, consolidating data traditionally distributed across multiple intermediaries. The permissionless nature means that transaction patterns become permanently visible on public ledgers, enabling analysis of institutional investment strategies. The European MiCA regulation entered full effect in 2024 [43], establishing comprehensive rules for tokenised asset issuers within EU member states, while regulatory oversight in the United States remains fragmented between multiple agencies. Asset tokenisation requires KYC procedures for anti-money laundering compliance, linking on-chain addresses to verified real-world identities, and creating centralised databases that become targets for cybercriminals.

3.3. Perpetual Futures Decentralised Exchanges and Leverage Risks

Perpetual futures generated daily trading volumes exceeding $12 trillion during Q2 2025, representing 59% of cryptocurrency derivatives activity [47]. Hyperliquid launched in 2024 with a custom Layer-1 blockchain optimised for derivatives trading, achieving transaction finality under two seconds while processing peak daily volumes exceeding $8 billion [48]. By October 2024, Hyperliquid controlled over 80% of the decentralised perpetual derivatives market [47,49]. Chen et al. identified four distinct operational models that govern exchange operations [50], with empirical analysis revealing that decentralised exchanges that employ virtual automated market-making models exhibit price formation dynamics where open interest in long and short positions exerts opposite effects on price volatility [51]. Figure 4 shows growth from $20 million in July 2021 to $34 billion in October 2025.

Ruan and Streltsov analysed high-frequency order book data from 2017 to 2023, documenting that spot market quality follows a U-shaped pattern over perpetual contracts’ eight-hour funding cycles [53]. Their research identified that perpetual contracts increase spot trading volume while widening quoted spreads, reflecting increased informed trading during funding settlement periods. Market makers respond to heightened adverse selection risk by expanding bid-ask spreads. Platforms like Hyperliquid support leverage ratios up to 50× [48], while Aster advertises leverage exceeding 1000× [54]. The December 2024 Bitcoin flash crash saw prices decline 7% from $103,853 to $92,251 within minutes, liquidating over $400 million in overleveraged long positions [47]. Transaction transparency enables competitors to observe large position accumulations and liquidation prices, facilitating front-running strategies. Blockchain analysis firms revealed extreme token concentration in Aster, with six wallet addresses controlling over 96% of total supply [54].

3.4. National Cryptocurrency Reserves and Institutional Adoption

Kazakhstan established the Alem Crypto Fund in September 2025, creating a state-backed vehicle for digital asset reserves through the Ministry of Artificial Intelligence and Digital Development [55]. The fund made its initial investment in BNB through a partnership with Binance Kazakhstan, managed by Qazaqstan Venture Group under the Astana International Financial Centre [56]. President Kassym-Jomart Tokayev announced plans for a comprehensive digital asset ecosystem with legislation targeted before 2026 [55], following the May 2025 plans for CryptoCity, a pilot zone allowing crypto payments [57]. After China’s mining crackdown, Kazakhstan ranked second globally by Bitcoin hashrate in 2021, though regulatory concerns led to the closure of 36 unlicensed exchanges in 2024 [55].

The trend extends beyond Kazakhstan. El Salvador established an official Bitcoin reserve in 2021, while Bhutan began accumulating Bitcoin through state-backed mining operations as early as 2019 [58]. Brazil and Indonesia have explored frameworks for building national digital asset reserves [55]. The institutional adoption trajectory follows earlier initiatives where Cointelegraph reported in June 2025 that Kazakhstan’s National Bank considered plans for a state-run crypto reserve funded with seized assets and state mining revenues [55]. Though the Alem Crypto Fund differs from a central bank reserve, it signals growing acceptance of digital assets as strategic holdings comparable to traditional foreign currency reserves. The institutional adoption trajectory raises privacy concerns for individual users. State-backed funds consolidating large positions enable correlation of on-chain activity with national policy decisions. The public nature of blockchain holdings allows tracking of government investment strategies, while regulatory frameworks tied to these initiatives often require enhanced know-your-customer procedures that link on-chain addresses to verified identities. This creates centralised databases connecting wallet addresses to real-world identities, undermining the pseudonymous properties that attracted early cryptocurrency adoption.

3.5. Blockchain Prediction Markets and Electoral Forecasting

Polymarket, a blockchain-based prediction market built on Polygon, processed over $3.3 billion in wagers on the 2024 U.S. presidential election between Donald Trump and Kamala Harris [59]. The platform predicted Trump’s victory with 95% certainty before midnight on election night [60], contrasting with traditional polls that showed near 50-50 odds [61]. Polymarket’s total value locked surged from $9.5 million in stablecoins at the start of 2024 to $220 million, with lifetime trading volume surpassing $1 billion by August [62]. The platform operates through users purchasing outcome shares using the USDC stablecoin, with prices adjusting in real-time based on trading activity.

Research firms Chaos Labs and Inca Digital identified evidence of wash trading on Polymarket, finding actual transaction volume around $1.75 billion compared with the platform’s reported figure of $2.7 billion [62]. Four individuals collectively wagered $25 million on Trump’s victory, with analysis suggesting strong reason to believe they represented the same entity [59,62]. The platform faced regulatory challenges, receiving a $1.4 million fine from the Commodity Futures Trading Commission in January 2022 for failure to register as a Swap Execution Facility [59]. Despite operating offshore to avoid U.S. regulations, an estimated $3.2 billion in cryptocurrency flowed through Polymarket during the 2024 election, with VPN services suspected of enabling U.S.-based users to bypass geographic restrictions [60]. The FBI raided founder Shayne Coplan’s residence in November 2024, with sources describing it as political retribution [60].

3.6. Blockchain-AI Integration and Federated Learning

The convergence of Blockchain and Artificial Intelligence (AI) represents a transformative step in addressing the core challenges of data privacy, trust, and decentralisation. Blockchain offers an immutable and transparent ledger capable of maintaining verifiable audit trails for AI-driven processes, which is especially relevant for distributed intelligence and data provenance verification. Recent works, such as Qu et al. [63], have comprehensively reviewed blockchain-enabled federated learning (FL) frameworks, highlighting their potential to overcome the limitations of centralised model aggregation by improving transparency, auditability, and incentive alignment. Similarly, Nguyen et al. [64] identified that integrating blockchain with edge-based FL allows for privacy-preserving computation at scale, supporting secure collaboration among heterogeneous IoT devices. This synergy mitigates the risks of single points of failure and strengthens accountability in AI model training. Furthermore, the emergence of advanced frameworks such as Biscotti [65] demonstrates how consensus-driven learning architectures can maintain both data confidentiality and model integrity without central coordination.

Beyond scalability and transparency, the blockchain–AI paradigm is rapidly evolving to address emerging threats such as poisoning and inference attacks. Ullah et al. [66] proposed a blockchain-based federated learning architecture (SPBFL-IoV) specifically tailored for Internet of Vehicles (IoV) systems to counter adversarial model manipulation through homomorphic encryption and robust update filtering. Bao et al. [67] extended this concept toward data governance by introducing blockchain-based privacy-preserving credit data sharing using attribute-based encryption, ensuring both fine-grained access control and traceable data exchanges. At a broader level, Liang and Ji [68] conducted a systematic review of privacy challenges in IoT-blockchain ecosystems, emphasising the trade-offs between transparency and confidentiality. Collectively, these developments underscore blockchain’s pivotal role in enabling secure, decentralised AI infrastructures that are auditable, privacy-aware, and resilient against adversarial behaviour—marking a fundamental shift toward verifiable and accountable intelligence.

Our previous studies have explored these aspects in IoT-healthcare ecosystems. In [69], a smart e-health framework was developed to monitor elderly and disabled individuals using edge-based processing for real-time analysis while preserving privacy. Earlier, lightweight deep learning models were proposed for efficient healthcare data analysis [70], and colour-coded CNN architectures were used for activity recognition and anomaly detection in wearable sensor data [71]. In a related work, multi-tiered security and explainability were investigated in IoT–Edge–Cloud environments for anomaly detection and data management [72]. Furthermore, the integration of federated learning for healthcare data privacy and interoperability has already demonstrated promising results in protecting distributed health records [73]. Building on these foundations, our current proposal extends the same principles by integrating blockchain with federated learning to ensure both verifiable updates and privacy-compliant collaboration among distributed healthcare institutions. Each institution maintains its data locally while participating in a shared training process governed by blockchain-based consensus and smart contracts. This integration not only enhances data confidentiality but also introduces transparent audit trails for model contributions and parameter exchanges. The proposed system aims to create a trustworthy, regulation-aligned, and technically feasible framework that reflects ongoing trends in secure, distributed healthcare data management. Beyond privacy applications, blockchain integration with search and retrieval systems has been explored in educational contexts [74], though these approaches primarily address content discovery rather than privacy preservation. Multimodal search capabilities in decentralised educational networks [75] demonstrate the potential for blockchain-based content distribution, though privacy considerations in such systems remain underexplored.

Having examined emerging trends that reshape the blockchain landscape, we now analyse specific privacy threats that exploit architectural transparency and user behaviour patterns.

4. Privacy Threats in Permissionless Blockchain Networks

Blockchain’s transparent architecture comes with privacy risks. With the rapid growth of DeFi, NFT, and Web3 dApps, new risks have emerged. We shall discuss some of the latest typical risks in this paper.

4.1. Dust Transactions and Zero-Value Transfer Attacks

Address poisoning attacks represent an evolution of traditional dust attacks, exploiting user interface dependencies and cognitive biases in address verification processes. These attacks leverage the transparency of blockchain transaction logs, where malicious actors systematically monitor high-value wallet addresses through blockchain explorers to identify targets holding substantial assets, particularly stablecoins such as USDT on the Ethereum network [25]. The attack methodology involves generating vanity addresses that match the first 4-5 and the final 4-5 hexadecimal characters of legitimate addresses. This exploits users’ tendency to verify only the beginning and end of lengthy hexadecimal strings rather than checking the complete address, a behavioural pattern rooted in cognitive shortcuts that affect security decision-making [76]. These attacks extend beyond simple address mimicry and include comprehensive transaction shadowing and asset impersonation. A documented August 2024 case involved an attacker creating 47 shadow transactions over six days before deceiving the victim into transferring 20 million USDT. (Verification: Transaction hash 0x08255ca0e42a872559437141fa46980e66d907f7668922467d67515b1ebb4b7f at block 20,571,432. Complete forensic timeline available at the referenced Etherscan link. Verification instructions: (1) Navigate to https://etherscan.io/tx/0x08255ca0e42a872559437141fa46980e66d907f7668922467d67515b1ebb4b7f (accessed on 6 October 2025), (2) Observe the 20M USDT transfer to the attacker’s address, (3) Click “Click to see More” and examine Internal Transactions showing the token routing, (4) Review the victim’s transaction history at block 20,571,300–20,571,450 to observe the pattern of shadow transactions preceding the attack. All blockchain data referenced is publicly accessible and immutable. This incident demonstrates the financial severity and technical sophistication of contemporary address poisoning schemes. The attack timeline reveals a methodical approach: initial reconnaissance (15–17 August), shadow transaction deployment (18–20 August), and execution phase (21 August), with the attacker maintaining consistent timing patterns matching the victim’s typical transaction schedule).

These attacks have evolved from traditional dust attacks, which involve the mass distribution of minimal value tokens or nonfungible tokens to target addresses. The fundamental premise of dust attacks relies on the expectation that recipients will eventually interact with the received assets, either through attempted disposal or inadvertent smart contract engagement. Such interactions can trigger malicious contract code or provide additional information on user behaviour and wallet management practices.

Defensive measures against address poisoning attacks require comprehensive verification protocols that extend beyond superficial address inspection. Security-conscious users should implement complete address verification procedures, examining all 42 hexadecimal characters rather than relying on prefix and suffix matching. The establishment of verified address whitelists provides an additional security layer, though this approach requires careful maintenance and verification procedures.

Transaction confirmation protocols should incorporate small-value test transactions before high-value transfers, particularly when transacting with previously unused addresses. This practice enables verification of recipient control and address accuracy while minimising potential losses from misdirected funds. Furthermore, users should maintain awareness of their complete transaction history and investigate unexpected zero-value transfers or unfamiliar token receipts, as these may indicate targeting by address poisoning campaigns.

The mathematical probability of an accidental collision with an address provides insight into the sophistication required for these attacks. For Ethereum addresses derived from the final 20 bytes of the Keccak-256 hash output, the probability of generating an address that matches the 5-character prefix and 5-character suffix patterns is approximately ${\displaystyle \frac{1}{{16}^{10}}}={\displaystyle \frac{1}{2^{40}}}$, representing a computationally intensive but feasible undertaking for motivated attackers with sufficient resources.

4.2. Private Key Management Vulnerabilities

Private key management represents the foundational security challenge in permissionless blockchains, while elliptic curve cryptography provides theoretical security of approximately $2^{128}$ operations for key recovery [77], contemporary threats target key management practices rather than cryptographic strength.

Private key compromises dominated 2024 blockchain incidents, causing over 80% of the $2.36 billion in losses across 760 documented cases [22]. This trend accelerated in 2025, with first-half losses reaching $2.47 billion despite fewer total incident, state-sponsored groups like the Lazarus Group stole $1.34 billion across 47 incidents in 2024 [78]. These operations frequently employ social engineering methodologies, including fabricated employment interviews where malicious code embedded within technical assessments extracts private keys from developer environments. A particularly concerning development involves the ongoing exploitation of the LastPass security breach, where encrypted password vaults containing seed phrases and private keys continue to be compromised through cryptanalytic attacks. This incident has resulted in cascading losses exceeding $250 million as of 2024, with victims continuing to emerge as encrypted vaults are systematically cracked [79]. The temporal persistence of this threat vector demonstrates how single points of failure in centralised password management can create extended vulnerability windows.

Contemporary private key theft methodologies have expanded beyond direct extraction to include address poisoning attacks, where malicious actors generate vanity addresses with similar prefixes and suffixes to legitimate addresses, as mentioned above, exploiting user interface dependencies and muscle memory. These attacks resulted in more than $83 million in documented losses during the first half of 2025, with notable incidents including a $2.6 million misdirected transaction due to manipulation of the transaction history.

Enterprise environments face additional complexities in private key management, particularly regarding multi-signature implementations and threshold signature schemes. The security of multi-signature wallets depends critically on the independence of key storage locations and the threshold parameter t in an t-of-n scheme. Recent incidents, including the WEMIX platform compromise resulting in $6.1 million losses through stolen authentication keys, demonstrate how centralised key management practices can undermine the theoretical security of distributed signing schemes [80].

Hardware security modules and cold storage solutions [81] provide enhanced protection through physical isolation of private key material, yet remain vulnerable to supply chain attacks and firmware compromise. The verification of hardware wallet integrity requires cryptographic attestation protocols, though the implementation of such systems remains inconsistent across consumer-grade devices.

The emergence of threshold signature schemes and secure multiparty computation protocols offers promising alternatives to traditional key management approaches. These cryptographic primitives enable distributed key generation and signing operations without any party possessing complete private key material, mathematically represented through secret sharing schemes where $k={\sum }_{i=1}^t{a}_i·s_i$ reconstructs the private key k only when t shares are combined. Prevention strategies must address both technical and human factors in private key security. The implementation of hardware-backed key storage, regular security audits of key management procedures, and comprehensive employee training regarding social engineering techniques have become essential components of contemporary blockchain security frameworks. The persistent evolution of attack methodologies necessitates continuous adaptation of defensive measures, particularly as the financial incentives for private key theft continue to increase with broader blockchain adoption and higher asset valuations.

4.3. Transaction Linking, Name Service Vulnerabilities, and On-Chain Analysis

Transaction linking exploits blockchain transparency to track user behaviour. Once users reveal wallet addresses publicly, graph analysis algorithms can connect their complete transaction history by clustering common inputs and identifying change addresses across the public ledger [82]. Transaction timing, gas fee patterns, and smart contract interactions create behavioural fingerprints that persist across address rotations. Cross-chain bridges compound this risk, as transaction timing and amounts can link addresses across multiple networks.

Blockchain name services like Ethereum Name Service introduce additional privacy concerns while improving usability. ENS domains function as NFT tokens that create permanent on-chain links between human-readable names and wallet addresses. Research by Xia et al. shows serious security problems within ENS, including domain squatting, malicious website connections, and scam addresses that exploit user trust in legitimate-looking domain names [83]. The convenience of ENS creates new attack opportunities through domain impersonation. Attackers register ENS domains that mimic legitimate wallet addresses, taking advantage of user interface flaws where address suggestions show ENS matches before exact address matches. This leads to phishing attacks where users accidentally select fraudulent domains when trying to access their own addresses. Name service registrations expose additional metadata through domain trading patterns and auction behaviours. The public ENS auction system reveals bidding strategies and value assessments that provide insights into users’ financial capabilities. ENS subdomain delegation creates recursive privacy risks, where root domain owners gain visibility into all subdomain activities. Using name services across multiple decentralised applications creates expanded tracking surfaces. Consistent name usage enables behavioural profiling that spans multiple protocols and applications, building comprehensive user profiles.

Mathematical analysis shows the effectiveness of address clustering approaches in privacy reduction. Common input ownership techniques achieve over 90% accuracy in Bitcoin networks, while change address identification maintains a similar success rate through output value analysis and timing correlations. Defence strategies require careful privacy practices that address both technical and operational risks. Users should rotate addresses regularly and avoid reusing addresses across transactions. Privacy tools like CoinJoin implementations, ring signatures, and zero-knowledge proof systems provide better anonymity, though they need careful implementation to avoid creating new tracking opportunities. The usage of name services should follow privacy-conscious practices, including careful ENS configurations and avoiding personally identifiable domain selections. Users must understand that name service registrations on the chain are permanent and have long-term privacy implications. Machine learning techniques in blockchain analysis have increased the sophistication of tracking attacks. Graph neural networks and deep learning algorithms can identify subtle patterns in transaction behaviours that traditional approaches miss, creating more challenging privacy preservation requirements [82].

Understanding these privacy challenges helps users make informed decisions about blockchain interactions and implement appropriate countermeasures to preserve financial privacy in permissionless networks.

4.4. RPC Infrastructure Privacy and MEV Extraction

Remote Procedure Call protocols form the main part of blockchain infrastructure, enabling communication between clients and blockchain nodes. Most users interact with blockchains through RPC endpoints without realising it, as popular wallet extensions like MetaMask use centralised RPC providers by default. Infura, owned by ConsenSys, serves as MetaMask’s default RPC provider, handling millions of requests daily from users who cannot afford to run their own blockchain nodes [84]. Many third-party RPC nodes serve millions of users who seek to add chains to their wallets, improve transaction speed, or complete tasks for project owners. This widespread reliance on centralised RPC infrastructure creates serious privacy risks that most users remain unaware of.

When users send transactions through wallet extensions, their IP addresses, transaction patterns, and behavioural data become visible to RPC providers, typically stored for at least some days. These companies can build detailed profiles of user activity, including which decentralised applications they use, their transaction frequency, and their asset holdings. The centralised nature of this infrastructure contradicts the decentralised principles that blockchain networks aim to achieve. Running personal blockchain nodes requires technical expertise and financial resources that most users lack. Ethereum nodes need large storage space, processing power, and constant maintenance, forcing most users to depend on third-party RPC services and creating bottlenecks in what should be decentralised networks.

Over 43 major RPC providers currently serve the blockchain ecosystem, including Alchemy, QuickNode, Chainstack, and numerous smaller services [85]. RPC communication faces several security challenges beyond privacy concerns. Unencrypted connections between clients and servers allow man-in-the-middle attacks where malicious actors can intercept and modify transaction data. Poor authentication mechanisms enable unauthorised access to RPC interfaces, potentially allowing attackers to control blockchain nodes or extract sensitive information. The 2022 Tornado Cash incident demonstrated how centralised RPC providers can block access to specific smart contracts, showing the censorship risks inherent in centralised infrastructure [86]. Testing environments and development networks heavily depend on RPC infrastructure, with developers building decentralised applications typically using testnet RPC endpoints provided by companies like Alchemy and Infura. This dependency means that experimental blockchain development relies on centralised infrastructure, creating additional points of failure and surveillance.

Maximal Extractable Value bots represent a different but related threat to blockchain privacy and fairness. MEV bots are automated programs that monitor blockchain mempools for profitable opportunities, reordering transactions to extract value from regular users. These bots earn profits through frontrunning, sandwich attacks, and arbitrage strategies that exploit the transparent nature of blockchain transactions. Frontrunning occurs when MEV bots observe pending transactions and place their own transactions with higher gas fees to execute first, allowing bots to profit from price movements they know will occur when the original transaction processes. Sandwich attacks involve MEV bots placing buy orders before a user’s trade and sell orders after it, artificially manipulating prices to extract value from the user’s transaction [87].

The scale of MEV extraction has grown substantially, with Flashbots data showing $7.4 million extracted through MEV on Ethereum in just 30 days. Most MEV activity targets popular decentralised exchanges like Uniswap, where bots can predict price impacts from large trades and position themselves accordingly [88]. The mathematical advantage comes from MEV bots having faster access to mempool data and the ability to adjust gas prices dynamically to ensure transaction ordering. Recent incidents demonstrate the complexity of MEV attacks, including a 2023 case where a rogue Ethereum validator conducted a $25 million sandwich attack by manipulating the block building process. The validator deposited the minimum 32 ETH required for validation, then used their block proposal privileges to frontrun MEV bots themselves, extracting value from both regular users and other MEV operators [89].

MEV bots create fairness problems that undermine the intended transparency and equality of blockchain networks. Regular users face higher transaction costs and worse execution prices because MEV bots consistently outbid them for favourable transaction ordering, creating a two-tier system where automated traders extract value from regular participants who lack the technical knowledge or resources to compete. MEV protection mechanisms exist, but remain underused. Private mempools and MEV protection services can protect transactions from front-running, but most wallet software does not implement these protections by default. Projects like Flashbots have developed tools to make MEV extraction more transparent and democratic, though adoption remains limited outside of trading operations. Understanding these infrastructure risks helps users make informed decisions about blockchain interaction methods. Running personal nodes provides the highest level of privacy and censorship resistance, though technical and financial barriers remain substantial. Alternative approaches include using privacy-focused RPC providers, rotating between different services, and implementing transaction privacy tools that reduce exposure to MEV extraction.

4.5. Permit and Permit2 Signature Hijacking Vulnerabilities

Off-chain token approval mechanisms like Permit2 reduce gas costs but create new attack surfaces. Phishing campaigns targeting these signatures caused $314 million in losses during H1 2024 from 260,000 victims, surpassing all 2023 losses [90]. This represented over half of DeFi security incidents in 2024 [91]. A single PEPE token holder lost $1.39 million after signing one malicious Permit2 signature [92].

Forensic analysis of October 2024 incidents reveals coordinated attack patterns. On 10 October 2024, at 22:03:43 UTC, the fwdETH incident (transaction hash on Blast Chain—Layer 2 chain of Ethereum: 0x80bbc39...5b84591e3648d) resulted in $36 million losses through a malicious Permit2 signature. The attack targeted the victim’s wallet 0xEab23c1E3776fAd145e2E3dc56bcf739f6e0a393, draining 15,079 fwdETH in two transfers: 12,817.15 fwdETH to 0x0605eDeE6a8b8b553caE09Abe83b2ebeb75516eC and 2261.85 fwDETH to 0xA963df55B326609a0cd205e85ca92d2a3c94DaB5. The attack exploited infinite approval through Permit2 signatures. Approximately two weeks earlier, on 27–28 September 2024, the spWETH attack ($32.43 million) demonstrated similar Permit2 exploitation patterns. The PEPE token incident of October 13, 2024, demonstrates the attack speed: victims signed malicious Permit2 signatures and lost $1.39 million in PEPE, MSTR, and APU tokens within approximately one hour of signing. Forensic verification: (1) Query https://blastscan.io/tx/0x80bbc39dd5c62b5368e1bf10d40969f5da8b45555de6bfbbcfe5b84591e3648d to view the complete transaction details on Blast Chain Block 9894004 (accessed 19 November 2025), (2) Review token transfers showing the two-stage drain of 15,079 total fwDETH, (3) Cross-reference attacker addresses with known malicious contracts.

The attack methodology exploits the asymmetric nature of cryptographic signatures [93]. Malicious actors construct approval messages appearing to authorise small transactions while actually granting comprehensive token access. Phishing websites replicate legitimate DeFi interfaces, targeting users who previously interacted with protocols like Uniswap. Since the off-chain signing process prevents users from verifying the approval scope, attackers obtain valid signatures for malicious operations that blockchain verification accepts as legitimate.

Prevention requires strict signature verification procedures, including manual examination of recipient addresses, token amounts, and expiration times. Hardware wallets increase signing deliberation but cannot prevent users from approving malicious messages. The convenience-security trade-off remains unresolved, with Permit2’s gas savings creating persistent attack surfaces as hijacking techniques become increasingly automated.

4.6. Smart Contract Risk

Smart contracts represent programmable agreements that execute automatically on blockchain networks, but their immutable nature makes security flaws particularly dangerous. In this paper, we mainly focus on EVM-compatible languages like Solidity, widely used by the community. Once deployed, smart contracts cannot be modified [94], meaning any vulnerabilities become permanent attack vectors (except that the smart contract is designed to be updatable by the developer). The transparency of permissionless blockchains allows anyone to examine contract code and identify weaknesses, creating both security benefits through public auditing and risks through attack discovery.

Recent data from OWASP’s Smart Contract Top 10 analysis shows that access control vulnerabilities alone caused $953.2 million in losses during 2024, while logic errors resulted in $63.8 million in damages. Reentrancy attacks, despite being well-known since the 2016 DAO incident, still caused $35.7 million in losses [95]. These numbers demonstrate that smart contract security remains a major problem despite years of research and tool development. Developers face multiple security challenges during the development process that extend beyond code quality. Environment configuration often involves storing sensitive information like contract addresses, private keys, and API endpoints, while developers commonly use .env files for local development, exposing contract addresses in environment files creates limited risk since these addresses become public upon deployment. However, private keys and deployment credentials should never appear in .env files or any version-controlled code. Production deployments require secure key management through hardware wallets or dedicated key management services.

Contract replacement attacks present another risk where malicious actors deploy similar contracts with subtle modifications to trick users into interacting with compromised versions. Developers can prevent this through proper verification processes, including contract address verification on block explorers and implementing transparent deployment procedures. Many development frameworks now include automatic verification tools that publish source code during deployment, making contract authenticity easier to verify. Developers seeking audited smart contract templates should primarily use the OpenZeppelin Contracts library, which provides battle-tested implementations of common standards like ERC-20 tokens, ERC-721 NFTs, and access control mechanisms. OpenZeppelin maintains the most widely used collection of audited smart contract components, with implementations that have undergone multiple security audits and real-world testing [96]. The OpenZeppelin Contracts Wizard provides an interactive interface for generating customised contracts based on these audited templates. The auditing process has evolved beyond manual code review to include automated analysis tools. A recent survey by Hejazi and Lashkari identified 256 smart contract vulnerability detection tools developed between 2018 and 2024, categorised by methodologies including fuzzing, symbolic execution, machine learning, and formal verification [97]; see also Section 7. These tools can detect common vulnerabilities like integer overflows, reentrancy issues, and access control problems, but they struggle with complex logic errors and business logic vulnerabilities.

Machine learning and AI techniques are increasingly used in smart contract auditing, though with important limitations. AI-powered tools excel at identifying known vulnerability patterns and can process large codebases quickly, but they often produce false positives and miss context-dependent security issues. Recent research shows that while AI can automate initial vulnerability scanning, human expertise remains necessary for understanding business logic flaws and attack vector combinations [98].

Common smart contract vulnerabilities fall into several categories based on analysis of real-world incidents. Access control issues remain the most financially damaging, often involving missing or incorrect permission checks that allow unauthorised users to execute privileged functions. Logic errors include incorrect mathematical operations, flawed state transitions, and improper handling of edge cases. Reentrancy vulnerabilities occur when external contract calls allow malicious actors to re-enter functions before state updates complete. Flash loan attacks exploit the temporary nature of uncollateralized loans to manipulate protocol states within single transactions [95].

Input validation problems create opportunities for attackers to provide malicious data that causes unexpected contract behaviour. Price oracle manipulation involves attacking external data sources that smart contracts rely on for price information. Unchecked external calls can fail silently, leading to incorrect assumptions about transaction success. These vulnerability categories reflect patterns observed across thousands of deployed contracts and billions of dollars in losses. The development ecosystem has responded with improved tools and practices, but adoption remains inconsistent. Formal verification methods can mathematically prove contract correctness for specific properties, though they require specialised knowledge and serious development time. Static analysis tools can identify potential vulnerabilities during development, while dynamic testing frameworks enable comprehensive testing of contract behaviour under various conditions. Educational resources and security frameworks continue to evolve. The OpenSCV taxonomy provides a hierarchical classification system for smart contract vulnerabilities, helping developers understand attack patterns and implement appropriate defences [99]. Industry groups have developed security checklists and best practice guides, though keeping pace with new attack vectors remains challenging.

Smart contract security requires a multi-layered approach combining secure coding practices, comprehensive testing, automated analysis tools, professional audits, and ongoing monitoring. The immutable nature of blockchain deployment makes prevention much more valuable than attempted remediation, placing a premium importance on security measures during the development phase. The cost of security failures, measured both in financial losses and in damaged reputation, justifies investing in proper security practices for smaller projects.

5. Privacy-Improving Technologies for Permissionless Blockchains

Privacy-enhancing technologies for permissionless blockchains fall into three categories: cryptographic techniques that hide transaction content (Section 5.2, Section 5.3, Section 5.4 and Section 5.5), architectural approaches that restrict visibility (Section 5.3), and operational practices that distribute trust (Section 5.1). We evaluate each approach’s privacy guarantees, performance trade-offs, and deployment barriers.

5.1. Multi-Signature Technique

Multisignature wallets distribute transaction control across multiple keyholders, requiring several parties to approve before funds can move. Instead of a single private key controlling assets, a multi-sig setup enforces collective authorisation at the protocol level. Common configurations include 2-of-3 or 3-of-5 schemes, where a subset of keyholders must sign each transaction.

This approach addresses several privacy and security concerns in blockchain systems. When one keyholder’s device gets compromised or one party acts maliciously, attackers cannot drain funds without obtaining additional signatures. The arrangement also obscures which specific participants authorised each transaction: observers see that multiple signatures validated the payment, but cannot determine which subset of keyholders actually cooperated. Multi-sig wallets have become standard infrastructure for DAOs, protocol treasuries, and institutional custody. Projects like Gnosis Safe dominate the Ethereum ecosystem, managing billions in treasury assets. The scheme protects against both external attacks and internal malfeasance, making it suitable for scenarios where trust must be distributed among multiple parties.

Modern implementations use threshold signature schemes [100] that appear identical to single-signature transactions on-chain. Bitcoin’s Taproot upgrade and threshold ECDSA protocols allow multiple parties to cooperatively generate signatures without revealing the multi-party nature of the authorisation. This reduces transaction costs and improves privacy compared to traditional multi-sig scripts, where the number of required signatures is visible in transaction data.

The operational challenges involve coordination overhead and key recovery. Each additional required signature increases the complexity of executing transactions. Organisations using 5-of-9 schemes must coordinate among five people for every payment, introducing delays. Transaction fees scale with signature count, making high-threshold configurations expensive for frequent operations. If enough keyholders lose access to their keys, the funds become permanently locked, yet distributing key material broadly increases exposure to compromise.

5.2. Zero-Knowledge Proofs

Zero-knowledge proofs allow one party to prove that they know something without revealing what they know. In blockchain contexts, this means that users can prove the validity of the transaction, the ownership of the assets, or the compliance with the rules without exposing the underlying data. A prover demonstrates knowledge of secret information to a verifier, who becomes convinced of the claim’s truth while learning nothing about the secret itself. The technology addresses fundamental privacy limitations in public blockchains. Bitcoin and Ethereum transactions expose amounts, addresses, and transaction graphs to anyone running a node. Zero-knowledge proofs break this transparency by allowing verification without disclosure. Users can prove they have sufficient funds to make a payment without revealing their balance, or demonstrate membership in a group without identifying which member they are.

Two main proof systems dominate blockchain applications. zk-SNARKs produce small, quickly verifiable proofs regardless of computation complexity. Groth16, the most widely deployed zk-SNARK construction, generates proofs of only 192 bytes that verify in under 10 milliseconds. This efficiency made zk-SNARKs practical for blockchain integration, where every byte costs gas and every verification must be fast. Zcash pioneered its use for private transactions, hiding sender, receiver, and amount while still allowing network validation. The drawback of zk-SNARKs involves the trusted setup ceremony. Generating the proving and verification keys requires creating and destroying secret randomness. If this toxic waste leaks, attackers could forge proofs and create counterfeit assets. Projects address this through multi-party computation ceremonies where hundreds of participants contribute randomness, requiring only one honest participant to maintain security. Zcash is Powers of Tau ceremony involved over 200 contributors across multiple rounds.

zk-STARKs eliminate trusted setup requirements through different cryptographic foundations. These proofs rely on hash functions and information-theoretic security rather than elliptic curve assumptions, making them resistant to quantum computers. STARKs generate larger proofs than SNARKs but scale better for complex computations. StarkWare uses them for Ethereum Layer 2 scaling, batching thousands of transactions into a single proofs that verify on the mainnet.

Current Ethereum scaling solutions demonstrate zero-knowledge proofs’ practical impact. zkSync, Polygon zkEVM, and Scroll use zero-knowledge rollups to process transactions off-chain while posting validity proofs on-chain. These systems batch thousands of transactions into one proof, reducing gas costs by over 90% compared to individual mainnet transactions. Users get near-instant finality and lower fees while maintaining Ethereum’s security guarantees.

The computational demands remain substantial. Generating proofs for the complex circuits that zero-knowledge techniques need requires powerful hardware, often GPUs or specialised ASICs. Modern zkEVM circuits contain millions of constraints, with memory requirements exceeding standard consumer hardware. Projects operate dedicated proofing infrastructure, introducing centralisation risks for the few entities that can afford to generate proofs. Research continues on proof aggregation and recursive composition to distribute this computational burden more effectively.

5.3. Permissioned Frameworks: Hyperledger Fabric

Hyperledger Fabric addresses permissionless blockchain privacy concerns through a fundamentally different architectural approach, implementing permissioned network structures where membership service providers authenticate all participants before network access. This design enables granular privacy controls through channel-based data segregation, restricting transaction visibility to authorised organisations while implementing private data collections for sensitive information that requires additional access controls. The endorsement policy framework requires transaction validation from specified peer organisations before ledger commitment, ensuring that smart contract execution occurs within isolated environments that prevent cross-contract information leakage and unauthorised data access.

The PnR architecture proposed by Banach demonstrates how Hyperledger Fabric can enforce privacy through structural mechanisms rather than relying solely on rewards for honest behaviour [24]. The Hyperledger architecture implements a two-organisation deployment where each organisation operates distinct peer types within a management layer. Organisation peers include anchor peers that maintain network topology, endorser peers that execute and validate transactions through chaincode, and general peers that maintain ledger copies. Membership service providers authenticate participants at each peer and manage cryptographic certificates. Channels connect peers across organisations, creating isolated communication pathways that restrict information flow to authorised parties. The ordering service receives endorsed transactions and organises them into blocks before distributing them to channel members. Client applications interact with the network through SDKs or REST APIs, enabling transaction submission and ledger queries. This layered structure allows organisations to maintain privacy boundaries while participating in shared consensus, as transactions remain visible only to channel participants rather than the entire network). The punishment mechanism operates through smart contract enforcement and controlled revocation of anonymity. When participants violate network policies, the system can either deny service access or revoke pseudonymous protections, revealing the identity behind malicious actions. This approach differs from traditional blockchain incentive structures, which reward block creation, in that it focuses on deterrence through accountability. The chaincode deployed at endorser peers evaluates transaction validity against predefined policies before endorsement, creating multiple checkpoints where improper behaviour can be detected and prevented.

Recent developments in the Hyperledger Fabric ecosystem reflect both growing pains and continued evolution. The platform reached a milestone with the release of version 3.0 in 2024, introducing improved performance and new features [101]. However, the landscape has shifted, with Visa departing from the consortium and the Linux Foundation discontinuing its Hyperledger Fabric developer courses. Despite these changes, development continues, with Chainlink joining the ecosystem to explore enterprise blockchain integration. Performance analysis by Yu et al. demonstrates that endorsement strategy optimisation can improve transaction throughput, with their proposal distribution algorithm reducing latency in high-load scenarios [102]. Healthcare implementations have shown promising results, with Al-Sumaidaee et al. achieving sub-second transaction times in private network deployments, though scalability remains constrained by the endorsement process [103]. Ke and Park’s performance modelling reveals that transaction throughput scales linearly up to a threshold determined by endorser capacity, after which the system experiences degradation due to cryptographic verification overhead [104].

Practical deployment challenges emerge from the permission model itself. Nedaković et al. implemented a healthcare trust relations system and identified coordination overhead as a major bottleneck, particularly when multiple organisations must reach consensus on transaction endorsement [105]. Latency modelling by Abang et al. in IoT contexts shows that network topology and peer placement can introduce milliseconds to seconds of delay, making real-time applications difficult without careful architecture design [106]. Multimedia applications face particular challenges, as Sharma et al. discovered that large file storage requires off-chain solutions, with Fabric maintaining only metadata references to external storage systems [107].

Fabric’s modular consensus architecture allows organisations to select appropriate ordering mechanisms without compromising privacy requirements, while recent Fabric 2.x and 3.0 implementations introduce certificate-based identity management and hardware security module integration for enhanced cryptographic operations. Organisations can implement zero-knowledge proofs within chaincode to verify claims without revealing underlying data, creating hybrid systems that combine the benefits of permissioned networks with advanced cryptographic privacy techniques, while this approach provides strong privacy guarantees within consortium environments, it fundamentally alters the permissionless nature of traditional blockchain networks and may not be suitable for applications requiring open participation and decentralised governance. The platform’s future remains tied to enterprise adoption patterns, where privacy requirements often outweigh the philosophical preference for permissionless access.

5.4. Ring Signatures

Ring signatures allow someone to sign a message on behalf of a group without revealing which group member created the signature. Anyone examining the signature knows it came from one of the group members, but cannot determine which one. This provides anonymity within the group: if ten people form a ring, each member has plausible deniability, since the signature could have come from any of them. The mechanism works by combining the public keys of all group members into a cryptographic structure in which the actual signer uses their private key along with the public keys of other members. The result proves that someone in the group authorised the message, but the proof itself reveals nothing about who specifically signed. All ring members appear equally likely to be the signer based on cryptographic evidence.

Monero uses ring signatures as its primary privacy mechanism. When Alice sends a transaction, her real output gets mixed with several decoy outputs from other users’ past transactions. The ring signature proves that Alice controls one of these outputs without identifying which one. Observers see that some output in the ring got spent, but cannot determine whether it was Alice’s or one of the decoys. Linkable ring signatures extend the basic concept to prevent double-spending while preserving anonymity. Each private key generates a unique key image when it is used to create a signature. If someone tries to spend the same output twice, both transactions produce identical key images, allowing nodes to reject the duplicate. The key image itself does not reveal which ring member was signed, but its uniqueness prevents reuse. This solves the double-spend problem without requiring transaction transparency. Monero’s CLSAG protocol improved ring signature efficiency by reducing the signature size by 25% compared to earlier schemes. Smaller signatures mean lower transaction fees and reduced blockchain bloat. The verification process also became faster, allowing the nodes to validate transactions more efficiently. These improvements matter for network scalability: As the transaction volume grows, efficient cryptography becomes necessary to keep the system usable.

Ring size directly affects privacy strength. Larger rings provide better anonymity, since each member represents a smaller fraction of possible signers. A ring of 16 means each member has 6.25% probability of being the signer from an observer’s perspective, while a ring of 100 provides 1% probability. However, larger rings increase transaction size, verification time, and fees. Monero currently uses rings of 16 as a balance between privacy and practicality. The anonymity set only includes other blockchain users who could plausibly be involved in the transaction. If an attacker controls most of the decoy outputs, they can deduce which output was real through elimination. Network-level analysis can also narrow the possibilities by correlating transaction timing and amounts. Ring signatures provide strong privacy guarantees, but work best when combined with other protections like Tor usage and avoiding amount correlation.

Recent research explores post-quantum ring signatures resistant to quantum computer attacks, though these constructions produce larger signatures and slower verification; See Section 8. Integration with confidential transactions that hide amounts remains an active development area, as combining multiple privacy techniques introduces complexity in proof construction and verification.

5.5. Stealth Addresses

Stealth addresses prevent address reuse by generating a unique, one-time address for each transaction while allowing the recipient to control all funds with a single private key. This breaks the link between payments that would otherwise be visible on-chain when multiple senders pay the same public address.

The recipient publishes a master stealth address—essentially a public identifier that never appears in actual transactions. When someone wants to send funds, they use this master address to derive a fresh, one-time address that only the intended recipient can access. Each payment creates a different on-chain address, so observers cannot tell that multiple transactions went to the same person. The blockchain shows payments to seemingly unrelated addresses, masking the recipient’s transaction history. The cryptographic mechanism relies on elliptic curve key derivation. The sender generates random data and combines it with the recipient’s public information to create a shared secret that only the sender and recipient can compute. This shared secret derives both the one-time payment address and the corresponding private key needed to spend those funds. The sender publishes the random data alongside the payment, allowing the recipient to scan the blockchain, recognise payments intended for them, and compute the necessary private keys.

Monero pioneered stealth addresses as a core privacy feature, making them mandatory for all transactions. Every Monero payment goes to a unique address that appears unconnected to the recipient’s public identity. This prevents address clustering and transaction graph analysis that plague Bitcoin’s transparent ledger. Ethereum adoption has been slower due to wallet complexity and gas costs. The ERC-5564 standard provides a framework for stealth addresses on EVM chains, with Umbra Protocol implementing the specification across the Ethereum mainnet and several Layer 2 networks. Since launch, Umbra has processed over 12,000 stealth transactions, demonstrating demand for recipient privacy despite added complexity.

The main operational challenge involves scanning. Recipients must check every transaction to see if it was meant for them, computing shared secrets and comparing derived addresses against on-chain data. This becomes computationally expensive as transaction volume grows. View tags [108] optimise this process by including a single-byte hint with each payment. Recipients check the view tag first—a trivial computation—and only perform expensive elliptic curve operations when the tag matches. This reduces scanning overhead by over 95%, making regular monitoring practical. Wallet integration remains the biggest barrier to adoption. Users must understand that stealth addresses require scanning and that funds appear in different addresses each time. Most wallet software lacks built-in support, forcing users to rely on tools. The user experience degrades compared to simple address reuse, though the privacy benefits are substantial.

Stealth addresses work best combined with other privacy techniques. They hide the recipient but not the amount or sender. Pairing them with confidential transactions that encrypt amounts and ring signatures that obscure senders would provide comprehensive privacy. Monero demonstrates this approach, while Ethereum implementations focus on recipient privacy as a first step toward broader confidentiality.

5.6. zkEVM Scaling Solutions

The zkEVM implementations represent a convergence of Ethereum Virtual Machine compatibility with zero-knowledge proof verification, offering enhanced privacy and scalability through cryptographic computation verification rather than optimistic fraud proofs. Polygon zkEVM processes transactions in EVM-compatible execution environments before generating validity proofs for Ethereum mainnet verification, employing a hybrid proving system that uses STARKs for computation verification and SNARKs for final proof compression to optimise both security and efficiency. Batch sizes of 1000–10,000 transactions generate single proofs [109] consuming approximately 300,000 gas for verification, reducing individual transaction costs by 90–95% compared to Ethereum mainnet execution while maintaining identical security guarantees through mathematical proof verification.

zkSync Era implements EVM compatibility through a custom virtual machine design supporting Solidity and Vyper languages, processing over 2000 transactions per second with finality times under 10 min and achieving total value locked exceeding $1.1 billion by Q3 2024. The architecture demonstrates practical adoption of zero-knowledge scaling while maintaining developer familiarity and tooling compatibility. Privacy features emerge naturally through transaction batching, where individual operations become computationally indistinguishable within proof aggregation, preventing correlation of specific transactions to senders without additional metadata analysis. Future implementations may integrate stealth addresses and confidential transaction amounts for enhanced privacy guarantees, creating comprehensive privacy-preserving execution environments.

Computational requirements for proof generation necessitate specialised hardware infrastructure, with modern zkEVM deployments requiring 64GB+ RAM and dedicated GPU acceleration for practical proof generation times. However, verification costs remain constant regardless of batch size, creating substantial economies of scale for high-throughput applications and enabling cost-effective privacy-preserving computation at scale.

6. Secure Development Lifecycle for Blockchain Systems

The gap between academic research on blockchain privacy and practical implementation often widens due to inadequate security practices during the development lifecycle. Projects that understand privacy risks theoretically still fall victim to attacks because they fail to implement proper security controls from the earliest stages of development. The Web3 ecosystem encompasses diverse infrastructure components and applications [110], each presenting unique security challenges at the system, developer, and user levels [111]. As Web3 technologies evolve beyond simple blockchain applications to encompass decentralised autonomous organisations, non-fungible tokens, and complex financial protocols [112], the importance of structured security practices becomes paramount [113]. Building on the security practice framework established by SlowMist [114], we outline a structured approach that researchers and development teams should consider when building permissionless blockchain applications. Fuzzing tools like Echidna [115] and Foundry [116] can automatically generate test cases that explore edge conditions developers might miss.

Table 3. Secure Development Lifecycle Framework for Blockchain Systems.

Phase	Security Activities	Blockchain Controls	Measurable Outcomes
Preparation	Isolated environments; hardware wallets for production; credential exclusion from version control	Multi-signature deployment approval; automated credential scanning; hardware device signing	Zero production keys in repositories; hardware wallet adoption rate; multi-signature coverage
	Threat modeling: attack surfaces including phishing, signature hijacking, MEV exploitation; on-chain and off-chain trust boundaries	Framework support for hardware wallet integration	Documented threat surfaces; framework security features enabled
Development	Audited smart contract libraries; checks-effects-interactions pattern; access control mechanisms; input validation	Overflow protection (Solidity 0.8+); property-based fuzzing; boundary condition testing	Audited library adoption ratio; access control coverage; fuzzing test coverage
	Content Security Policy headers; input sanitization; transaction preview with decoded parameters; RPC response validation	External data verification; calldata decoding before signature requests	CSP implementation status; validation coverage
	Transport security; request rate limiting; dedicated RPC infrastructure; network segmentation	Self-hosted nodes prevent metadata leakage; transaction routing with MEV protection	Dedicated infrastructure adoption; rate limiting effectiveness
Release	Code freeze period; external security audit; critical and high-severity finding remediation; regression testing	Protocol economic model verification; game-theoretic assumption validation	Critical findings resolved; code freeze duration (days)
	Incremental deployment; contract address verification on block explorers; source code publication; emergency pause mechanisms	Pause and upgrade path testing under realistic network conditions	Contract verification completion time; source publication status
Runtime	Permission change monitoring; large value transfer alerts; anomalous transaction pattern detection; malicious address interaction tracking	Upgradeable contract state monitoring; transaction flow analysis	Median detection latency; false positive rate; monitored attack vector coverage
	Infrastructure security updates; access control enforcement; automated balance reconciliation	Component isolation; continuous state verification	Critical vulnerability patch time; reconciliation frequency
	Vulnerability disclosure programs; pre-authorized emergency response; pause and upgrade capabilities	Economic incentive alignment for responsible disclosure	Median incident containment time; disclosure versus exploitation ratio
Awareness	User education on signature authorization risks and social engineering; ecosystem vulnerability tracking; periodic security exercises	Proactive vulnerability assessment following ecosystem incidents	Security drill frequency; incident-to-review response time

Framework phases incorporate measurable security controls enabling quantitative maturity assessment. Common tool implementations include git-secrets for credential scanning [117], Echidna and Foundry for property-based fuzzing [115,116], OpenZeppelin for audited contract templates [96], and Hardhat or Foundry as development frameworks [116,118].

illustrates the structured development lifecycle framework.

The foundation of secure Web3 development begins with the proper configuration of the environment and key management practices. Developers face immediate security decisions when setting up local development environments, particularly regarding how to handle private keys, API credentials, and contract addresses. The common practice of storing sensitive credentials in .env files presents different risk levels depending on what information gets stored.

Table 4. Role Responsibility Matrix for Key Security Controls.

Control Point	Developer	Security	Operations	Lead
Environment setup, credential scanning	R	A	C	I
Hardware wallet deployment integration	R	C	A	I
Threat model documentation	C	R	C	A
Contract security patterns	R	A	I	I
Fuzzing and adversarial testing	R	A	I	I
Infrastructure hardening, RPC nodes	I	C	R	I
External audit coordination	C	A	I	R
Code freeze decision	I	C	I	R
Deployment execution	C	C	R	A
Monitoring system deployment	C	R	A	I
Incident response execution	C	R	A	R
Quarterly security drills	C	R	C	A

R = Responsible (executes), A = Accountable (approves), C = Consulted (advises), I = Informed (notified) following standard RACI framework [119]. Most organisations adapt this based on team size.

assigns these security responsibilities across development teams using the RACI framework.

Smart contract addresses can safely appear in environment files since deployment makes them public regardless. However, private keys and deployment credentials must never exist in .env files or any version-controlled code. A single accidental commit containing private keys to a public repository can lead to immediate fund drainage: automated bots scan GitHub commits for exposed private keys and drain associated wallets within minutes of exposure. Production deployments require hardware wallets or dedicated key management services. Development and testing should use separate keys with minimal funds, isolated from any production assets. The Hardhat [118] and Foundry [116] development frameworks support hardware wallet integration for deployment scripts, allowing developers to sign transactions without exposing private key material to the development environment.

Requirements documentation at this stage should specify threat models, trust assumptions, and security boundaries before any code gets written. Projects need clear documentation of what data should remain private, which components handle sensitive information, and where trust boundaries exist between on-chain and off-chain systems. Business process documentation should map user flows through security-critical operations, identifying points where users face risks from phishing attacks, signature hijacking, or malicious contract interactions. Role-based enforcement of these controls requires clear allocation of responsibilities across development, security, operations, and leadership teams. This is shown in

Table 5. Role-by-Control-Point Matrix for SDLC.

Control Point	Developer	Security	Operations	Lead
Preparation Phase
Environment configuration	R	C	A	I
Credential management	R	A	C	I
Threat model definition	C	R	I	A
Framework selection	R	C	I	A
Development Phase
Smart contract implementation	R	C	I	I
Unit test development	R	C	I	I
Code review	C	R	I	I
Fuzzing campaigns	I	R	I	I
Static analysis	C	R	I	I
Infrastructure hardening	I	C	R	I
Release Phase
Code freeze enforcement	I	C	I	R
External audit coordination	C	A	I	R
Vulnerability remediation	R	A	I	I
Staging deployment	C	C	R	A
Mainnet deployment approval	I	C	I	R
Contract verification	C	R	A	I
Runtime Phase
On-chain monitoring	C	R	A	I
Infrastructure monitoring	I	C	R	I
Incident detection	C	R	A	I
Emergency response execution	C	R	A	R
Balance reconciliation	C	C	R	I
Post-incident analysis	C	R	C	A
Continuous Improvement
Security drill coordination	C	R	C	A
Bug bounty management	I	R	I	A
Ecosystem threat tracking	C	R	C	I

Responsibility codes: R = Responsible (performs the work), A = Accountable (final authority and approval), C = Consulted (provides input), I= Informed (kept updated). This RACI framework follows standard project management methodology [119].

.

6.1. Development Process and Smart Contract Security

Smart contract development introduces unique security challenges due to code immutability and the transparent nature of blockchain execution. The Web3 development paradigm shifts from traditional centralised architectures to decentralised systems where toolkits and frameworks enable efficient innovation despite distributed information [113]. Security considerations must be integrated into the coding process itself rather than being added as an afterthought. Using audited libraries like OpenZeppelin Contracts provides battle-tested implementations of common patterns, reducing the risk of introducing novel vulnerabilities. However, the evaluation of Web3 applications reveals that existing implementations often fall short on security and adoptability as claimed [111], necessitating rigorous development practices.

Security coding requirements should enforce defensive patterns from the start. This includes Check Effects Interactions to prevent reentrancy, proper access control on privileged functions, input validation on all external calls, and careful handling of arithmetic operations to prevent overflow and underflow issues. Solidity version 0.8.0 introduced automatic overflow checks, but developers must still test edge cases involving zero values, maximum token approvals, and unusual input combinations. The test case requirements extend beyond functional correctness to include adversarial scenarios. Unit tests should attempt to exploit potential vulnerabilities by calling functions with extreme values, trying to reenter contracts, testing authorisation bypasses, and simulating malicious contract interactions. Fuzzing tools like Echidna and Foundry’s fuzzer can automatically generate test cases that explore edge conditions developers might miss.

Front-end security matters as much as contract code. Web interfaces represent the primary attack surface for most users, who interact with contracts through browser-based applications rather than directly. Configuration requirements should enforce Content Security Policy headers, implement proper input sanitisation to prevent cross-site scripting, validate all data from external sources, including RPC responses, and use secure random number generation for any cryptographic operations. The interface should clearly display transaction details before signature requests, helping users identify signature hijacking attempts. Smart contract security coding requirements should enforce defensive patterns from the start. Blockchain-based verification systems have been applied to integrity verification in educational platforms [120], demonstrating lightweight approaches to content authentication.

Server environments hosting front-ends or running backend services need hardening against common attack vectors. This includes properly configured HTTPS, secure headers, rate limiting to prevent denial of service, and isolation between different components. RPC endpoint selection matters—projects should run their own nodes when possible rather than relying entirely on third-party providers that can log IP addresses and transaction patterns.

6.2. Release Process and Security Auditing

The release phase represents the last opportunity to catch vulnerabilities before deployment to the mainnet. Code freeze requirements prevent last-minute changes that could introduce bugs or bypass previous testing. Regression testing ensures that bug fixes did not break existing functionality or introduce new vulnerabilities. Test coverage should include all critical paths through the contract code, with particular attention to functions handling value transfers or permission changes. Reputable security audits provide external validation of contract security. However, audits have limitations—they represent snapshots in time and cannot guarantee the absence of vulnerabilities. Projects should provide auditors with comprehensive documentation of intended behaviour, known limitations, and areas of particular concern. The audit process works best when auditors have time to thoroughly review code rather than rushing to meet deployment deadlines.

Audit reports often identify issues ranging from critical vulnerabilities to gas optimisation opportunities. Teams must address critical and high-severity findings before deployment. Medium and low-severity issues require judgment calls about risk versus deployment timeline pressure. The temptation to deploy despite audit findings has led to numerous exploits where known vulnerabilities were ignored due to competitive pressure or overconfidence.

6.3. Runtime Monitoring and Incident Response

Deployment does not end security responsibilities—runtime monitoring becomes essential for detecting attacks in progress or identifying suspicious activity before major losses occur. Smart contracts require different monitoring approaches than traditional software since on-chain activity is permanently visible, but off-chain systems may need protection from unauthorised access. Runtime security monitoring should track permission changes in contracts with upgradeable components, watching for unauthorised calls to privileged functions. Fund movements need monitoring through alerts on large transfers, unusual transaction patterns, or interactions with known malicious addresses. Periodic reconciliation between expected and actual balances can identify discrepancies from accounting errors or exploitation attempts.

Environment hardening protects the infrastructure supporting blockchain applications, while smart contracts run on the decentralised network, supporting services like RPC endpoints, indexers, and front-end hosting require traditional security measures. Regular updates, access controls, and network segmentation reduce the attack surface on these centralised components.

Bug bounty programs incentivise security researchers to report vulnerabilities rather than exploit them. Platforms like Immunefi host bug bounties for blockchain projects, offering rewards scaled to vulnerability severity. Well-structured bounties specify scope, provide clear reporting channels, and commit to response timeframes. The payout structure should make responsible disclosure more profitable than exploitation for most researchers. Emergency response procedures need definition before incidents occur. Response teams should have pre-authorised access to pause mechanisms, upgrade capabilities, or other incident response tools. The decision-making process during emergencies must balance speed against avoiding panic-driven mistakes. Clear communication channels allow coordination between developers, security teams, and community members during crises. Stop-loss disposal requirements limit damage when breaches occur—pausable contracts allow emergency halts while teams assess the situation, though pause mechanisms themselves become targets if not properly protected.

Post-incident procedures should document tracking requirements for understanding attack vectors, problem-solving processes for implementing fixes, and security release protocols for deploying patches. Issue analysis determines root causes and identifies similar vulnerabilities elsewhere in the codebase.

6.4. Security Awareness and Continuous Improvement

Security awareness cultivation extends beyond the immediate development team to include all stakeholders in a Web3 project. The Web3 ecosystem faces challenges at multiple levels—including system-level issues related to infrastructure reliability, developer-level challenges around tooling and standards, and user-level concerns about usability and security [110]. Understanding these challenges requires recognising Web3 as an evolving technological landscape where decentralisation, blockchain integration, and user empowerment create both opportunities and risks [112,121]. Users need to be educated about signature verification, the risks of contract interactions, and how to identify phishing attempts. Many attacks succeed not through technical exploitation but through social engineering of users who approve malicious transactions.

Tracking security incidents across the broader ecosystem provides early warning of emerging attack patterns. When one project suffers a specific type of exploit, similar projects should immediately audit their code for the same vulnerability class. Attack techniques spread quickly after the first flash loan attack, many projects discovered they were vulnerable to the same approach. Security awareness assessment and drills prepare teams for various threat scenarios, revealing gaps in monitoring or response capabilities before real incidents occur. The integration of these security practices throughout the development lifecycle addresses many of the privacy and security concerns discussed in earlier sections. Proper key management prevents private key theft, which accounts for most blockchain security losses. Smart contract security practices mitigate the risks from vulnerable contract code. Runtime monitoring enables early detection of the MEV attacks, dust attacks, and signature hijacking attempts that target users. This structured approach bridges the gap between understanding privacy risks theoretically and implementing robust defences in production systems.

Security awareness cultivation extends beyond the immediate development team to include all stakeholders in a Web3 project. Users need education about signature verification, the risks of contract interactions, and how to identify phishing attempts. Many attacks succeed not through technical exploitation but through social engineering of users who approve malicious transactions.

Tracking security incidents across the broader ecosystem provides early warning of emerging attack patterns. When one project suffers a specific type of exploit, similar projects should immediately audit their code for the same vulnerability class. Attack techniques spread quickly across the ecosystem. After the first flash loan attack, many projects discovered they were vulnerable to the same approach.

The SDLC framework requires measurement to demonstrate effectiveness. Projects can track detection latency by recording the time from vulnerability introduction to discovery. The 2024 incident data shows that automated monitoring reduced median detection times from 19 h to 11 min for unauthorised privilege escalation attempts [22]. Response effectiveness can be measured through quarterly drills that simulate attacks and record time-to-containment. The October 2024 Permit2 attacks demonstrated this clearly: projects with pre-authorised pause mechanisms contained incidents within 8–15 min and limited losses to under 5% of total value, while projects lacking these capabilities saw complete fund drainage [92]. Pre-deployment metrics also correlate with outcomes. Projects with external audits covering more than 75% of critical functions experienced 68% fewer exploits in their first six months compared to projects with limited or no audit coverage [22]. These metrics, linked to the threats identified in Section 4 and shown in Table 3 and Table 4, help teams assess whether their security investments actually reduce risk.

7. Formal Approaches to Blockchain Security Concerns

When important concerns like security and privacy are delegated to software, the functional correctness of the software is of primary concern. This is of high importance in the wider world, but is even more pressing in the world of blockchain. In the wider world, if a piece of software proves to be faulty, it can normally be replaced with an improved version, perhaps at some, even considerable, cost, but the process of replacement nevertheless mitigates the damage that the faulty version gave rise to. In the blockchain world, once a smart contract is deployed on-chain, it quickly becomes immutable, and any faults it contains get set in stone. A range of problems this causes has been discussed earlier in the paper. Worse, if the blockchain protocol itself is flawed in some way, there is little that can be done once the blockchain itself has attracted sufficient traction. All the attacks around value extraction discussed earlier in the paper are based on exploiting fundamental features of the relevant protocol, are therefore consigned to be ‘facts of life’ barring a hard fork in the relevant protocol.

One approach that addresses these issues is the verification of software using formal techniques. Formal methods, as they are generically known, emerged to address the so-called software crisis in the very late 1960s, growing through the 1970s, and by now encompass a large range of specific techniques which can get applied at all levels of the development stack. The literature is by now huge. A good perspective on the field can be gained from recent major conferences, such as the most recent edition of the Formal Methods Conference [122].

Formal verification techniques aim to avoid errors before the fact’, by proving that the system under scrutiny does not have them. This is a big challenge because one has to be able to know what is correct and what is erroneous, and, given the system in question or a model of it, one has to be able to correctly find errors while simultaneously avoiding misidentifying either correct or erroneous features of the system or its model.

The survey [123], in [122], gives a timely overview of the wide variety of approaches to the verification problem that have been developed by now. The key fact that makes the field difficult is that almost all questions that one might ask in the hope of gaining useful information about a candidate system are undecidable. So the best that we can hope for is to obtain partial answers. The consequences of this are discussed in detail in [123].

It is fair to say that the deployment of formal methods techniques to address the problems inherent in the world of blockchain can be described as one of the niche application areas of formal verification. Various key areas within the blockchain world can be identified as specific focus topics for formal verification. Two key areas stand out.

The first of these is the verification of the virtual machine that supports the protocol of some given blockchain of interest. Several such works are available in the literature, for instance [124,125,126,127,128,129]. Given its popularity and wide adoption, it is not surprising that Etherium and the Etherium Virtual Machine specifically, have been the focus of much attention and figure prominently among these. The Financial Cryptography and Data Security conferences showcase much contemporary work in this area.

The second key area is the verification of smart contracts. This stands in contrast to the verification of virtual machines and protocols. The verification of virtual machines and protocols can be understood as a relatively well defined problem, in the sense that any given protocol is required to achieve some quite tightly defined objectives, and a lot of the objectives that different protocols are intended to meet are relatively similar across the range of different protocol types. By contrast, the challenge with smart contracts is that they may be required to meet any number of objectives that are taken from the application domain, i.e., that are user-defined. Since the remit of possible application domains is extremely large, a ‘one size fits all’ approach to smart contracts verification is infeasible, and an application-specific approach is needed. In [130], there is a survey of the application of formal techniques to smart contracts, mirroring the landscape set out in [123]. As is to be expected, Ethereum atracts the most interest, see e.g., [131,132]. And representative of the broader scope of smart contract verification are works such as [129,133,134].

The application of formal methods to security concerns, such as privacy, raises a whole new set of questions that mere conformance to functional correctness—as for virtual machines, protocols or smart contracts—has no need for, while the development of functional correctness of a protocol or contract has to assure that correct behaviour is not spoiled by the lower-level detail that is introduced during development, conformance to security concerns has to ensure that, during development, the lower level detail that is introduced, does not leak additional security-critical information, even if the development is in all other functional respects, completely correct. This is a considerable additional challenge that many Formal techniques are unable to address ‘out of the box’. A comprehensive survey of formal techniques applied to security concerns can be found in [135], and it emphasises that formal methods, rigorous as they are are, cannot find errors or vulnerabilities of a type that have not been imagined. This observation is not restricted to the formal world, of course. The security of digital systems would not be the arms race that it currently is if it were possible to prove, once and for all, that a system is perfectly secure. And this applies in no less measure to privacy concerns in blockchain. For a survey of current approaches to security in blockchain using formal approaches see [136].

The preceding comments notwithstanding, the fast pace of innovation in blockchain implies that the proportion of the blockchain ecosystem that is subjected to formal techniques is rather small. Developers on the whole tend to not be users of such techniques. However, the preceding sections have mentioned a small number of key areas in which key systems have been subjected to formal verification.

8. Quantum Threats to Blockchain Security

Since the invention of Shor’s algorithm for polynomial-time factoring of large numbers in 1994 [137,138], the previously sleepy niche world of quantum computing was set ablaze in 1994. Interest has been rife in the development of quantum computers that will undermine the security of most of what takes place on the internet. Unfortunately (or fortunately, depending on one’s point of view), laboratory physics has been less enthusiastic to concur. Despite the investment of billions of dollars worldwide, there is yet to be a quantum computer that can perform at anywhere near enough the level needed for breaking RSA, DH, ECC, and other public key protocols, and the myriad applications that have been built on top of them in today’s internet.

Despite the previous observation, research into quantum secure cryptography, also referred to as post-quantum cryptography, is proceeding vigorously. The weak point of the existing cryptographic primitives, which makes them vulnerable to a quantum attack, is that they rely on a ‘hidden subgroup problem’. This means that they conceal a periodic algebraic structure whose concealment underpins the relevant security guarantee. The quantum Fourier transform is able, in polynomial time, to reveal the relevant periodicity, after which the secret it conceals can be inferred. Post-quantum Cryptography seeks to create cryptographic primitives that are not based on a hidden subgroup problem, and reassuring progress has been made. See [139] for an informal account, and [140] for a textbook presentation, though one lacking the most recent advances. By now, cryptographic primitives that are believed to be quantum-secure have been established. NIST has published standards for these with the intent of enabling smooth interworking of applications [141,142,143]. In principle, such primitives can be used to replace the current quantum-vulnerable ones, in all contexts where they need to be used. There are some performance penalties, and inevitable integration issues for production systems, but a moderate performance penalty is a small price to pay if the alternative is loss of security. Besides the relatively well-established and standardised quantum-secure primitives, many other avenues continue to be explored. Many of these are based on mathematics, behind which there is often a rich algebraic structure, which can lead to unexpected breaks. So the field is in great flux at present.

For most blockchain architectures, two basic cryptographic techniques play an important part. Firstly, there is hashing, whereby the chain of hashes that binds the chain into an immutable sequence of blocks makes the chain to all intents and purposes, immutable. By and large, hashing techniques are immune to quantum attacks, as they are not based on hidden subgroups, being instead based on large numbers of simple arithmetic and bitwise operations that create sufficient confusion to obscure the original plaintext being hashed quite effectively. Secondly, there is public key cryptography. This is used for ‘authentication at a distance’ whereby a transaction signed with a private key can be depended on by a remote party, based on the presumption that only the true owner of whatever the transaction refers to could have signed it in a way that the relevant public key can confirm. Unfortunately, this is precisely the kind of cryptography that is vulnerable to quantum attack, as it is typically based on RSA, DH, ECC, and related techniques. Breaking these primitives can not only reveal the signer’s details, but can enable the faking of public key signatures, while the doxing of blockchain actors may be unpleasant for the parties concerned, the breakdown of signature security would be catastrophic for the trust framework that justifies the use of blockchain in any event. The availability of the standardised post-quantum cryptographic primitives we have mentioned indicates that, in principle, blockchains could be re-engineered to use them in case of need.

It is clear that the quantum world does not guarantee or undermine privacy concerns in blockchain per se. Rather, the cryptographic primitives at issue are vital ingredients of complex cryptographic protocols that achieve aspects of privacy as a whole. So the risk to privacy is proportional to the risk to the cryptographic primitives involved.

For now, the prospect of the collapse of blockchain trust for quantum reasons remains relatively remote. But vigilance is prudent, and investigation of quantum-safe blockchain architectures is proceeding. Given the large amount of hype surrounding quantum computing, a large number of blog-style articles and posts can be readily found on the web. In the academic literature, too some articles may be found, e.g., [144,145,146,147]. They restate the position outlined above with more context and detail. So It is fair to say that, at present, the non-quantum threats discussed earlier in the paper poses an immediate and far greater threat to blockchain security than anything based on the quantum regime, though in the considerably longer term, that evaluation may be subject to reappraisal.

9. Discussion and Limitations

The results of this study highlight the deep interweaving of organizational design and privacy governance within permissionless blockchain ecosystems. The open and distributed nature of these systems complicates the operations involved in simultaneously implementing privacy, accountability, and compliance principles. Many blockchain organizations, from decentralized autonomous organizations (DAOs) to development foundations, still lack a formalised security and privacy management structure. The absence of defined roles for auditing, incident management, and compliance monitoring contributes to the persistence of vulnerabilities, particularly as ecosystems grow and become integrated with external financial or governmental systems.

Effective privacy governance requires rethinking the design of organisations’ Secure Development Lifecycle (SDLC). The proposed Web3-oriented SDLC model emphasises measurable controls, automated code auditing, and formal verification pipelines from design to deployment. Integrating privacy engineering practices at every stage of the lifecycle ensures a balance between data privacy and system transparency. Furthermore, explicitly assigning privacy responsibilities, such as data management, smart contract auditing, and federated analytics, can reduce fragmentation and improve accountability in decentralised environments.

From a privacy perspective, the fundamental trade-off between transparency and anonymity remains unresolved. Public ledgers inherently allow for exhaustive verification, but also permit the reconstruction of transaction graphs, deanonymization, and behavioral profiling. These challenges are amplified by the emergence of new paradigms such as cross-chain interoperability, Layer 2 solutions, and AI-powered blockchain analytics, which increase the potential for data coupling, while technologies like zero-knowledge proofs, zkEVMs, and circle signatures offer technical solutions, organisational frameworks must ensure the consistent implementation and governance of these mechanisms.

Furthermore, privacy protection cannot rely solely on cryptography. Organisational culture, reflected in developer practices, node operating policies, and community standards, plays an important role in ensuring sustainable privacy protection. Open governance models that integrate privacy-by-design principles can serve as a model for reconciling innovation and compliance. Collaborative monitoring mechanisms, such as federated learning for anomaly detection, enable the identification of threats in real time without compromising user privacy.

In short, organizational maturity and privacy protection are complementary and essential pillars for the sustainability of blockchain ecosystems. The proposed framework bridges the gap between theoretical privacy protection guarantees and their practical implementation through structured governance, continuous validation, and adaptive privacy enhancement mechanisms. This alignment between organizational responsibility and privacy engineering is a importantstep towards a secure evolution of permissionless blockchains.

10. Conclusions

Privacy remains one of the most critical issues in permissionless blockchains, while technologies such as zero-knowledge proofs, ring signatures, zkEVM, stealth addresses, and modular frameworks like Hyperledger Fabric have improved privacy protection, they still face trade-offs in performance, scalability, and developer accessibility.

This paper analysed current privacy challenges, examined major vulnerabilities across DeFi platforms, NFTs, and Layer-2 ecosystems, and outlined a practical Secure Development Lifecycle (SDLC) framework for privacy-focused blockchain development. Moving forward, research and engineering efforts should focus on creating balanced solutions that enhance privacy without weakening transparency or network efficiency. A stronger link between academic research, open-source projects, and production systems will be vital to achieving a more private, secure, and sustainable permissionless blockchain environment.