Security Assessment of Smart Contract Integration and Wallet Interaction in Decentralized Applications: A Case Study of BlockScribe

Abstract

Smart contracts and cryptocurrency wallets are foundational components of decentralized applications (dApps) on blockchain platforms such as Ethereum. While these technologies enable secure, transparent, and automated transactions, their integration also introduces complex security challenges. This study presents a security-oriented analysis of smart contract and wallet integration, focusing on BlockScribe—a decentralized Ethereum-based application for digital record certification. We systematically identify and categorize security risks arising from the interaction between wallet interfaces and smart contract logic. In particular, we analyze how user authorization flows, transaction design, and contract modularity affect the security posture of the entire dApp. To support our findings, we conduct an empirical evaluation using static analysis tools and formal verification methods, examining both contract-level vulnerabilities and integration-level flaws. Our results highlight several overlooked attack surfaces in wallet–contract communication patterns, including reentrancy amplification, permission mismanagement, and transaction ordering issues. We further discuss implications for secure dApp development and propose mitigation strategies that improve the robustness of wallet–contract ecosystems. This case study contributes to a deeper understanding of integration-layer vulnerabilities in blockchain-based systems and offers practical guidance for developers and auditors aiming to strengthen smart contract security.

1. Introduction

The growing adoption of blockchain technology [1] has allowed a wide range of decentralized applications (dApps), particularly in the domains of finance, identity management, and content ownership. Ethereum [2] is one of the most widely used blockchain platforms. It provides a robust, programmable infrastructure for creating autonomous smart contracts [3] that enforce conditions, handle assets, and define execution rules. At the heart of Ethereum’s execution layer is the Ethereum Virtual Machine (EVM) [2], a Turing-complete environment responsible for processing transactions and executing the contract logic deterministically across all network nodes. This programmability has driven the rapid expansion of Web3 technologies and tokenized systems. An important part of this ecosystem is the integration of cryptocurrency wallets [4], such as MetaMask [5] and Trust Wallet [6]. These wallets allow users to authorize transactions, manage cryptographic keys, and interact directly with on-chain contracts. These wallets have become essential tools for end users and serve as the primary bridge between client-side applications and decentralized infrastructure. In 2022, the number of users of cryptocurrency wallets surpassed 80 million worldwide, underlining their central role in the experience of blockchain users [7].

Smart contracts and decentralized applications (dApps) on Ethereum have introduced innovative ways to execute secure automated transactions. However, integrating smart contracts with browser-based wallets such as MetaMask introduces new attack vectors, including user interaction flaws, key management risks, and front-end logic vulnerabilities. This paper presents a security-oriented case study of BlockScribe, a decentralized Ethereum application (dApp) that combines Solidity-based smart contracts with MetaMask wallet interactions. We analyze practical risks that arise from this integration and identify security flaws related to access control, gas usage, user input, and cryptographic assumptions. Building on this, we propose practical design guidelines for developers building Ethereum-based dApps, particularly those involving wallet-based user authorization workflows.

However, despite the maturity of the Ethereum protocol, the integration of smart contracts with user-facing wallet interfaces continues to expose applications to significant security and usability challenges. These include phishing attacks, inadequate input validation, transaction replay issues, improper access control, and user error in private key management. Many of these vulnerabilities are not caused by flaws in the underlying blockchain itself but by misconfiguration or an oversimplified design of the application layer. The motivation for this study is the recognition that secure design practices for Ethereum-based applications remain underdocumented and inconsistently applied. In particular, developers often lack concrete guidance on how to assess and mitigate risks introduced by wallet integration, especially in browser-based web interfaces. Although many tools detect individual vulnerabilities in smart contracts, few studies holistically evaluate contract–wallet interactions in a realistic application context. This paper presents a practical and structured evaluation of the integration between smart contracts of Ethereum and wallet interfaces through a case study of BlockScribe, a prototype decentralized application designed to manage subscriptions. The overarching objective of this study is not just to analyze a single instance but to develop a generalizable security assessment framework for Ethereum-based applications that interact with cryptocurrency wallets. BlockScribe serves as a controlled, reproducible environment for testing security assumptions, identifying architectural risks, and validating mitigation strategies. The framework itself is designed to be applicable across a broad range of Ethereum dApps with similar interaction patterns. The insights derived from this case aim to inform the secure design and auditing of decentralized applications in a more general way.

Instead of proposing a new cryptographic primitive or formal verification method, this work contributes to the field by providing reproducible testing practices, code-level insights, and security recommendations derived from a complete contract–frontend workflow. The intended audience includes researchers in applied blockchain security, developers of decentralized applications, and auditors tasked with reviewing production smart contract deployments. The main contributions of this paper are as follows:

• We propose a generalizable security assessment framework for evaluating the integration of cryptocurrency wallets with Ethereum-based decentralized applications, with a focus on identifying architectural vulnerabilities in the wallet–contract interaction layer.
• We identify and examine the security risks and vulnerabilities associated with cryptocurrency wallets in web applications.
• We investigate the role of smart contracts in enhancing the security of decentralized applications, with an emphasis on how they can be used to automate trustless operations while minimizing security risks.
• We develop a prototype Ethereum-based web application, BlockScribe, to demonstrate how MetaMask and Ethereum smart contracts can be integrated effectively, followed by a comprehensive security analysis to identify key vulnerabilities and suggest solutions.
• We conduct experiments and propose best practices for developers working with Ethereum-based applications.

In Section 2, we provide an overview of the fundamental technologies behind blockchain, Ethereum, smart contracts, and cryptocurrency wallets, examining their role in enabling decentralized applications. Section 3 reviews the latest developments in Ethereum-compatible wallet architectures, highlights key attack vectors, and integrates a comparison with related academic work on smart contract security assessment. In Section 4, we present a case study of BlockScribe, a prototype Ethereum-based subscription management system, used to demonstrate common integration patterns between wallets and smart contracts. Section 5 covers the results of our empirical evaluation, including structured manual testing, static analysis with automated tools, and severity-based classification. Finally, Section 6 concludes the study with key findings and best practices and also outlines future research directions, including performance benchmarking and the broader applicability of the proposed framework across platforms.

2. Foundations of Blockchain, Ethereum, Smart Contracts, and Digital Wallets

In this section, we provide an overview of the fundamental technologies relevant to the paper, including blockchain, Ethereum, smart contracts, and digital wallets. Blockchain technology is a relatively new innovation in Information and Communications Technology (ICT), and its adoption across industries is steadily increasing. At its core, the blockchain is a sequential chain of blocks, where each block contains data on multiple transactions. Each newly added block carries a unique identifier, along with the identifier of the preceding block, thereby forming an unbroken chain linking the first block (genesis block) to the most recent one. These identifiers are generated using cryptographic hash functions, which create a unique digital fingerprint based on the block data. This mechanism ensures the integrity and immutability of the stored information, making the blockchain a tamper-resistant and reliable system for recording transactions [8]. Data stored on the blockchain are managed through a peer-to-peer (P2P) network, eliminating the need for a central authority. One of the fundamental processes in a blockchain network is mining, which involves validating and adding new blocks containing transactions to the chain. To ensure that the network nodes can verify the authenticity of the transactions and determine which node should join the next block, consensus mechanisms are implemented [9]. Several consensus algorithms exist, each with its own strengths and weaknesses. The most widely used are as follows:

• Proof of Work (PoW) [10]—uses cryptographic computations to validate transactions but requires high energy,
• Proof of Stake (PoS) [11]—selects validators based on staked cryptocurrency, reducing energy consumption,
• Proof of Authority (PoA) [12]—depends on trusted validators, making it more centralized but efficient.

The choice of a consensus algorithm depends on the specific requirements and objectives of the blockchain-based system, such as scalability, security, and energy efficiency. Figure 1 presents a simplified diagram illustrating the operation of a blockchain.

Blockchain has several key properties: (i) immutability—once recorded, data cannot be changed without altering all subsequent blocks and reaching network consensus; (ii) decentralization—each participant holds a full blockchain copy, reducing reliance on a central authority; (iii) transparency—all transactions are visible to participants; and (iv) security—advanced cryptographic techniques ensure data confidentiality, authenticity, and integrity. Depending on access requirements, blockchain networks can be classified into public, private, and hybrid blockchains, each offering varying levels of accessibility and control. The combination of decentralization, immutability, transparency, and security makes blockchain valuable for applications beyond finance, such as supply chain management, digital identity verification, or secure voting.

Over time, as blockchain technology began to be utilized beyond the financial sector, the Ethereum platform was introduced, serving as the foundation for the development of dApps [13]. Due to their immutability, transparency, and decentralization, dApps are particularly valuable in use cases where data integrity and resistance to manipulation are of the highest importance. These applications operate on blockchain networks, eliminating reliance on centralized intermediaries and ensuring trustless interactions. At the core of Ethereum lies the Ethereum Virtual Machine (EVM), a decentralized computational environment that ensures the consistency of the network’s state across all nodes. Each Ethereum node maintains a copy of this state, enabling a synchronized and secure system. Ethereum operates on an account-based model, where accounts have 20-byte addresses. Every Ethereum account consists of several key components [14]:

• Transaction counter (nonce)—to prevent replay attacks;
• Balance of Ether (ETH)—the native cryptocurrency used for transaction fees;
• Smart contract code (if applicable);
• Persistent storage for contract-related data.

There are two primary types of account within the Ethereum network: (i) externally owned accounts—controlled by private keys, allowing users to initiate transactions—and (ii) contract accounts—managed by deployed smart contract code, which executes autonomously in response to incoming transactions. A fundamental component of Ethereum is the use of smart contracts [3], which are self-executing programs designed to operate deterministically within the EVM. These contracts operate as part of the Ethereum network protocol and allow developers to implement automated, trustless interactions. Smart contracts can be written in multiple programming languages, each offering unique characteristics tailored to different use cases of the blockchain. The most widely used languages are Solidity [15], Vyper [16], and Fe [17]. A key component in the context of dApps and smart contracts is the generation of the Application Binary Interface (ABI) [18], which is created from the contract code. ABI enables the contract to communicate and interact with external applications by defining callable methods. This enables external applications to communicate with the contract in a language understood by the EVM. Before a smart contract can be deployed on the Ethereum network, it must first be compiled into low-level bytecode, which is then executed by the EVM. To streamline this process, developers can use a variety of tools and integrated development environments. Among the most widely used solutions are Remix [19], a browser-based IDE designed for Solidity development, and Hardhat [20], a modern development framework for compiling, testing, and deploying Ethereum smart contracts. Hardhat supports extensibility of plugins, mainnet forking, and advanced debugging capabilities, making it a preferred choice among developers for building production-grade decentralized applications. In summary, Ethereum has significantly expanded the capabilities of blockchain technology, enabling dApps that go far beyond financial transactions. With the EVM, smart contracts, and the dApp ecosystem, Ethereum provides developers with a powerful and flexible environment to create complex decentralized solutions. As adoption continues to grow, Ethereum’s potential extends to multiple industries, making it a cornerstone of the Web3 revolution [21].

The final and highly significant component that needs to be introduced for the purposes of this paper is digital wallets. A cryptocurrency wallet is a specialized type of digital wallet designed exclusively for managing blockchain-based assets. Although certain digital wallets offer cryptocurrency storage capabilities, they lack the specialized security features and optimizations required to securely execute blockchain transactions, which are inherently supported by dedicated cryptocurrency wallets. The key differences between a digital wallet and a cryptocurrency wallet are presented in

Table 1. Digital wallets vs. Cryptocurrency wallets.

	Digital Wallet	Cryptocurrency Wallet
Goal	Holds various forms of digital payment options, such as credit and debit cards, electronic money, and occasionally cryptocurrencies.	Specifically designed for storing, sending, and receiving cryptocurrencies.
Types of assets	Supports loyalty cards, tickets, digital IDs, and sometimes cryptocurrency.	Only manages cryptocurrencies and blockchain-based assets.
Connection	Typically linked to traditional financial institutions (banks, payment networks).	Connected to blockchain networks, with private and public key management.
Examples	Apple Pay, Google Pay, PayPal	MetaMask, Argent, Trust Wallet, Coinbase Wallet

.

Cryptocurrency wallets serve as interfaces for storing cryptographic keys, which are essential for accessing funds and authorizing transactions. The private keys stored within these wallets enable users to digitally sign transactions, thereby proving ownership of their Ethereum addresses and authorizing outgoing operations. However, the presence of a valid signature does not guarantee that an account possesses sufficient funds. The EVM performs final verification of the account balance and execution of the transaction during the processing phase. If the balance is insufficient, the transaction will revert automatically, even if it was correctly signed. Cryptocurrency wallets can be categorized according to how cryptographic keys are stored and managed [22]. Users may retain full control over their keys or delegate key storage to an external service provider. Based on this distinction, cryptocurrency wallets can be classified into the following types:

• Hardware wallets (cold storage)—type of non-custodial wallet that exists as physical devices designed for secure offline storage of cryptographic keys. Since they operate offline (cold storage) mode, they are highly resistant to cyber threats such as phishing, malware, and hacking attempts [22]. Due to their enhanced security features, hardware wallets are considered the safest option for storing cryptocurrencies. Some of the most popular models include Ledger Nano S or X [23], and Trezor Model T or One [24].
• Web-based wallets (hot wallets)—web wallets provide access via a web browser, making them convenient for everyday transactions. However, private keys are often managed by a third-party service, which means that users must trust the provider for security. Although these wallets offer easy access and usability, they introduce higher security risks, as they remain online (hot storage) and are vulnerable to hacking attempts. An example of this type of wallet is MetaMask.
• Mobile-based wallets—smartphone applications that allow users to store and manage cryptocurrencies conveniently. They are designed for on-the-go transactions and often include QR code support for seamless payments. Although they provide greater accessibility, mobile wallets can be vulnerable to device theft, malware, or unauthorized access if proper security measures (for example, biometric authentication, PIN protection) are not in place. Examples of popular mobile wallets include AlphaWallet [25] or Trust Wallet.
• Desktop wallets—software applications installed on a personal computer. Unlike web wallets, desktop wallets do not require a constant internet connection, reducing the risk of remote attacks. They provide users with full control over their private keys, but the security of the wallet depends on the computer’s protection against malware and viruses. Examples of popular desktop wallets include Electrum (Bitcoin wallet) [26] or Atomic Wallet [27].
• Paper wallets—paper wallets involve physically printing or writing down private and public keys on paper. Since keys never exist in digital form, they are immune to cyberattacks. However, this method introduces new risks, such as loss, damage, or theft of the physical document. Although paper wallets provide strong security against hacking, they require careful handling to prevent destruction or unauthorized access.

The choice of wallet type depends on security requirements, accessibility preferences, and user experience. Although hardware and paper wallets offer maximum security, they may not be convenient for frequent transactions. However, web, mobile, and desktop wallets provide easier access, but require additional security precautions.

3. Technical Overview of Wallet Architectures, Attack Vectors, and Related Work

This section presents a technical overview of smart contract-based wallet architectures and outlines common attack vectors that affect decentralized applications. In addition, it includes a comparison with existing academic papers to smart contract security, to highlight the distinctive methodological choices made in this study. Although many of wallet features and attack vectors are well documented, we include this overview to establish a technical foundation for the risk-oriented analysis presented in Section 4 and Section 5. Summarizing key wallet properties and known vulnerabilities enables a more structured and comparative discussion of security implications in the prototype application.

The review begins with MetaMask [5], a widely used cryptocurrency wallet introduced in 2016. MetaMask is fully compatible with the Ethereum platform and is available as both a mobile application and a browser extension. Currently, the extension supports multiple modern web browsers, including Google Chrome, Mozilla Firefox, Opera, and Microsoft Edge. One of MetaMask’s key advantages is its ability to create and manage multiple accounts that can be used on different Ethereum-based networks. It allows users to easily switch between networks, perform transactions using ETH or ERC-20 tokens, and track their transaction history and balances [28]. Figure 2 presents the architecture of a MetaMask-based platform and its integration with an Ethereum blockchain network.

MetaMask relies on Infura [29], a service that facilitates secure connections to the blockchain. Unlike custodial services, Infura does not store private keys, which enhances security by ensuring that users retain control over their cryptographic credentials. Instead, private keys are stored locally on the user’s device, reducing the risk of unauthorized access. Communication between MetaMask and Infura is carried out using the JSON-RPC protocol [30], a standard communication framework that allows interaction with blockchain nodes through remote procedure calls (RPC). When creating a MetaMask wallet, users are required to create a password that is used within the browser extension to unlock and access the contents of the wallet. Additionally, MetaMask provides users with the option to secure their accounts using a secret recovery phrase (SRP). The SRP consists of twelve randomly generated words, which serve as a backup mechanism to recover access to the wallet in the event of loss of password or device failure. Users are required to carefully store and safeguard this phrase, as anyone gaining access to it can take full control of the wallet and its assets. This phrase is not stored on MetaMask servers, it is solely the responsibility of the user to ensure its security. One of MetaMask’s greatest strengths is its seamless integration with dApps. As a browser extension, it allows users to quickly access and interact with the Ethereum ecosystem. Furthermore, MetaMask is praised for its user-friendly interface, which is intuitive even for people who are new to cryptocurrency transactions. The wallet offers advanced security features, including encryption of private keys, to ensure that they remain protected on the user’s device and local storage of account information, rather than relying on centralized external servers. However, as a hot wallet, MetaMask remains constantly connected to the Internet, making it susceptible to cyber threats such as phishing attacks, malware, and hacking attempts. This is a shared limitation among all hot wallets, as their constant connectivity increases the risk of unauthorized access.

The next notable cryptocurrency wallet worthy of detailed discussion is Trust Wallet [6], which is owned by Binance, one of the world’s largest cryptocurrency exchanges. Trust Wallet is available as both a mobile application and a browser extension, offering flexibility and convenience to users who manage their digital assets across multiple platforms. As a non-custodial wallet, Trust Wallet grants users full ownership and control over their private keys, ensuring that no third party has access to their funds. One of its most distinguishing features is its multichain support, which allows users to interact with more than 100 blockchain networks [6]. This broad compatibility makes it an attractive option for those who store and trade various cryptocurrencies, eliminating the need for multiple wallets. Moreover, Trust Wallet features an integrated dApp browser that enables effortless interaction with blockchain-based platforms, including decentralized exchanges (DEXs) and decentralized finance (DeFi) protocols, directly within the wallet interface. Trust Wallet also supports staking, a feature based on the PoS consensus mechanism. This allows users to lock their cryptocurrency holdings to help maintain and secure blockchain networks. In return, they earn staking rewards in the form of additional cryptocurrency. This feature encourages network participation while providing users with a passive income opportunity. Like MetaMask, Trust Wallet utilizes SRP as a backup mechanism for account recovery.

The Coinbase wallet [31] is another cryptocurrency wallet worth examining in detail. It is a mobile-based non-custodial wallet operated by the Coinbase cryptocurrency exchange. Similarly to Trust Wallet, Coinbase Wallet is a self-custody solution, meaning that users have full control over their private keys. The wallet application is available for iOS and Android devices, making it easily accessible for mobile users. It includes a built-in dApp browser, allowing users to search and interact with decentralized applications and perform trades on DEXs directly within the app. To enhance security, the wallet stores private keys locally on the user’s device and utilizes SRP as a backup mechanism. A major advantage of Coinbase Wallet is its compatibility with hardware wallets, such as Ledger [23]. By integrating with Ledger devices, users can add an extra layer of security, reducing exposure to potential cyber threats.

The final cryptocurrency wallet that we want to examine is Argent [32], an advanced and innovative wallet that represents the next generation of digital asset management, leveraging Ethereum smart contracts to improve security, usability, and asset protection. It is available in both mobile and web-based versions. Unlike MetaMask, Argent does not rely on traditional private- and public-key pairs. Instead, it is a smart contract-based wallet, meaning that all transactions and security mechanisms are governed by predefined rules embedded within the smart contract code. This architectural difference enables enhanced programmability, allowing for the implementation of advanced security features, such as transaction limits and account freezing. Argent eliminates the need for users to memorize complex private keys or SRPs, which can be a significant challenge in terms of usability in traditional wallets. Instead, it introduces an innovative mechanism based on third parties trusted by guardians who can assist in account recovery and provide an additional layer of security. These guardians can include friends and family members, other cryptocurrency wallets, or independent security services. Guardians play a crucial role in account recovery procedures, as they can be authorized to approve the recovery process in case the user loses access to their wallet. In addition, they help mitigate security risks by providing protection in scenarios where unauthorized access to the wallet is detected. Argent also allows users to set transaction limits, restricting the amount of cryptocurrency that can be transferred without additional authorization. This feature improves security by preventing large unauthorized transactions and reducing the risk of total asset loss in the event of an attack.

3.1. Attack Vectors on Cryptocurrency Wallets

Each of the cryptocurrency wallets discussed in Section 3 plays a crucial role in the blockchain ecosystem. However, due to their digital nature, these wallets are an attractive target for cybercriminals. One of the most effective methods of attacking cryptocurrency wallets is phishing, a form of social engineering designed to deceive users into revealing sensitive information [33]. Phishing attacks exploit human vulnerabilities, using psychological manipulation techniques to trick users into performing actions that compromise their security. Human error is often the weakest link in security, as individuals may unknowingly disclose their credentials or private data when responding to fraudulent but convincing messages. Attackers typically impersonate well-known and trusted organizations, such as government agencies or reputable companies, using emails that appear to be sent from legitimate sources. These emails contain malicious links intended to deceive recipients into providing sensitive information, such as login credentials or private keys. A particularly dangerous form of phishing attack in the context of cryptocurrency wallets is the creation of fake wallets. In this scheme, cybercriminals develop fraudulent applications that closely resemble legitimate cryptocurrency wallets. These fake wallets are then distributed through app stores, websites, or other digital channels. Once a victim installs a malicious wallet, the application may request private keys, passwords, or recovery phrases, allegedly for wallet setup or fund import. In reality, this information is directly transmitted to attackers, who can then initiate unauthorized transactions, transferring funds to their own accounts. Given that cryptocurrency transactions are irreversible, stolen funds are often difficult, if not impossible, to recover. Furthermore, malicious wallet applications may contain additional malware, allowing attackers to further infiltrate the victim’s device, potentially compromising other personal and financial data. As one of the most widely used cryptocurrency wallets, MetaMask is frequently targeted by phishing attacks. Cybercriminals often create counterfeit versions of the MetaMask extension or set up fraudulent websites designed to steal users’ private keys or recovery phrases. A notable example of such phishing attempts occurred in December 2020, when CipherTrace, a cybersecurity firm, issued a warning about a malicious Chrome extension impersonating MetaMask [34]. This attack was particularly dangerous because the fraudulent download link appeared as the top result in Google Search when users searched for “MetaMask”, as it was a sponsored link. Figure 3 illustrates how phishing websites mimic the official MetaMask page. Although the title of the fraudulent page closely resembles the original, non-Latin characters were substituted in the URL to create a deceptive domain. This subtle and effective tactic often misleads users, making them believe they are on the legitimate website, ultimately leading to the compromise of their security credentials.

Another notable attack on a cryptocurrency wallet was the 2017 Parity Wallet incident [35], which is one of the largest Ethereum-related security breaches in history. The attack resulted in the loss of 150,000 ETH, valued at approximately 30 million dollars at the time. Unlike phishing attacks or social engineering scams, this breach was not a result of user deception but stemmed from a critical flaw in the wallet’s smart contract architecture. The attack exploited a security weakness in Parity Wallet’s smart contract code, which lacks proper access controls. This vulnerability allowed an attacker to reinitialize the wallet ownership list, effectively resetting the contract administrator settings. As a result, the attacker granted himself the sole ownership rights over the affected wallets [35]. Once in control, the attacker was able to replace the addresses of the original wallet owners with their own, allowing them to authorize transactions and transfer all stored funds to their personal account. The Parity Wallet attack serves as a cautionary example of how poorly implemented smart contracts can lead to catastrophic financial losses, underscoring the need for stringent security practices in Ethereum-based applications.

The next significant vulnerability in a smart contract occurred in 2023, targeting the Orion protocol, a decentralized financial platform [36]. The attack exploited a lack of reentrancy protection, a vulnerability that allows an attacker to repeatedly invoke a function before the initial execution is complete. In more advanced scenarios, referred to as reentry amplification, the attacker may chain multiple such invocations within a single transaction, amplifying the effect of the exploit. The attacker first created a fraudulent token and deposited a small amount in the contract to gain access. The next step involved taking out a flash loan, a type of instant loan that must be repaid within the same transaction, for a large sum of money. Using their fraudulent token, the attacker then exchanged the borrowed funds for other tokens [37]. During this exchange, the attacker repeatedly triggered the vulnerable function, depositing the borrowed funds back into the contract. Due to improper balance calculations, the contract overestimated the attacker’s token holdings, allowing them to acquire additional tokens illegitimately. Using this flaw, the attacker extracted all available funds from the contract and repeated the process on a different blockchain network, ultimately stealing approximately 3 million dollars. The root cause of this attack was the absence of adequate security measures to prevent multiple invocations of the same function within a single transaction.

These cases highlight the importance of strengthening security through the implementation of robust authentication measures, routine security assessments, and detailed user education on protecting private keys and recovery phrases.

3.2. Related Work

Numerous papers have proposed tools and methodologies aimed at improving the security of smart contracts, particularly in the Ethereum ecosystem. A common strategy involves the application of static analysis and formal verification techniques to detect known classes of vulnerabilities. For example, Luu et al. [38] introduced Oyente, an early static analyzer that uses symbolic execution to identify issues such as reentry, transaction order dependence, and time-stamped dependence. Tikhomirov et al. [39] developed SmartCheck, which performs abstract syntax tree (AST) traversal and pattern matching to report Solidity-specific anti-patterns. Another prominent example is Securify, proposed by Tsankov et al. [40], which uses Datalog-based logic reasoning to distinguish between compliance and violation patterns, allowing for rule-based classification of contract behaviors. These tools have contributed significantly to the formalization and automation of vulnerability detection in smart contracts. Despite their analytical rigor, these tools often operate under simplified assumptions, such as the absence of external interactions, or rely solely on code-level heuristics. As such, they may fail to capture security flaws that arise dynamically from inter-function logic, user interactions, or unexpected input sequences. Moreover, their output is typically limited to a list of detected issues, without guidance on real-world exploitability or business logic inconsistencies. More recent empirical studies, such as those by Torres et al. [41], have shifted their attention to analyzing deployed contracts to derive vulnerability taxonomies and classify honeypot patterns. While their contribution is valuable in mapping the threat landscape, the methodology is retrospective and does not offer a proactive testing strategy for new contracts prior to deployment.

In contrast, the framework we proposed in this paper adopts a hybrid approach, combining automated symbolic analysis with structured manual testing. It simulates interaction scenarios reflecting both valid and adversarial behaviors to uncover vulnerabilities that may not be evident through code inspection alone. Rather than focusing exclusively on known vulnerability patterns, the approach emphasizes context-aware testing of access control logic, input validation, and execution paths under edge-case conditions. This integrated methodology enables the identification of latent flaws related to control flow, logic consistency, and functional misuse—areas often overlooked in traditional static analysis pipelines. Furthermore, unlike previous studies that evaluated tools in isolation or focused on the design of analysis frameworks, this paper demonstrates the application of a cohesive tool-assisted security assessment process through an end-to-end case study. By combining formal vulnerability classification (through SWC IDs), severity scoring, and remediation validation, the proposed framework contributes not only a technical method, but also a reproducible auditing model applicable to a broad class of decentralized applications.

4. Case Study: BlockScribe Subscription Management System

The previous sections on blockchain, Ethereum, smart contracts, wallets, and attack vectors show that a lack of awareness among users and developers is a major cause of vulnerabilities in Ethereum-based applications. Given the potential security risks involved in developing such applications, we decided to design and assess a web-based application built on the Ethereum platform, using the MetaMask wallet. The primary objective was to evaluate its security and identify critical aspects that must be considered when developing this kind of dApps. The implemented application, named BlockScribe (BS), functions as a blockchain-based subscription management system. It is written in Solidity version $0.8.21$, taking advantage of built-in protections against integer overflow and underflow, support for structured exception handling, and improved gas optimization. The system was deployed on the Sepolia Ethereum test network and consists of two main layers: (i) a smart contract layer managing subscriptions and (ii) a front-end built in React and Ethers.js that connects to MetaMask.

The system architecture is illustrated in Figure 4, and its key components, along with their interactions, are detailed below:

• User—an individual who uses the web application. Users communicate with the MetaMask wallet for authentication and transaction signing.
• Frontend app—a React-based [42] frontend application responsible for interacting with MetaMask (sending transactions, user authentication) and communicating with the Ethereum network. Integration with Ethereum is achieved using the Ethers.js library.
• MetaMask—the cryptocurrency wallet used for testing BlockScribe. Although users can utilize any compatible cryptocurrency wallet, MetaMask was chosen due to its user-friendly interface and advanced security features.
• Ethereum (Sepolia)—the Sepolia Ethereum test network [43] was used for conducting experiments. Sepolia, like other Ethereum testnets, allows developers to test and debug smart contracts and applications without incurring real transaction costs. It operates with test Ether, which has no real-world value, but provides an accurate simulation of how the application would perform on the Ethereum mainnet.
• SubscriptionService smart contract—a smart contract implemented in Solidity, one of the most widely used contract-programming languages for developing Ethereum-based dApps.

The SubscriptionService smart contract includes functionalities for subscription management, payment processing, and administrative actions. A fragment of this contract is presented in Algorithm 1. The design of the contract is intentionally minimalistic and serves an educational purpose. Instead of replicating a full-scale application, it focuses on illustrating the most common and impactful security mistakes made during smart contract development. This approach supports reproducibility, clarity of analysis, and alignment with the experimental goals of the study. The key variables were marked as $constant$ or $immutable$, and the public functions take advantage of $calldata$ for the input parameters to minimize the use of gas. Critical functions such as $withdrawFunds\left(\right)$ and $selfDestructContract\left(\right)$ are protected using $require(msg.sender==owner)$ to ensure that only the contract owner can invoke them.

Algorithm 1 The fragment of SubscriptionService contract.

contract  SubscriptionService {         address public immutable owner;         uint256 public subscriptionFee;         uint256 public constant subscriptionPeriod = 30            days;    struct Subscriber {        uint256 subscriptionDue;        bool isSubscribed;        string email;    }    mapping (address => Subscriber)        public subscribers;    constructor (uint256 _subscriptionFee) {        owner = msg.sender;        subscriptionFee = _subscriptionFee;    }    function subscribe(string calldata email)        external payable {…}    function makePayment() external payable {…}    function withdrawFunds()        external {…}    function selfDestructContract()        external {…}    … }

The main public variables in the contract are as follows:

• address public owner—stores the Ethereum address of the contract owner. This variable is initialized at the time of contract deployment.
• uint256 public subscriptionFee—defines the subscription fee amount, expressed in Wei, where 1 Wei is the smallest unit of $ETH$ (equivalent to ${10}^{-18}$$ETH$).
• uint public subscriptionPeriod—specifies the duration of a subscription after payment. This value is hardcoded as 30 days and cannot be modified by any contract methods.
• mapping(address $=>$ Subscriber) public subscribers—a mapping structure that maintains associations between user addresses and their subscription data, enabling efficient retrieval of subscription details.

Furthermore, SubscriptionService smart contract provides several externally callable functions, allowing users and the contract owner to interact with the subscription system. The primary functions include:

• subscribe—allows users to subscribe to the service by providing their email address, name, and surname, and making a payment in $ETH$ equal to the subscription fee set during the contract initialization.
• unsubscribe—enables users to cancel their subscription, modifying the contract’s state and emitting an “Unsubscribed” event.
• makePayment—allows users to renew their subscription by making an $ETH$ payment. The function verifies whether the correct subscription fee has been sent and checks if the previous subscription period has expired before processing the payment.
• checkSubscription—verifies the subscription status of a user, checking whether they are an active subscriber and if their subscription is still valid.
• getAllSubscribers—returns a list of all subscribers, including historical subscription data from past transactions.
• withdrawFunds—enables the contract owner to withdraw accumulated funds from the contract.
• updateSubscriptionFee—allows the contract owner to modify the subscription fee after the contract has been deployed to the network.
• selfdestructContract—grants the contract owner the ability to terminate the service by removing the contract from the blockchain, effectively ending its operation.

The smart contract developed was subsequently deployed on the previously configured test network to facilitate both manual and automated testing using Remix. Deploying the contract on the network requires a transaction, which in turn requires the use of a cryptocurrency wallet to authorize and execute the deployment process. Figure 5 presents the Remix interface that illustrates the smart contract deployment process.

5. Experiments

In this section, we present a comprehensive security assessment of the smart contract. The evaluation employs a hybrid methodology that integrates both automated analysis tools and structured manual testing. The assessment was carried out under the assumption that the smart contract had been verified and published in Etherscan block explorer [44]. This assumption is aligned with best practices in decentralized application development, where developers verify the contract to improve transparency and community trust. A verified contract on Etherscan allows users to inspect Solidity source code, analyze function-level behavior, and understand input/output relationships without relying on reverse engineering. While code verification promotes openness and facilitates third-party audits, it also increases the attack surface, as malicious actors can more easily identify flaws. In our study, this setup enabled efficient manual security testing and provided a realistic context for simulating both valid and adversarial interactions with the smart contract. The general testing framework applied in this study is shown in Figure 6. It combines symbolic analysis with manual testing in a structured pipeline, enabling comprehensive vulnerability detection. The detected issues were classified using the SWC registry [45], assigned severity levels, and summarized in structured tables (

Table 2. Successfully completed manual testing scenarios for the implemented contract methods.

No.	Function	Scenario	Expected Result	Result
1	subscribe(email, firstName, lastName)	The user inputs correct arguments for the function.	The function executes correctly, and the provided data is saved on the blockchain. A “Subscribed” event is emitted.	Positive
2	subscribe(email, firstName, lastName)	The user invokes the function with an incorrect transaction fee.	The function returns an error and does not save the provided data. A “Subscribed” event is not emitted.	Positive
3	unsubscribe()	A user with an active subscription invokes the function.	The subscription is correctly canceled. The data is saved on the blockchain, and an “Unsubscribed” event is emitted.	Positive
4	updateSubscriptionFee(newFee)	The contract owner invokes the method with a correct new fee value.	The function call succeeds. The subscription fee is updated.	Positive
5	updateSubscriptionFee(newFee)	The contract owner invokes the method with an incorrect fee value, e.g., an empty value.	The function call fails. The fee is not updated.	Positive
6	withdrawFunds()	The contract owner invokes the method.	The function executes successfully. Funds are transferred to the owner’s account.	Positive

,

Table 3. Unsuccessful manual testing scenarios for the implemented contract methods.

No.	Function	Scenario	Expected Result	Result
7	subscribe(email, firstName, lastName)	The user inputs an incorrect email address.	The function returns an error, and the user-provided data is not saved. A “Subscribed” event is not emitted.	Negative—data is saved, and the event is emitted
8	subscribe(email, firstName, lastName)	The user inputs parameters where each has a length of a thousand characters.	The function returns an error, and the user-provided data is not saved. A “Subscribed” event is not emitted.	Negative—data is saved, and the event was emitted
9	subscribe(email, firstName, lastName)	The user invokes the function with empty values for the parameters.	The function returns an error and does not save the provided data. A “Subscribed” event is not emitted.	Negative—data is saved, and the event is emitted
10	unsubscribe()	A user without an active subscription invokes the function.	The function call fails. An “Unsubscribed” event is not emitted.	Negative—the event was emitted
11	updateSubscriptionFee(newFee)	A non-owner user invokes the method with a correct new fee value.	The function call fails. The fee is not updated.	Negative—the fee is updated
12	withdrawFunds()	A non-owner user invokes the method.	The function call fails. Funds remain in the contract account.	Positive—reverted as expected
13	selfDestructContract()	A non-owner user calls the function.	The function call fails.	Positive—reverted as expected

,

Table 4. Security assessment of the contract using Mythril—identified and mitigated risks.

SWC ID	Function	Severity	Risk Description and Mitigation
114	withdrawFunds()	Medium	Transaction Ordering Dependence—the function’s outcome depends on the balance or memory record, which could lead to race conditions.
110	subscriberAddresses(uint256)	Medium	Exception State—in the full implementation, this function previously used assert() for input validation. Replaced with require() in the final version.
106	selfDestructContract()	Low	Access to self-destruction properly restricted by $require(msg.sender==owner)$.
101	makePayment(), subscribe (string, string, string)	Medium	Arithmetic Errors—potential for integer overflow/underflow in arithmetic operations.

,

Table 5. Security analysis of the contract using Slither.

No.	Function	Severity	Potential Weakness or Observation
1	withdrawFunds()	None	Access control in place using $require(msg.sender==owner).$ No weakness identified.
2	subscribe(string, string, string)	Medium	User-controlled array length—function sets the array length based on user input.
3	getAllSubscribers()	Low	Inefficient loop—loop condition should use a buffered array length.
4		Low	The value of subscriptionPeriod should be declared as constant.
5	subscribe(string, string, string)	Low	Function should be declared as external and parameters should use calldata.

and

Table 6. Summary of vulnerabilities by category, detection method, and severity.

Category	Detection Method	Tool(s) Used	No. of Findings	Severity Levels Present
Access Control	Automated	Mythril	1	Medium
Arithmetic Errors	Automated	Mythril	1	Medium
Transaction Ordering	Automated	Mythril	1	Medium
Inefficient Data Structures	Automated	Slither	2	Low
Assertion Handling	Automated	Mythril	1	Medium
Visibility/Input Handling	Automated	Slither	2	Low
Logic Validation Failures	Manual	Manual	5	Medium

).

This security assessment adopts an attacker model consistent with publicly accessible Ethereum contracts and front-end wallet interactions. The assumed adversary is an external user with no privileged access to backend infrastructure, off-chain databases, or admin keys. The attacker is equipped with basic blockchain development tools (e.g., Remix, Hardhat, MetaMask) and is capable of crafting transactions, observing state changes, and invoking contract functions using web-based interfaces or scripts. The threat model covers logic flaws (for example, improper input validation, insufficient access control), economic vulnerabilities (for example, reentry, integer overflow) and interface misuses between the wallet and smart contract. It does not cover low-level infrastructure attacks (e.g., node takeover), off-chain exploits (e.g., phishing, social engineering) or protocol layer bugs outside of the Solidity/EVM domain. This model reflects realistic threats in production Ethereum dApps, focusing on misuse of exposed functions, faulty interface assumptions, and predictable state transitions exploitable by attackers.

The experiments were conducted using Solidity compiler version $0.8.28$, Mythril $0.24.8$ and Slither $0.10.3$. All tools were invoked with standard configuration flags as recommended in their documentation. Given the evolving nature of these tools, specific execution scripts have not been included in the appendix to avoid future inconsistencies. However, all artifacts used for symbolic analysis and scenario-based testing are available on request to support reproducibility.

5.1. Evaluating of Smart Contract Functions

The implementation of the BlockScribe smart contract was tested using Etherscan to assess its security level. The goal was to simulate real-world interactions and identify potential vulnerabilities that could compromise the integrity of the system. Once the contract code was verified, Etherscan allowed for direct invocation of its methods through the tool’s web interface. A total of 13 functional test scenarios were executed to assess the behavior and robustness of key contract functions. Of these, eight resulted in correct and expected behavior, including appropriate rejections and access enforcement, while five revealed logic or validation flaws. The results have been classified accordingly and are summarized in Table 2 and Table 3. This analysis provides a basis for evaluating the security posture of the contract under both typical and boundary conditions.

A critical issue was found in Scenario 11: any user, regardless of their role, can modify the subscription fee. This represents a significant security vulnerability, as unauthorized modifications could lead to financial discrepancies and exploitation of the system. Another concerning case was Scenario 10, which, while not causing a direct financial loss to the owner or users, could still have negative consequences. In this case, false “Unsubscribed” events were emitted, even though no subscription was actually canceled. Such misleading events, sometimes referred to as fake event triggers, could cause confusion for system administrators, especially when interpreting data from blockchain explorers. As a result, inaccurate information can lead to incorrect operational or analytical decisions. To mitigate this risk, additional validation mechanisms should be implemented to prevent the emission of events without a corresponding state change.

The most critical flaw was observed in Scenario 13, where the contract destruction function was successfully executed by an unauthorized user. This function should not be publicly accessible, as unrestricted access could lead to accidental or deliberate deletion of the contract. Such an event would result in a complete loss of contract functionality and would significantly undermine user trust in the system. To prevent this, access to this function must be strictly limited to the contract owner. Strengthening access controls and validation mechanisms is essential to ensure the security and reliability of the smart contract.

The manual testing phase included 13 interaction scenarios that covered both valid and invalid user behaviors. Among these, eight test cases produced correct and expected outcomes (see Table 2 and Table 3), including appropriate rejection of unauthorized or malformed inputs. The remaining five scenarios revealed functional flaws, such as lack of proper input validation, missing access control, or emission of misleading events. These results underscore the necessity of rigorous access checks and input handling in production-grade smart contract deployments.

In addition to validating functional correctness, we investigated the gas consumption efficiency of selected functions. Key optimizations include the use of calldata for function parameters, particularly in the methods subscribe() and makePayment(), where the parameters are read-only. This approach avoids unnecessary memory allocation. Furthermore, loops that iterate over storage-based arrays now cache the array length in a local variable before execution, thereby minimizing repetitive gas-intensive read operations. Finally, all non-dynamic constant values, such as the subscription period, were declared as constant or immutable, reducing storage footprint and transaction cost. In the current prototype, some input validation mechanisms in functions such as subscribe() still need to be fully implemented. Specifically, while basic data are collected, stricter checks for format correctness and empty values should be added in future iterations to improve robustness.

5.2. Testing Using Tools

This subsection presents the results of tests performed using automated analysis tools. The security evaluation utilized two widely adopted static analysis tools: Slither [46] and Mythril [47]. Slither was executed with enabled default detectors and targeted vulnerabilities related to reentrancy, access control, uninitialized storage, and gas optimization. Mythril was configured in symbolic execution mode, using Solidity $0.8.28$ bytecode compiled without optimization. The detected issues were classified according to the Smart Contract Weakness Classification Registry (SWC), which provides standardized identifiers for common smart contract flaws. In this study, formal verification is understood as a property-oriented vulnerability analysis supported by symbolic execution, as implemented in the aforementioned tools, rather than in the form of mathematical proofs or theorem-proving techniques. We started with Mythril, a widely adopted tool to assess the security of solidity-based smart contracts. The results of the analysis are presented in Table 4.

Each identified vulnerability is assigned a unique SWC code, which facilitates the identification and remediation of known security problems. The analysis identified potential risk categories commonly associated with Solidity-based contracts. However, in the case of BlockScribe, all relevant risks were inherently mitigated using the Solidity version $0.8.28$ or explicitly addressed through appropriate access control and validation mechanisms. Table 4 summarizes the risk areas reviewed and the corresponding preventive measures applied in the contract design. One of the identified issues, classified as SWC 114, arises from the dependence on the order of the transactions. The function responsible for fund withdrawals is based on the contract balance at the time of execution, making it susceptible to race conditions. If the contract state changes between two function calls, an attacker could manipulate the balance before the transaction is completed, leading to incorrect fund distribution. Implementing reentrancy locks or unique transaction identifiers can help mitigate this risk. Another vulnerability, classified as SWC 110, is related to the improper use of assertions within the function that returns subscriber addresses. The use of the assert() function in this context is inappropriate, as assertions should only validate conditions that are always true. If an attacker provides an invalid input, such as an excessively large index, the function may trigger an assertion failure, interrupting contract execution. Replacing assert() with require() would ensure that invalid inputs cause the function to terminate gracefully rather than leading to unexpected behavior. A more critical issue, classified as SWC-106, refers to smart contracts where the selfdestruct() function is not properly access-controlled. In the case of BlockScribe, this risk is mitigated by design—the selfDestructContract() function is protected by a $require(msg.sender==owner)$ check, ensuring that only the contract owner can invoke this operation. The last identified risk, classified as SWC 101, concerns arithmetic operations that may be vulnerable to integer overflow and underflow. The mathematical operations within the contract could exceed the limits of the specified data types, resulting in unexpected errors. This vulnerability is inherently mitigated in Solidity $0.8.28$, which includes native arithmetic checks that eliminate the need for external libraries such as SafeMath. Although this study adopts the SWC registry as the basis for identifying and categorizing vulnerabilities, it is worth noting that the SWC framework is no longer actively maintained. However, it remains widely used in academic and tool-supported analyses, particularly in automated vulnerability scanners such as Mythril. Its structured taxonomy still provides a valuable reference point for systematic assessment. However, to align with evolving industry practices, future research may benefit from incorporating more current standards such as the Ethereum Enterprise Alliance (EEA) EthTrust Security Levels [48], which offer a normative framework for security certification and compliance evaluation in modern smart contract development.

Another tool used to assess the security of the implemented contract was Slither [46]. Unlike Mythril, which focuses on potential attack scenarios and simulations, Slither performs static code analysis. In addition to identifying vulnerabilities, the tool also detected certain issues related to code optimization and quality. Table 5 presents the observations and potential problems identified using this tool, including suggestions related to code quality, optimization, and access control.

One of the key identified issues is the unsafe transfer of $ETH$, where the withdrawFunds() function allows arbitrary users to receive funds without proper access restrictions. This lack of control could lead to unauthorized transactions, making it necessary to implement stricter access mechanisms to ensure that only the contract owner or authorized users can execute this function. Another weakness comes from the way the subscribe function handles user-controlled input. The subscriberAddresses array does not have a predefined length limit, meaning that an attacker could exploit this by inserting excessive data, which may eventually overload the contract’s memory and increase gas consumption. To mitigate this risk, validation checks should be implemented to prevent duplicate entries and enforce reasonable constraints on the size of the array. The contract also contains a critical flaw related to its self-destruction mechanism, which was also detected by Mythril and described in Table 4 as SWC 106. The contract was implemented using Solidity version ($0.8.28$), which includes built-in protections against integer overflow and underflow, and supports structured exception handling and improved memory management. Another inefficiency was identified in the getAllSubscribers function, where the loop iterates over an array stored in memory without caching its length. Each iteration requires additional computational resources to fetch the array size, which can lead to performance issues, especially when dealing with large data sets. A simple optimization, such as storing the array length in a local variable before looping, would reduce execution time and lower gas costs. Furthermore, the contract includes a variable, subscriptionPeriod, which is not declared as constant, even though its value remains unchanged after deployment. In Solidity, marking such variables as constant optimizes gas usage because their values are embedded in the bytecode rather than being stored in memory. Implementing this optimization would result in lower execution costs for functions referencing this variable. Lastly, the subscribe function was declared as public, allowing both internal and external calls. However, since this function is designed to be accessed externally, it would be more efficient to declare it as external. Furthermore, its parameters should use calldata instead of memory, as calldata is optimized for handling external input data, reducing unnecessary memory allocation and improving gas efficiency.

Although automated security tools such as Mythril and Slither provide an efficient and systematic means of identifying common vulnerabilities, they are not sufficient for comprehensive smart contract assurance. Manual code audits conducted by experienced developers are essential to detect context-specific and logic-related flaws that automated tools may overlook. Regular reviews, ideally performed at each stage of the development lifecycle, significantly reduce the likelihood that critical exploits go undetected. In addition, such manual analysis revealed broader architectural considerations, particularly with respect to secure access control for financial operations. To mitigate the risk of unauthorized withdrawals or destructive actions, the adoption of multisignature wallet mechanisms is strongly recommended. Although not implemented in the BlockScribe prototype, these mechanisms are increasingly used in production-grade decentralized applications involving asset custody or contract lifecycle management, as they reduce single point of failure and enhance user trust.

5.3. Summarize—Recommended Best Practices

The research carried out allowed for the identification of security vulnerabilities and areas for optimization within the smart contract code. This section presents a summary of the improvements and best practices implemented that can be used by developers working with smart contracts. To consolidate the results of automated and manual evaluations, Table 6 provides a categorized summary of the detected vulnerabilities, indicating their origin (manual or tool-assisted) and severity. This structured overview reinforces the need for hybrid security testing strategies that combine symbolic analysis with scenario-based evaluation.

Compared to static scoring frameworks such as EthTrust Level or CertiK Skynet [49], the proposed method emphasizes a hybrid analysis strategy that combines symbolic execution with manual scenario testing. Although EthTrust and Skynet provide valuable standardized metrics for assessing code structure and known antipatterns, they were not applied directly in this study. Instead, we see their integration as a promising avenue for future work, particularly in benchmarking coverage, identifying blind spots, and improving audit reproducibility through the complementary use of standardized certification schemes and custom interaction-based assessments. The key takeaways of this research include the following enhancements:

• Choosing and maintaining a stable Solidity version ensures protection against common vulnerabilities and compatibility with modern language features.
• Proper validation of input data, which should include checks to prevent empty values and enforce correct data formats. In the current prototype, some validation logic (e.g., email formatting and empty field checks) is not fully enforced and will be strengthened in future versions. Additionally, the length of user-inputted strings should be restricted to prevent excessive memory usage and potential exploits.
• Access control for contract functions to ensure that only authorized users can execute certain operations. Functions should be restricted where necessary, for example, by allowing only the contract owner to call administrative functions.
• Protection against concurrent function execution to prevent race conditions. Implement a reentrancy guard and ensure that functions cannot be executed multiple times simultaneously, reducing the risk of exploitation.
• Using the immutable keyword where applicable, as it enhances security by preventing unintended modifications while also optimizing gas consumption, leading to more efficient contract execution.
• Gas optimization techniques should be considered essential in production-grade contracts. Developers are encouraged to use calldata instead of memory
• For functions involving asset transfer or contract destruction, developers should consider the integration of multi-signature wallets. This mechanism ensures that sensitive operations can only be executed after approval by multiple trusted parties, thus mitigating the risk of unauthorized access due to compromised private keys or malicious insider actions.
• To enhance scalability and cost efficiency, developers should consider integrating off-chain computation and Layer 2 solutions such as Optimistic Rollups or zk-Rollups. These technologies reduce the transaction load on the Ethereum mainnet while maintaining security guarantees through fraud proofs or zero-knowledge validation mechanisms [50].

6. Conclusions

This study presented a practical security assessment of Ethereum-based web applications, with a particular focus on the integration of cryptocurrency wallets and smart contracts. By developing and analyzing the BlockScribe prototype, we showed how wallet-contract integration patterns can expose applications to risks such as unauthorized access, weak input validation, improper fallback logic, and misconfigured access control. Although the methodology is tailored for Ethereum-compatible platforms (due to its reliance on Solidity and EVM tools), its principles—such as layered validation, symbolic analysis, and scenario-based testing—could be adapted to other ecosystems like Hyperledger Fabric, provided similar abstractions and tooling exist.

Using static analysis tools (Mythril, Slither), targeted unit tests, and manual code inspection, we identified key vulnerability patterns and evaluated how modern Solidity features (e.g., version $0.8.28$) mitigate common weaknesses. These include protections against arithmetic overflows, improved exception handling, and enhanced type safety. The analysis also highlighted broader integration challenges, such as the misuse of wallet APIs and the need for layered validation when accepting user input. Our findings emphasize that many security flaws originate not in the blockchain protocol itself but in the surrounding application logic and assumptions made at the interface layer.

Although this research does not introduce novel cryptographic mechanisms or formal proofs, it contributes to a reproducible and tool-supported methodology to identify security flaws in real-world Ethereum applications. The simplified prototype and the step-by-step evaluation framework provide an accessible reference model for developers, security reviewers, and engineering teams looking to implement wallet-enabled smart contract logic in a secure and maintainable way.

Future work may explore expanding the prototype to support Layer 2 integrations, decentralized identity authentication, and automated vulnerability certification frameworks such as the EEA EthTrust Security Levels. We also identify opportunities for integrating contract monitoring tools and runtime protection mechanisms that can provide early detection of wallet-side anomalies in production environments. In addition, while the current evaluation focuses on a single dApp-wallet pairing (BlockScribe with MetaMask), the proposed framework is not limited to this combination. The broad applicability to other Ethereum-based applications, such as decentralized exchanges, NFT platforms, or stake protocols, remains an open avenue for further exploration. Testing the methodology against alternative wallet interfaces (e.g., Rabby [51], OKX Wallet [52]) and under more diverse interaction patterns would help validate the generality and robustness of the framework across the ecosystem. Furthermore, while the current implementation performs well for moderate-sized contracts (less than 1000 lines of code), we recognize that symbolic execution and static analysis tools may face runtime and path-explosion challenges for larger contracts or complex Layer 2 setups. Future work may therefore include performance benchmarking, such as comparative gas profile, execution time tracking, and resource cost evaluation before and after vulnerability mitigation.