<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.3 20210610//EN" "JATS-journalpublishing1-3-mathml3.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ali="http://www.niso.org/schemas/ali/1.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" article-type="research-article" dtd-version="1.3" xml:lang="EN">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Front. Blockchain</journal-id>
<journal-title-group>
<journal-title>Frontiers in Blockchain</journal-title>
<abbrev-journal-title abbrev-type="pubmed">Front. Blockchain</abbrev-journal-title>
</journal-title-group>
<issn pub-type="epub">2624-7852</issn>
<publisher>
<publisher-name>Frontiers Media S.A.</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">1730114</article-id>
<article-id pub-id-type="doi">10.3389/fbloc.2025.1730114</article-id>
<article-version article-version-type="Version of Record" vocab="NISO-RP-8-2008"/>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Original Research</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Hyper-heuristic driven smart contracts for DeFi: a framework for dynamic rule optimization and adaptive executions</article-title>
<alt-title alt-title-type="left-running-head">Danach et al.</alt-title>
<alt-title alt-title-type="right-running-head">
<ext-link ext-link-type="uri" xlink:href="https://doi.org/10.3389/fbloc.2025.1730114">10.3389/fbloc.2025.1730114</ext-link>
</alt-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname>Danach</surname>
<given-names>Kassem</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
<uri xlink:href="https://loop.frontiersin.org/people/3142863"/>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Conceptualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/conceptualization/">Conceptualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Methodology" vocab-term-identifier="https://credit.niso.org/contributor-roles/methodology/">Methodology</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Validation" vocab-term-identifier="https://credit.niso.org/contributor-roles/validation/">Validation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Formal analysis" vocab-term-identifier="https://credit.niso.org/contributor-roles/formal-analysis/">Formal Analysis</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Writing &#x2013; original draft" vocab-term-identifier="https://credit.niso.org/contributor-roles/writing-original-draft/">Writing &#x2013; original draft</role>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Rkein</surname>
<given-names>Hassan</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Conceptualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/conceptualization/">Conceptualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Formal analysis" vocab-term-identifier="https://credit.niso.org/contributor-roles/formal-analysis/">Formal Analysis</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Methodology" vocab-term-identifier="https://credit.niso.org/contributor-roles/methodology/">Methodology</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Visualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/visualization/">Visualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Writing &#x2013; review &#x26; editing" vocab-term-identifier="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/">Writing &#x2013; review and editing</role>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Farroukh</surname>
<given-names>Ahmad</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Conceptualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/conceptualization/">Conceptualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Formal analysis" vocab-term-identifier="https://credit.niso.org/contributor-roles/formal-analysis/">Formal Analysis</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Data curation" vocab-term-identifier="https://credit.niso.org/contributor-roles/data-curation/">Data curation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Resources" vocab-term-identifier="https://credit.niso.org/contributor-roles/resources/">Resources</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Validation" vocab-term-identifier="https://credit.niso.org/contributor-roles/validation/">Validation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Writing &#x2013; review &#x26; editing" vocab-term-identifier="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/">Writing &#x2013; review and editing</role>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Balaa</surname>
<given-names>Ziad E. L.</given-names>
</name>
<xref ref-type="aff" rid="aff2">
<sup>2</sup>
</xref>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Conceptualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/conceptualization/">Conceptualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Investigation" vocab-term-identifier="https://credit.niso.org/contributor-roles/investigation/">Investigation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Methodology" vocab-term-identifier="https://credit.niso.org/contributor-roles/methodology/">Methodology</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Resources" vocab-term-identifier="https://credit.niso.org/contributor-roles/resources/">Resources</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Validation" vocab-term-identifier="https://credit.niso.org/contributor-roles/validation/">Validation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Writing &#x2013; review &#x26; editing" vocab-term-identifier="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/">Writing &#x2013; review and editing</role>
</contrib>
<contrib contrib-type="author" corresp="yes">
<name>
<surname>Haddad</surname>
<given-names>Samir</given-names>
</name>
<xref ref-type="aff" rid="aff3">
<sup>3</sup>
</xref>
<xref ref-type="corresp" rid="c001">&#x2a;</xref>
<uri xlink:href="https://loop.frontiersin.org/people/3140721"/>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Conceptualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/conceptualization/">Conceptualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Validation" vocab-term-identifier="https://credit.niso.org/contributor-roles/validation/">Validation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Methodology" vocab-term-identifier="https://credit.niso.org/contributor-roles/methodology/">Methodology</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Supervision" vocab-term-identifier="https://credit.niso.org/contributor-roles/supervision/">Supervision</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Writing &#x2013; review &#x26; editing" vocab-term-identifier="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/">Writing &#x2013; review and editing</role>
</contrib>
</contrib-group>
<aff id="aff1">
<label>1</label>
<institution>Basic and Applied Sciences Research Center, Information System and Management System Department, Al Maaref University</institution>, <city>Beirut</city>, <country country="LB">Lebanon</country>
</aff>
<aff id="aff2">
<label>2</label>
<institution>Department of Computer Science - LaRRIS, Lebanese University &#x2013; Faculty of Sciences Fanar</institution>, <city>Beirut</city>, <country country="LB">Lebanon</country>
</aff>
<aff id="aff3">
<label>3</label>
<institution>Department of Computer Science and Mathematics, Faculty of Arts and Sciences, University of Balamand</institution>, <city>Koura</city>, <country country="LB">Lebanon</country>
</aff>
<author-notes>
<corresp id="c001">
<label>&#x2a;</label>Correspondence: Samir Haddad, <email xlink:href="mailto:samir.haddad@balamand.edu.lb">samir.haddad@balamand.edu.lb</email>
</corresp>
</author-notes>
<pub-date publication-format="electronic" date-type="pub" iso-8601-date="2026-01-08">
<day>08</day>
<month>01</month>
<year>2026</year>
</pub-date>
<pub-date publication-format="electronic" date-type="collection">
<year>2025</year>
</pub-date>
<volume>8</volume>
<elocation-id>1730114</elocation-id>
<history>
<date date-type="received">
<day>22</day>
<month>10</month>
<year>2025</year>
</date>
<date date-type="rev-recd">
<day>24</day>
<month>11</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>25</day>
<month>11</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>Copyright &#xa9; 2026 Danach, Rkein, Farroukh, Balaa and Haddad.</copyright-statement>
<copyright-year>2026</copyright-year>
<copyright-holder>Danach, Rkein, Farroukh, Balaa and Haddad</copyright-holder>
<license>
<ali:license_ref start_date="2026-01-08">https://creativecommons.org/licenses/by/4.0/</ali:license_ref>
<license-p>This is an open-access article distributed under the terms of the <ext-link ext-link-type="uri" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution License (CC BY)</ext-link>. The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.</license-p>
</license>
</permissions>
<abstract>
<p>The static and hard-coded logic of smart contracts in Decentralized Finance (DeFi) platforms significantly limits their adaptability in dynamic and volatile market environments. To address this challenge, we propose a novel hyper-heuristic driven framework that enables real-time rule optimization within smart contracts, thereby enhancing responsiveness, gas efficiency, and operational robustness. The framework features a two-layer architecture: a reinforcement learning-based high-level controller selects appropriate low-level rule heuristics from a domain-specific library based on evolving transaction contexts and on-chain data. Implemented and evaluated on Uniswap v2 and Aave v3 protocols, the system dynamically optimizes parameters such as slippage tolerance, gas usage thresholds, and loan-to-value ratios. Experimental results on real-world datasets show significant performance improvements, including a 45.6% increase in transaction success rate, 28.3% reduction in average gas consumption, and 38.4% drop in liquidation events under market stress scenarios. This research demonstrates the feasibility and advantages of embedding intelligent, adaptive decision-making mechanisms within DeFi smart contracts, opening new pathways toward autonomous, resilient, and regulation-aligned blockchain systems.</p>
</abstract>
<kwd-group>
<kwd>decentralized finance (DeFi)</kwd>
<kwd>smart contracts</kwd>
<kwd>hyper-heuristics</kwd>
<kwd>dynamic rule optimization</kwd>
<kwd>reinforcement learning</kwd>
<kwd>solidity</kwd>
<kwd>gasefficiency</kwd>
<kwd>blockchain adaptability</kwd>
</kwd-group>
<funding-group>
<funding-statement>The authors declare that no financial support was received for the research and/or publication of this article.</funding-statement>
</funding-group>
<counts>
<fig-count count="6"/>
<table-count count="11"/>
<equation-count count="2"/>
<ref-count count="36"/>
<page-count count="14"/>
</counts>
<custom-meta-group>
<custom-meta>
<meta-name>section-at-acceptance</meta-name>
<meta-value>Smart Contracts</meta-value>
</custom-meta>
</custom-meta-group>
</article-meta>
</front>
<body>
<sec sec-type="intro" id="s1">
<label>1</label>
<title>Introduction</title>
<p>Decentralized Finance (DeFi) has emerged as a transformative paradigm in financial systems, offering permissionless and trustless alternatives to traditional banking through blockchain-based smart contracts <xref ref-type="bibr" rid="B33">Werner et al. (2021)</xref>. Protocols such as Uniswap, Aave, Compound, and MakerDAO have enabled decentralized lending, trading, and yield optimization at unprecedented scale. These applications rely heavily on <italic>smart contracts</italic>, self-executing programs written in languages like Solidity and deployed on platforms such as Ethereum <xref ref-type="bibr" rid="B34">Xu et al. (2021)</xref>.</p>
<p>However, the deterministic nature of smart contracts introduces a fundamental rigidity: contract rules and execution paths are hard-coded and immutable once deployed. This restricts adaptability to external conditions such as market volatility, liquidity shifts, or policy updates <xref ref-type="bibr" rid="B32">Wang et al. (2022)</xref>. For instance, static parameters for interest rates, slippage tolerances, or liquidation thresholds can lead to operational inefficiencies or system vulnerabilities. Historical failures such as the bZx protocol exploit (2020) and the Terra-LUNA collapse (2022) illustrate how poorly calibrated rules or inflexible contract structures can be catastrophic in real-world DeFi markets <xref ref-type="bibr" rid="B23">Qin et al. (2021)</xref>; <xref ref-type="bibr" rid="B18">Kang and Hwang (2023)</xref>.</p>
<p>To mitigate these limitations, some platforms have explored the use of external oracles and governance models to update contract behavior post-deployment <xref ref-type="bibr" rid="B35">Zhang et al. (2020)</xref>; <xref ref-type="bibr" rid="B14">Ghosh et al. (2022)</xref>. Yet, such mechanisms are not without drawbacks, often exhibiting centralization risks, governance delays, and susceptibility to oracle manipulation. Consequently, there is increasing interest in self-adjusting smart contracts that can autonomously respond to both on-chain and off-chain dynamics in real time.</p>
<p>These existing approaches suffer from several concrete failure modes. Upgradeable-proxy contracts rely on governance proposals&#x2014;typically through DAOs or multi-signature wallets&#x2014;that introduce significant latency, ranging from several hours to days (e.g., exceeding 15,000 Ethereum blocks), thereby creating windows of vulnerability. A prominent example is Compound&#x2019;s Proposal 62 in 2021, which resulted in the unintentional distribution of over $90 million in tokens due to delayed governance execution.</p>
<p>Similarly, oracle-based systems are prone to manipulation through flash loans or thin-liquidity trades. Notable cases include the bZx protocol exploit (2020), where attackers leveraged flash loans to manipulate price oracles, and the Mango Markets hack (2022), in which an attacker artificially inflated the price of a collateral asset to extract funds. These incidents underscore the operational fragility introduced by delayed or externally controlled adaptability mechanisms.</p>
<p>Despite the rapid evolution of DeFi, smart contracts remain fundamentally static. Once deployed, their logic is immutable, leading to inefficiencies and vulnerabilities during periods of market volatility or liquidity shifts. Prior attempts to enhance adaptability&#x2014;through off-chain control logic, oracle-based feeds, or governance-based updates&#x2014;introduce trade-offs in the form of latency, centralization, and heightened security risks.</p>
<p>What remains underexplored is the design of smart contracts capable of autonomously and efficiently adapting their internal rule sets in response to evolving on-chain conditions&#x2014;without relying on external interventions. This represents a critical research gap in the pursuit of real-time, decentralized, and intelligent contract behavior.</p>
<p>This paper addresses the gap by proposing a hyper-heuristic driven smart contract architecture. Our framework embeds a high-level reinforcement learning controller directly within the contract, enabling on-chain selection from a domain-specific heuristic library. This adaptive mechanism empowers smart contracts to optimize execution parameters in real time, enhancing transaction success rates, reducing gas costs, and increasing resilience to environmental volatility&#x2014;while maintaining decentralization and transparency.</p>
<sec id="s1-1">
<label>1.1</label>
<title>Background and motivation</title>
<p>Hyper-heuristics have gained prominence as a high-level search methodology designed to automate the process of selecting or generating heuristics for solving complex optimization problems <xref ref-type="bibr" rid="B5">Burke et al. (2013)</xref>. Unlike traditional metaheuristics (e.g., Genetic Algorithms or Simulated Annealing) that directly explore solution spaces, hyper-heuristics operate at a higher abstraction level, making decisions about which heuristics to apply, when, and how.</p>
<p>Originally developed for scheduling, routing, and other NP-hard combinatorial domains, hyper-heuristics have demonstrated robust generalization capabilities across problem domains <xref ref-type="bibr" rid="B7">Cowling et al. (2001)</xref>; <xref ref-type="bibr" rid="B2">Alzamili et al. (2023)</xref>. Their layered architecture typically consists of:<list list-type="bullet">
<list-item>
<p>A <italic>low-level heuristic set</italic> containing problem-specific rules or operators.</p>
</list-item>
<list-item>
<p>A <italic>high-level strategy</italic>, often implemented via reinforcement learning, evolutionary search, or case-based reasoning, to select heuristics based on the problem state.</p>
</list-item>
</list>
</p>
<p>Despite their success in traditional optimization, the integration of hyper-heuristics into blockchain-based environments remains underexplored. This paper pioneers the application of hyper-heuristics to the domain of smart contracts, specifically targeting rule optimization in DeFi protocols. By embedding a high-level decision-making layer within smart contract logic, we aim to equip DeFi systems with real-time adaptability, autonomy, and robustness against external shocks.</p>
<p>Research Contributions. In this work, we:<list list-type="order">
<list-item>
<p>Propose a novel architecture that integrates hyper-heuristics directly into smart contracts for dynamic rule selection.</p>
</list-item>
<list-item>
<p>Develop a reinforcement learning-based controller to manage heuristic choice in response to market indicators.</p>
</list-item>
<list-item>
<p>Evaluate the system using real datasets from Uniswap and Aave, showing measurable improvements in transaction efficiency, cost reduction, and resilience to market volatility.</p>
</list-item>
</list>
</p>
<p>The remainder of this paper is organized as follows: Section II surveys related work on smart contract adaptability and heuristic optimization. Section III defines the problem formulation and modeling assumptions. Section IV introduces the proposed framework and implementation. Section V presents detailed experimental results and analysis. Section VI discusses broader implications and limitations, and Section VII concludes the paper.</p>
</sec>
</sec>
<sec id="s2">
<label>2</label>
<title>Related work</title>
<p>The rigidity of smart contract logic in Decentralized Finance (DeFi) has motivated extensive research into enhancing adaptability, resilience, and efficiency in decentralized systems <xref ref-type="bibr" rid="B25">Rkein et al. (2024)</xref>. This section reviews existing efforts across three main categories: smart contract dynamism, DeFi rule optimization, and hyper-heuristics in optimization and blockchain contexts.</p>
<sec id="s2-1">
<label>2.1</label>
<title>Smart contract adaptability in DeFi</title>
<p>The security and adaptability of blockchain and Ethereum smart contracts have become increasingly vital research domains, particularly in the context of Decentralized Finance (DeFi). With the growing reliance on immutable, self-executing code, any lack of flexibility or vulnerability in smart contracts can have profound consequences on financial ecosystems.</p>
<p>Multiple surveys and taxonomies have addressed general and Ethereum-specific smart contract threats. <xref ref-type="bibr" rid="B26">Saad et al. (2019)</xref>, <xref ref-type="bibr" rid="B19">Li et al. (2020)</xref>, and <xref ref-type="bibr" rid="B36">Zhu et al. (2020)</xref> provided foundational classifications of blockchain vulnerabilities, laying the groundwork for more focused explorations into Ethereum smart contract security. <xref ref-type="bibr" rid="B20">Luu et al. (2016)</xref> were among the first to present a taxonomy of smart contract vulnerabilities while also introducing Oyente&#x2014;an automated tool for analyzing contract behavior. Although Oyente marked significant progress in detection capabilities, it lacked depth in mitigation strategies.</p>
<p>
<xref ref-type="bibr" rid="B10">Dika (2017)</xref> offered a comparative evaluation of early smart contract analysis tools, though the limited tool maturity and dataset scope constrained its findings. <xref ref-type="bibr" rid="B1">Alharby and van Moorsel (2017)</xref> conducted a systematic mapping of smart contract research prior to 2018, highlighting gaps in scalability, privacy, and deployment studies.</p>
<p>
<xref ref-type="bibr" rid="B3">Atzei et al. (2017)</xref> introduced a widely cited three-layer vulnerability taxonomy encompassing Solidity, the Ethereum Virtual Machine (EVM), and blockchain-level flaws. Building on this, <xref ref-type="bibr" rid="B11">Dingman (2019)</xref> applied the NIST framework to identify 49 smart contract bugs grouped into 10 classes. <xref ref-type="bibr" rid="B15">Grishchenko et al. (2018)</xref> contributed formal definitions for call integrity, atomicity, and runtime correctness&#x2014;core principles in smart contract verification.</p>
<p>Several researchers have also assessed the effectiveness of vulnerability detection tools. <xref ref-type="bibr" rid="B9">Di Angelo and Salzer (2020)</xref> compared 27 tools against 18 known vulnerabilities, while <xref ref-type="bibr" rid="B22">Praitheeshan et al. (2019)</xref> evaluated detection rates across 16 vulnerability types using seven popular tools. <xref ref-type="bibr" rid="B17">Huang et al. (2019)</xref> emphasized vulnerability management throughout the software development lifecycle, mapping prevention strategies from design to audit phases. <xref ref-type="bibr" rid="B27">Sayeed and Marco-Gisbert (2019)</xref> focused on application-level vulnerabilities, benchmarking ten tools against seven core bug types. <xref ref-type="bibr" rid="B12">Durieux et al. (2020)</xref> performed one of the largest empirical evaluations, testing nine detection tools across thousands of real-world Ethereum contracts.</p>
<p>
<xref ref-type="bibr" rid="B30">Tantikul and Ngamsuriyaroj (2020)</xref> explored inter-tool detection correlation, while <xref ref-type="bibr" rid="B6">Chen et al. (2020)</xref> compiled a comprehensive mapping of 40 vulnerabilities, 29 associated attack types, and 51 proposed countermeasures. <xref ref-type="bibr" rid="B29">Tang et al. (2021)</xref> categorized detection techniques as static, dynamic, or formal, also suggesting the potential for machine learning to enhance analysis capabilities. <xref ref-type="bibr" rid="B24">Rameder (2021)</xref> addressed gaps in these earlier studies by proposing an updated taxonomy and tool mapping, though he lacked empirical efficiency metrics or Common Weakness Enumeration (CWE) alignments.</p>
<p>Recently, <xref ref-type="bibr" rid="B13">Ghaleb and Pattabiraman (2022)</xref> introduced SolidiFI, an automated benchmark framework evaluating six static tools&#x2014;Oyente, Securify, Mythril, SmartCheck, Manticore, and Slither&#x2014;against seven prevalent vulnerabilities, including reentrancy, unhandled exceptions, and transaction-order dependence. While comprehensive, the study did not extend to dynamic or formal verification methods.</p>
<p>In parallel, DeFi has flourished as a blockchain-powered peer-to-peer financial system. Smart contracts serve as the backbone of DeFi, enabling decentralized trading, lending, and asset management. According to <xref ref-type="bibr" rid="B28">Sch&#xe4;r (2021)</xref> and <xref ref-type="bibr" rid="B23">Qin et al. (2021)</xref>, DeFi has grown into a $200 billion economy, leveraging the permissionless architecture of public blockchains. Within this framework, any user can deploy financial logic, and participants can interact with it without intermediaries&#x2014;provided the predefined contract rules are met.</p>
<p>However, smart contracts in DeFi are traditionally deployed with static logic and fixed parameters. Such inflexibility entails that, contract rules including slippage tolerance, liquidation thresholds, or collateral ratios, cannot adapt to market volatility or user behavior without external interventions. <xref ref-type="bibr" rid="B34">Xu et al. (2021)</xref> highlighted this challenge and proposed modular upgradeable architectures. Similarly, proxy contracts like those in the OpenZeppelin EIP-1967 standard enable logic upgrades but often require administrator keys, reintroducing centralization risks.</p>
<p>To support adaptive behavior, trusted data feeds such as <xref ref-type="bibr" rid="B35">Zhang et al. (2020)</xref> and <xref ref-type="bibr" rid="B4">Breidenbach et al. (2021)</xref> were introduced, enabling contracts to react to off-chain data. Nonetheless, these solutions rely on external inputs and do not offer intrinsic logic-level adaptability. <xref ref-type="bibr" rid="B16">Gudgeon et al. (2020)</xref> underscored the impracticality of real-time updates through decentralized governance due to inherent voting delays, especially under stress scenarios.</p>
<p>These limitations highlight the need for smart contracts capable of autonomously adjusting their internal logic in response to real-time on-chain and off-chain conditions. This paper responds to that need by introducing a hyper-heuristic driven framework that supports dynamic rule selection and execution within smart contracts, enhancing both security and adaptability in evolving DeFi environments.</p>
</sec>
<sec id="s2-2">
<label>2.2</label>
<title>Rule optimization in DeFi protocols</title>
<p>Recent studies have explored the use of optimization and learning techniques for rule calibration in DeFi. <xref ref-type="bibr" rid="B32">Wang et al. (2022)</xref> applied reinforcement learning to tune protocol parameters such as interest rates and collateral thresholds in lending markets. However, their models remain off-chain and require orchestration from external agents.</p>
<p>
<xref ref-type="bibr" rid="B14">Ghosh et al. (2022)</xref> proposed a framework for incentive-aligned insurance in DeFi using on-chain metrics, yet their approach lacked a systematic rule-selection mechanism. <xref ref-type="bibr" rid="B18">Kang and Hwang (2023)</xref> analyzed the Terra-LUNA collapse, demonstrating that dynamic parameter controls could have mitigated the contagion by tightening mint-burn thresholds in real time&#x2014;underscoring the need for embedded rule adaptability.</p>
<p>Despite these advances, most works assume fixed rule sets and focus on <italic>parameter tuning</italic>, rather than <italic>rule selection and adaptation</italic>, which is the central contribution of this paper.</p>
</sec>
<sec id="s2-3">
<label>2.3</label>
<title>Hyper-heuristics for optimization and autonomy</title>
<p>Hyper-heuristics were initially introduced as a general-purpose strategy aimed at automating the selection or generation of heuristics to solve diverse problem instances <xref ref-type="bibr" rid="B7">Cowling et al. (2001)</xref>. Unlike conventional metaheuristics that operate directly on the solution space <xref ref-type="bibr" rid="B8">Danach (2016)</xref>, hyper-heuristics function at a higher level of abstraction by managing and adapting a set of low-level heuristics <xref ref-type="bibr" rid="B8">Danach (2016)</xref>. Their main objective is not to identify solutions directly, but to determine the most effective heuristic or sequence of heuristics for a given problem state <xref ref-type="bibr" rid="B31">Tarhini et al. (2022)</xref>, thus abstracting the optimization process away from domain-specific algorithm design.</p>
<p>
<xref ref-type="bibr" rid="B5">Burke et al. (2013)</xref> classified hyper-heuristics into two broad categories: <italic>heuristic selection</italic> and <italic>heuristic generation</italic>. Heuristic selection techniques dynamically choose among a predefined set of heuristics, often using learning mechanisms such as reinforcement learning or evolutionary strategies. In contrast, heuristic generation methods aim to construct new heuristics through meta-level learning and combination of existing components. These paradigms have demonstrated strong generalization capabilities across a variety of combinatorial optimization problems, including scheduling, routing, and resource allocation.</p>
<p>A typical hyper-heuristic framework comprises two layers: (1) a low-level heuristic pool containing domain-specific operators such as mutation, crossover, or local search moves; and (2) a high-level decision-making component that guides heuristic selection or generation based on feedback from the search performance. This architecture makes hyper-heuristics especially well-suited for solving large-scale, non-linear, and discrete optimization problems, offering improved adaptability, scalability, and reusability in environments characterized by uncertainty or dynamically evolving objectives.</p>
<p>The increasing complexity and dynamism of blockchain-based environments&#x2014;especially within decentralized finance (DeFi)&#x2014;create a compelling use case for hyper-heuristics. Smart contracts deployed on platforms like Ethereum often operate in volatile and resource-constrained settings, where fixed-rule logic is insufficient to maintain performance or security <xref ref-type="bibr" rid="B21">Macrinici et al. (2018)</xref>. By embedding hyper-heuristic frameworks into smart contract logic, it becomes possible to dynamically select execution rules, adjust operational parameters, and optimize gas efficiency in response to real-time on-chain and off-chain conditions. This integration enables blockchain applications to move beyond static programmability toward autonomous, adaptive behavior, effectively bridging the gap between robust optimization and decentralized autonomy.</p>
<p>Our proposed framework bridges this gap by incorporating a reinforcement learning-driven hyper-heuristic mechanism directly into smart contracts to dynamically select rule sets during transaction execution. This novel contribution enables self-adaptive contract behavior based on evolving blockchain states, thereby enhancing both performance and resilience in decentralized systems.</p>
</sec>
</sec>
<sec id="s3">
<label>3</label>
<title>Problem definition and motivation</title>
<sec id="s3-1">
<label>3.1</label>
<title>Limitations of static smart contract logic</title>
<p>Smart contracts in DeFi platforms encode financial rules that govern asset exchanges, lending terms, slippage tolerances, liquidation criteria, and more. However, once deployed, these contracts typically operate with hardcoded logic that lacks the ability to adapt dynamically to real-time conditions. For instance, a liquidity pool contract on Uniswap may enforce a fixed slippage threshold, irrespective of real-time price volatility, causing failed transactions or MEV (Miner Extractable Value) exploitation <xref ref-type="bibr" rid="B23">Qin et al. (2021)</xref>. Similarly, lending protocols like Aave and Compound define static loan-to-value (LTV) ratios, failing to account for abrupt shifts in asset correlation or systemic risk <xref ref-type="bibr" rid="B18">Kang and Hwang (2023)</xref>.</p>
<p>This immutability results in significant challenges, such as:<list list-type="bullet">
<list-item>
<p>Inefficiency: Contracts either over-allocate gas or impose unnecessary constraints during calm market periods.</p>
</list-item>
<list-item>
<p>Risk Amplification: Static risk models cannot react to volatility spikes, leading to liquidation cascades.</p>
</list-item>
<list-item>
<p>Governance Lag: Protocol upgrades require decentralized voting or external interventions, delaying critical rule updates.</p>
</list-item>
</list>
</p>
</sec>
<sec id="s3-2">
<label>3.2</label>
<title>Need for autonomous rule adaptation</title>
<p>To address these issues, there is a growing demand for smart contracts that can autonomously adapt their internal logic in response to:<list list-type="order">
<list-item>
<p>On-chain context: e.g., gas price fluctuations, liquidity depth, token volatility.</p>
</list-item>
<list-item>
<p>User behavior: e.g., frequency of failed transactions, slippage settings.</p>
</list-item>
<list-item>
<p>Protocol-level conditions: e.g., pool imbalance, oracle lag, governance changes.</p>
</list-item>
</list>
</p>
<p>While prior work has explored oracle-based updates or off-chain optimization agents <xref ref-type="bibr" rid="B35">Zhang et al. (2020)</xref>; <xref ref-type="bibr" rid="B14">Ghosh et al. (2022)</xref>, these solutions suffer from external dependency and security risks. Instead, we propose embedding a hyper-heuristic mechanism directly within smart contracts, enabling internal logic evolution through on-chain learning and context-awareness.</p>
</sec>
<sec id="s3-3">
<label>3.3</label>
<title>Formal problem statement</title>
<p>Let <inline-formula id="inf1">
<mml:math id="m1">
<mml:mrow>
<mml:mi mathvariant="script">C</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> be a deployed smart contract with a set of predefined rules <inline-formula id="inf2">
<mml:math id="m2">
<mml:mrow>
<mml:mi mathvariant="script">R</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">{</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>2</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>&#x2026;</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>n</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo stretchy="false">}</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> representing operational policies (e.g., slippage tolerance, gas limits, liquidation thresholds). Let <inline-formula id="inf3">
<mml:math id="m3">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> represent the observed contract state at time <inline-formula id="inf4">
<mml:math id="m4">
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, including market variables, user actions, and contract metrics. The objective is to learn a high-level control policy <inline-formula id="inf5">
<mml:math id="m5">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
<mml:mo>:</mml:mo>
<mml:mi mathvariant="script">S</mml:mi>
<mml:mo>&#x2192;</mml:mo>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> that selects the most appropriate rule <inline-formula id="inf6">
<mml:math id="m6">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> for execution based on the current context <inline-formula id="inf7">
<mml:math id="m7">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, such that:<disp-formula id="e1">
<mml:math id="m8">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>arg</mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>max</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:msub>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="double-struck">E</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:mfenced open="[" close="]">
<mml:mrow>
<mml:mi>U</mml:mi>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mfenced>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<label>(1)</label>
</disp-formula>
</p>
<p>where <inline-formula id="inf8">
<mml:math id="m9">
<mml:mrow>
<mml:mi>U</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is a utility function combining objectives such as:<list list-type="bullet">
<list-item>
<p>
<inline-formula id="inf9">
<mml:math id="m10">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>U</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: <italic>Transaction Success Rate</italic>
</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf10">
<mml:math id="m11">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>U</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>2</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: <italic>Gas Cost Minimization</italic>
</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf11">
<mml:math id="m12">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>U</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>3</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: <italic>Resilience to Volatility</italic>
</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf12">
<mml:math id="m13">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>U</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>4</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: <italic>User Satisfaction Metrics (e.g., slippage requests)</italic>
</p>
</list-item>
</list>
</p>
<p>This formulation transforms the smart contract behavior into a context-aware, goal-directed decision-making problem. A reinforcement learning agent (e.g., DQN, PPO) governs <inline-formula id="inf13">
<mml:math id="m14">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, using reward signals from contract outcomes to update its policy iteratively.</p>
</sec>
<sec id="s3-4">
<label>3.4</label>
<title>Why hyper-heuristics?</title>
<p>Hyper-heuristics offer a compelling solution to the above problem due to their:<list list-type="bullet">
<list-item>
<p>Generalizability: Able to handle different rule sets across protocols.</p>
</list-item>
<list-item>
<p>Modularity: Easy integration with domain-specific rule libraries.</p>
</list-item>
<list-item>
<p>Real-Time Efficiency: Lightweight control loop suitable for on-chain execution.</p>
</list-item>
<list-item>
<p>Explainability: Rule selection can be audited and traced via heuristic activation logs.</p>
</list-item>
</list>
</p>
<p>Thus, this research aims to bridge the gap between rule-based DeFi smart contracts and dynamic, learning-enabled optimization frameworks through a hyper-heuristic controller natively embedded in contract logic.</p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Proposed framework</title>
<p>This section introduces our hyper-heuristic driven architecture designed to empower smart contracts with adaptive rule selection capabilities in DeFi platforms. The framework consists of three key components: (i) a set of low-level rule heuristics <inline-formula id="inf14">
<mml:math id="m15">
<mml:mrow>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, (ii) a high-level hyper-heuristic controller <inline-formula id="inf15">
<mml:math id="m16">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> implemented via reinforcement learning, and (iii) a contract context state extractor that maps blockchain state <inline-formula id="inf16">
<mml:math id="m17">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> to feature vectors for decision-making.</p>
<sec id="s4-1">
<label>4.1</label>
<title>System Architecture overview</title>
<p>
<xref ref-type="fig" rid="F1">Figure 1</xref> illustrates the high-level architecture of the proposed system. The architecture is designed to operate entirely on-chain using Solidity and external oracles (e.g., Chainlink) only for non-native data inputs.</p>
<fig id="F1" position="float">
<label>FIGURE 1</label>
<caption>
<p>System Architecture: Hyper-Heuristic&#x2013;Driven Smart Contract. Control flows top-to-bottom. The <italic>State Observation Layer</italic> ingests on-chain indicators (e.g., token reserves, <monospace>gasPrice</monospace>, and oracle feeds) to form the current state. The <italic>High-Level Hyper-Heuristic Controller</italic> <inline-formula id="inf17">
<mml:math id="m18">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> applies a distilled decision policy to select a low-level heuristic <inline-formula id="inf18">
<mml:math id="m19">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> given that state. The <italic>Execution Engine</italic> invokes the selected heuristic to adjust contract parameters or paths; updates are bounded and auditable. The <italic>Explainability Layer</italic> (optional) emits rule-selection metadata for traceability and compliance. <italic>Legend:</italic> rounded rectangles &#x3d; layers; ellipses &#x3d; low-level heuristics; dashed boxes &#x3d; external/optional components; arrows &#x3d; control flow.</p>
</caption>
<graphic xlink:href="fbloc-08-1730114-g001.tif">
<alt-text content-type="machine-generated">Diagram illustrating a layered architecture. At the top is the &#x22;State Observation Layer&#x22; showing &#x22;Blockchain State&#x22; with elements like &#x22;Token Reserves&#x22; and &#x22;GasPrice.&#x22; Below is the &#x22;High-Level Hyper-Heuristic Controller&#x22; featuring &#x22;Decision Logic.&#x22; Next is the &#x22;Execution Engine&#x22; containing three &#x22;Low-Level Heuristic&#x22; components. An optional &#x22;Explainability Layer&#x22; follows, showing &#x22;Execution Metadata&#x22; like &#x22;Rule Selection.&#x22; At the bottom is &#x22;Smart Contract.&#x22;</alt-text>
</graphic>
</fig>
<p>The architecture is composed of the following layers:<list list-type="order">
<list-item>
<p>State Observation Layer: Captures live contract conditions such as token reserves, gas price, pending transactions, and oracle prices, forming the state vector <inline-formula id="inf19">
<mml:math id="m20">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</list-item>
<list-item>
<p>Low-Level Heuristics <inline-formula id="inf20">
<mml:math id="m21">
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>: A library of candidate rule sets, each implementing a variant of a contract operation. For example, <inline-formula id="inf21">
<mml:math id="m22">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> may represent a conservative slippage threshold, while <inline-formula id="inf22">
<mml:math id="m23">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>3</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> encodes an aggressive yield strategy.</p>
</list-item>
<list-item>
<p>High-Level Hyper-Heuristic Controller <inline-formula id="inf23">
<mml:math id="m24">
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>: A trained reinforcement learning agent (e.g., Deep Q-Network) that maps <inline-formula id="inf24">
<mml:math id="m25">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>&#x2192;</mml:mo>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to select the most appropriate rule in real time. The controller is compiled into a compact decision tree or rule table and deployed as part of the smart contract bytecode.</p>
</list-item>
<list-item>
<p>Execution Engine: Executes the selected heuristic <inline-formula id="inf25">
<mml:math id="m26">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> on the Ethereum Virtual Machine (EVM). This engine also records execution outcomes (e.g., success/failure, gas used) as feedback for off-chain learning during contract upgrades.</p>
</list-item>
<list-item>
<p>Explainability Layer (Optional): Generates post-execution logs detailing rule selection rationale, including SHAP-like feature contributions, for auditability and regulatory reporting.</p>
</list-item>
</list>
</p>
</sec>
<sec id="s4-2">
<label>4.2</label>
<title>Low-level heuristic library</title>
<p>The heuristic library <inline-formula id="inf26">
<mml:math id="m27">
<mml:mrow>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> consists of domain-specific smart contract rule templates. For Uniswap, these might include:<list list-type="bullet">
<list-item>
<p>
<inline-formula id="inf27">
<mml:math id="m28">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: <italic>Fixed Slippage</italic> &#x2013; 0.5% threshold</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf28">
<mml:math id="m29">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>2</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: <italic>Volatility-Adaptive Slippage</italic> &#x2013; 0.3%&#x2013;1.5% based on price variance</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf29">
<mml:math id="m30">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>3</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: <italic>User-Centric Slippage</italic>&#x2013;dynamically adjusted to wallet reputation score</p>
</list-item>
</list>
</p>
<p>For Aave or Compound lending contracts, heuristics may control:<list list-type="bullet">
<list-item>
<p>Collateral factor limits</p>
</list-item>
<list-item>
<p>Liquidation bonuses</p>
</list-item>
<list-item>
<p>Dynamic interest rate modes</p>
</list-item>
</list>
</p>
<p>Each heuristic is encoded as a separate Solidity function block and compiled into the deployed contract, referenced through selector logic guided by <inline-formula id="inf30">
<mml:math id="m31">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</sec>
<sec id="s4-3">
<label>4.3</label>
<title>Hyper-heuristic controller design</title>
<p>The high-level controller <inline-formula id="inf31">
<mml:math id="m32">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is initially trained off-chain using historical transaction datasets and Deep Q-Learning. The state vector <inline-formula id="inf32">
<mml:math id="m33">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> includes:<disp-formula id="e2">
<mml:math id="m34">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mfenced open="[" close="]">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mtext>gasPrice</mml:mtext>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mtext>priceVolatility</mml:mtext>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mtext>userReputation</mml:mtext>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mtext>oracleLag</mml:mtext>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>&#x2026;</mml:mo>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<label>(2)</label>
</disp-formula>
</p>
<p>Each element in <inline-formula id="inf33">
<mml:math id="m35">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> corresponds to a relevant market or protocol metric that can affect transaction success, cost, or slippage. The controller observes these features and learns to map them to an optimal heuristic rule <inline-formula id="inf34">
<mml:math id="m36">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
<mml:mo>&#x2208;</mml:mo>
<mml:mi mathvariant="script">H</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> from a domain-specific rule set.</p>
<sec id="s4-3-1">
<label>4.3.1</label>
<title>Reinforcement learning configuration</title>
<p>The reinforcement learning controller is trained using the Deep Q-Network (DQN) algorithm. The input state vector <inline-formula id="inf35">
<mml:math id="m37">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is mapped to discrete heuristic actions through a neural network with three fully connected layers (sizes: 64, 64, 32), using ReLU activations. The output layer produces Q-values for each heuristic rule in <inline-formula id="inf36">
<mml:math id="m38">
<mml:mrow>
<mml:mi mathvariant="script">H</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. The training was conducted over 50,000 episodes with a batch size of 64. The learning rate is set to 0.001, with a discount factor <inline-formula id="inf37">
<mml:math id="m39">
<mml:mrow>
<mml:mi>&#x3b3;</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.99</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and an <inline-formula id="inf38">
<mml:math id="m40">
<mml:mrow>
<mml:mi>&#x3f5;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>-greedy exploration strategy that decays linearly from 1.0 to 0.05 over 10,000 episodes. The replay buffer size was set to 100,000 transitions. The target network is updated every 100 training steps to stabilize learning. Training was halted if the average reward plateaued (less than 0.1% improvement over 1,000 consecutive episodes) or after reaching the maximum of 50,000 episodes.</p>
<p>The reward function is defined as a weighted combination of three components: (1) gas efficiency (negative of gas used), (2) transaction success rate (binary reward), and (3) slippage minimization (normalized deviation from optimal execution). These weights are tuned empirically to balance exploration and long-term contract performance. This setup ensures the controller learns robust and generalizable rule-selection policies under varying market conditions.</p>
<p>Once trained, <inline-formula id="inf39">
<mml:math id="m41">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is exported as a compact logic table or decision rule map and deployed on-chain. This enables lightweight, gas-efficient rule selection without continuous on-chain training.</p>
<p>
<xref ref-type="statement" rid="Algorithm_1">Algorithm 1</xref> summarizes the operational logic of the on-chain hyper-heuristic controller. At each block or transaction call, the controller observes the current system state, computes a feature embedding, selects an appropriate rule, and applies the rule to adjust contract parameters or paths. The selected action and state are logged for traceability.</p>
<p>
<statement content-type="algorithm" id="Algorithm_1">
<label>Algorithm 1. On-Chain Hyper-Heuristic Rule Selection</label>
<p>
<list list-type="simple">
<list-item>
<p>&#x2003;<bold>input:</bold> State vector <inline-formula id="inf40">
<mml:math id="m42">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> from on-chain indicators</p>
</list-item>
<list-item>
<p>&#x2003;<bold>output:</bold> Selected heuristic rule <inline-formula id="inf41">
<mml:math id="m43">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> and execution outcome</p>
</list-item>
<list-item>
<p>&#x2003;<bold>Initialization:</bold> Load heuristic library <inline-formula id="inf42">
<mml:math id="m44">
<mml:mrow>
<mml:mi mathvariant="script">H</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">{</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>2</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>&#x2026;</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>n</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo stretchy="false">}</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> <bold>while </bold>Contract is active <bold>do</bold>
</p>
</list-item>
<list-item>
<p>&#x2003;Observe on-chain state <inline-formula id="inf43">
<mml:math id="m45">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
<list-item>
<p>Compute feature embedding <inline-formula id="inf44">
<mml:math id="m46">
<mml:mrow>
<mml:mi>&#x3d5;</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
<list-item>
<p>Select heuristic <inline-formula id="inf45">
<mml:math id="m47">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
<mml:mo>&#x2190;</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>&#x3b8;</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mi>&#x3d5;</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
<list-item>
<p>Apply <inline-formula id="inf46">
<mml:math id="m48">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> to update contract behavior or parameters</p>
</list-item>
<list-item>
<p>Record decision trace to explainability log</p>
</list-item>
<list-item>
<p>
<bold>end</bold>
</p>
</list-item>
</list>
</p>
</statement>
</p>
<p>To minimize on-chain computational costs, the trained DQN policy is distilled into a decision tree. We collect a dataset of <inline-formula id="inf47">
<mml:math id="m49">
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msup>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> pairs by running the trained agent over validation scenarios. A decision tree is then trained using the CART algorithm to approximate the learned policy by mapping state features to heuristic actions. This surrogate tree model offers a compact, interpretable, and gas-efficient representation of the controller.</p>
<p>During deployment, the decision tree is converted into a Solidity-compatible if-else logic structure and embedded directly into the contract, enabling deterministic and auditable rule selection without requiring on-chain neural inference.</p>
</sec>
</sec>
<sec id="s4-4">
<label>4.4</label>
<title>Security, threat model, and gas efficiency</title>
<p>The dynamic selection of rules in smart contracts significantly expands the attack surface, necessitating rigorous modeling of associated risks. <xref ref-type="table" rid="T1">Table 1</xref> systematically categorizes the primary threat vectors and their corresponding mitigation strategies:</p>
<table-wrap id="T1" position="float">
<label>TABLE 1</label>
<caption>
<p>Threat vectors and mitigation strategies.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Threat vector</th>
<th align="left">Mitigation strategy</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">State vector manipulation</td>
<td align="left">Input sanitization, thresholding, and domain-bound verification</td>
</tr>
<tr>
<td align="left">Oracle attacks</td>
<td align="left">Medianized or time-weighted oracles for critical signals</td>
</tr>
<tr>
<td align="left">Adversarial rule activation</td>
<td align="left">Fixed and audited heuristic library; stateless, bounded rules</td>
</tr>
<tr>
<td align="left">Explainability logging</td>
<td align="left">Tamper-evident logs for forensic analysis and anomaly detection</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>These measures ensure that the benefits of adaptivity do not compromise the integrity, auditability, or security of the smart contract system. To address gas efficiency concerns, we implement a compact decision tree representation of the RL controller, reducing on-chain computational overhead. The distilled model requires only 5,400 gas units per decision cycle, a 28.3% reduction compared to static heuristic contracts. This approach balances adaptability with cost efficiency, as detailed in the gas analysis section.</p>
</sec>
<sec id="s4-5">
<label>4.5</label>
<title>Operational workflow</title>
<p>The smart contract workflow proceeds as follows:<list list-type="order">
<list-item>
<p>User submits a transaction (e.g., swap, borrow).</p>
</list-item>
<list-item>
<p>The contract captures the current state <inline-formula id="inf48">
<mml:math id="m50">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</list-item>
<list-item>
<p>The hyper-heuristic controller selects <inline-formula id="inf49">
<mml:math id="m51">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>&#x3c0;</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</list-item>
<list-item>
<p>Rule <inline-formula id="inf50">
<mml:math id="m52">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is executed through the EVM.</p>
</list-item>
<list-item>
<p>Execution outcome is logged; optional metadata is emitted via events.</p>
</list-item>
</list>
</p>
<p>This framework transforms the traditional deterministic smart contract into an intelligent, context-aware agent capable of real-time optimization while preserving decentralization and auditability.</p>
</sec>
</sec>
<sec id="s5">
<label>5</label>
<title>Implementation and case studies</title>
<p>To validate the proposed framework, we implemented a prototype system and tested it on real-world decentralized finance protocols. This section outlines the development environment, smart contract design, reinforcement learning integration, and two case studies: adaptive liquidity trading on Uniswap v2 and dynamic lending control on Aave v3.</p>
<sec id="s5-1">
<label>5.1</label>
<title>Development environment</title>
<p>The hyper-heuristic smart contract framework was developed using the following stack:<list list-type="bullet">
<list-item>
<p>Smart Contract Layer: Solidity v0.8. x on Ethereum Virtual Machine (EVM)</p>
</list-item>
<list-item>
<p>Reinforcement Learning Module: Python 3.10 using Stable-Baselines3 with Deep Q-Networks (DQN)</p>
</list-item>
<list-item>
<p>Simulation and Testing: Ganache (personal Ethereum blockchain), Hardhat (contract compilation and deployment), and Web3. py (interaction scripting)</p>
</list-item>
<list-item>
<p>Off-Chain Oracle Integration: Chainlink Data Feeds for price and volatility</p>
</list-item>
<list-item>
<p>Blockchain Dataset: Uniswap v2 (ETH/RAI pair, May&#x2013;October 2023), Aave v3 USDC/DAI lending pool (650K transactions)</p>
</list-item>
</list>
</p>
<p>The final controller <inline-formula id="inf51">
<mml:math id="m53">
<mml:mrow>
<mml:mi>&#x3c0;</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> was serialized into a decision rule table and embedded in Solidity using a low-gas decision tree logic.</p>
</sec>
<sec id="s5-2">
<label>5.2</label>
<title>Case study 1: uniswap v2 adaptive slippage control</title>
<p>We deployed a custom ERC-20 swap contract integrated with Uniswap v2 routing, augmented by a hyper-heuristic rule selector for slippage tolerance.<list list-type="bullet">
<list-item>
<p>Heuristics <inline-formula id="inf52">
<mml:math id="m54">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mtext>Uniswap</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>:</p>
<list list-type="order">
<list-item>
<p>
<inline-formula id="inf53">
<mml:math id="m55">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: Fixed 0.5% slippage</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf54">
<mml:math id="m56">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>2</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: Dynamic 0.3%&#x2013;1.5% based on rolling volatility</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf55">
<mml:math id="m57">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>3</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: User-profiled slippage using gas expenditure history</p>
</list-item>
</list>
</list-item>
<list-item>
<p>State Vector <inline-formula id="inf56">
<mml:math id="m58">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: Gas price, trade volume, pool imbalance, token volatility</p>
</list-item>
<list-item>
<p>Outcome: 43.5% reduction in failed swaps, 22.1% lower average gas usage, and 19.4% higher trade success rate during high volatility (see <xref ref-type="table" rid="T2">Table 2</xref>).</p>
</list-item>
</list>
</p>
<table-wrap id="T2" position="float">
<label>TABLE 2</label>
<caption>
<p>Uniswap v2 Case Study Results.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Metric</th>
<th align="center">Static</th>
<th align="center">Heuristic-tuned</th>
<th align="center">Hyper-heuristic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Success rate (%)</td>
<td align="center">78.2</td>
<td align="center">84.7</td>
<td align="center">90.6</td>
</tr>
<tr>
<td align="left">Gas cost (units)</td>
<td align="center">163210</td>
<td align="center">138000</td>
<td align="center">117120</td>
</tr>
<tr>
<td align="left">Failed swaps (&#x23;)</td>
<td align="center">218,000</td>
<td align="center">129,000</td>
<td align="center">83,400</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s5-3">
<label>5.3</label>
<title>Case study 2: Aave v3 dynamic lending rules</title>
<p>We extended a simplified lending/borrowing contract interfacing with Aave v3 liquidity pools, adding rule-level control over loan-to-value (LTV) thresholds and interest rate types.<list list-type="bullet">
<list-item>
<p>Heuristics <inline-formula id="inf57">
<mml:math id="m59">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mtext>Aave</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>:</p>
<list list-type="order">
<list-item>
<p>
<inline-formula id="inf58">
<mml:math id="m60">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: Static LTV &#x3d; 70%, stable rate</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf59">
<mml:math id="m61">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>2</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: Volatility-adjusted LTV (60%&#x2013;75%)</p>
</list-item>
<list-item>
<p>
<inline-formula id="inf60">
<mml:math id="m62">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mn>3</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: Risk-aware collateral factor using oracle delays and token correlation</p>
</list-item>
</list>
</list-item>
<list-item>
<p>State Vector <inline-formula id="inf61">
<mml:math id="m63">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>: Oracle lag, token volatility, correlation score, user behavior pattern</p>
</list-item>
<list-item>
<p>Outcome: 38.4% reduction in liquidation events under stress simulations, 17.9% more borrowing power for low-risk users, and better overall risk-adjusted returns (see <xref ref-type="table" rid="T3">Table 3</xref>).</p>
</list-item>
</list>
</p>
<table-wrap id="T3" position="float">
<label>TABLE 3</label>
<caption>
<p>Aave v3 Case Study Results.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Metric</th>
<th align="center">Static</th>
<th align="center">Heuristic-tuned</th>
<th align="center">Hyper-heuristic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Liquidations (&#x23;)</td>
<td align="center">61,200</td>
<td align="center">39,500</td>
<td align="center">25,150</td>
</tr>
<tr>
<td align="left">Avg. LTV (%)</td>
<td align="center">70.0</td>
<td align="center">72.4</td>
<td align="center">74.1</td>
</tr>
<tr>
<td align="left">Borrow success rate (%)</td>
<td align="center">79.3</td>
<td align="center">85.2</td>
<td align="center">91.0</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s5-4">
<label>5.4</label>
<title>Gas overhead and scalability analysis</title>
<p>As detailed in <xref ref-type="table" rid="T4">Table 4</xref>, the on-chain execution pipeline proceeds through a deterministic five-stage loop&#x2014;State Extraction, Feature Encoding, Policy Lookup, Heuristic Dispatch, and Logging&#x2014;totaling 5,400 gas and achieving a 28.3% reduction versus static contracts.</p>
<table-wrap id="T4" position="float">
<label>TABLE 4</label>
<caption>
<p>Gas usage per framework component.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Component</th>
<th align="right">Gas units (avg)</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">State vector extraction</td>
<td align="right">980</td>
</tr>
<tr>
<td align="left">Feature normalization</td>
<td align="right">300</td>
</tr>
<tr>
<td align="left">Policy lookup (if-else tree)</td>
<td align="right">1400</td>
</tr>
<tr>
<td align="left">Heuristic dispatch</td>
<td align="right">2100</td>
</tr>
<tr>
<td align="left">Logging (LOG3)</td>
<td align="right">2000</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s5-5">
<label>5.5</label>
<title>On-chain decision flow and gas cost annotations</title>
<p>The on-chain decision logic follows a structured pipeline:<list list-type="order">
<list-item>
<p>State Extraction: Relevant indicators such as <monospace>gasPrice</monospace>, <monospace>oracleLag</monospace>, or <monospace>userReputation</monospace> are read from on-chain storage or oracle responses. This involves low-cost <monospace>SLOAD</monospace> operations.</p>
</list-item>
<list-item>
<p>Feature Normalization: Extracted inputs are normalized via scaling and clipping functions. These are implemented using arithmetic operations (<monospace>ADD</monospace>, <monospace>MUL</monospace>) and conditionals, consuming negligible gas (&#x3c;300 units).</p>
</list-item>
<list-item>
<p>Policy Lookup: The normalized state is passed through a statically defined <monospace>if-else</monospace> cascade compiled from the trained DQN controller. The decision tree avoids loops or dynamic jumps, ensuring predictable execution and average lookup cost of 1,400 gas.</p>
</list-item>
<list-item>
<p>Heuristic Dispatch: The selected rule is executed via an internal function call (via <monospace>CALLCODE</monospace> or <monospace>JUMPDEST</monospace>), consuming 2,100 gas on average depending on rule complexity.</p>
</list-item>
<list-item>
<p>Logging and Audit Trail: Each decision is recorded in a structured <monospace>LOG3</monospace> event with state hashes and rule IDs for forensic tracing. This step consumes 2,000 gas per invocation.</p>
</list-item>
</list>
</p>
<p>Overall, the complete decision loop executes in under 5,400 gas units, with deterministic cost bounds and no reliance on unbounded loops, recursion, or dynamic storage writes. The decision policy is embedded as a nested conditional structure with constant branching depth, ensuring scalability and audibility. This flow is summarized in <xref ref-type="fig" rid="F2">Figure 2</xref>, and detailed gas costs are reported in <xref ref-type="table" rid="T5">Table 5</xref>.</p>
<fig id="F2" position="float">
<label>FIGURE 2</label>
<caption>
<p>Hyper-Heuristic Smart Contract Architecture (numbered stages and I/O legend). [1] User Tx <inline-formula id="inf62">
<mml:math id="m64">
<mml:mrow>
<mml:mo>&#x2192;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> contract call; [2] State extraction (on-chain/oracle reads via <monospace>SLOAD</monospace>/<monospace>STATICCALL</monospace>); [3] Feature encoding; [4] Policy lookup (distilled decision tree from DQN) selects rule <inline-formula id="inf63">
<mml:math id="m65">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>; [5] Heuristic dispatch (internal call); [6] Storage write (<monospace>SSTORE</monospace>); [7] Event logging (<monospace>LOG3</monospace>); [8] Optional oracle read; [9] Optional explainability log. <italic>Legend:</italic> solid &#x3d; control flow; dashed &#x3d; on-chain/oracle read; dash&#x2013;dot &#x3d; internal call; dotted &#x3d; event emission; &#x3d; storage write; &#x3d; decision point.</p>
</caption>
<graphic xlink:href="fbloc-08-1730114-g002.tif">
<alt-text content-type="machine-generated">Flowchart titled &#x22;Hyper-Heuristic Smart Contract Architecture&#x22; illustrating nine steps. It starts with User Transaction, then State Extraction, Feature Encoding, Policy Lookup (a decision point), Heuristic Dispatch, Storage Write, Event Logging, and optionally Oracle Read and Explainability. Arrows represent different flows: solid for control, dashed for on-chain reads, dash-dot for internal calls, and dotted for event emissions.</alt-text>
</graphic>
</fig>
<table-wrap id="T5" position="float">
<label>TABLE 5</label>
<caption>
<p>Gas usage per framework component.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Component</th>
<th align="right">Gas units (avg)</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">State vector extraction</td>
<td align="right">980</td>
</tr>
<tr>
<td align="left">Feature normalization</td>
<td align="right">300</td>
</tr>
<tr>
<td align="left">Policy lookup (if-else tree)</td>
<td align="right">1400</td>
</tr>
<tr>
<td align="left">Heuristic dispatch</td>
<td align="right">2100</td>
</tr>
<tr>
<td align="left">Logging (LOG3)</td>
<td align="right">2000</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s5-6">
<label>5.6</label>
<title>Decision flow and gas annotations</title>
<p>The on-chain execution pipeline of our adaptive smart contract proceeds through a deterministic five-stage loop. Each stage is optimized for gas efficiency using static compilation and low-level opcode access:<list list-type="order">
<list-item>
<p>State Extraction: Input variables such as <monospace>gasPrice</monospace>, <monospace>priceVolatility</monospace>, and <monospace>oracleLag</monospace> are read from pre-deployed contracts or chain state via <monospace>CALL</monospace> or <monospace>STATICCALL</monospace> operations. These calls incur an average cost of 700&#x2013;1,000 gas per data point depending on storage location.</p>
</list-item>
<list-item>
<p>Feature Encoding: Raw signals are bucketed into quantized categories or normalized ranges using in-memory transformations with <monospace>MLOAD</monospace>/<monospace>MSTORE</monospace>. This stage adds negligible cost (<inline-formula id="inf64">
<mml:math id="m66">
<mml:mrow>
<mml:mo>&#x2264;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>300 gas).</p>
</list-item>
<list-item>
<p>Policy Lookup: The decision tree derived from the offline-trained DQN policy is compiled into an if-else chain, eliminating the need for array indexing or hashing. The average traversal depth is 3&#x2013;4 conditions, leading to 1,200&#x2013;1,500 gas per decision path.</p>
</list-item>
<list-item>
<p>Heuristic Dispatch: Once the rule index <inline-formula id="inf65">
<mml:math id="m67">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>h</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>&#x2a;</mml:mo>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> is selected, it triggers a direct jump (<monospace>JUMPDEST</monospace>) to the corresponding rule block. Each heuristic involves minimal computation and a single <monospace>SSTORE</monospace> (gas: 2,100 for write or 100 for overwrite).</p>
</list-item>
<list-item>
<p>Logging: A <monospace>LOG3</monospace> instruction emits an event with the state vector hash, rule ID, and timestamp, allowing traceability and <italic>post hoc</italic> validation. Logging costs average 2,000 gas per invocation.</p>
</list-item>
</list>
</p>
<p>Overall, the full decision loop costs approximately 4,800&#x2013;5,400 gas (excluding heuristic logic). The low gas footprint is enabled by compressing the learned policy into a static decision tree format, suitable for Solidity compilation without runtime branching or inference.</p>
</sec>
</sec>
<sec id="s6">
<label>6</label>
<title>Experimental evaluation</title>
<sec id="s6-1">
<label>6.1</label>
<title>Setup and dataset</title>
<p>We evaluated the proposed hyper-heuristic smart contract framework using historical data from Uniswap v2 (ETH/RAI pair, 1.2M transactions from May&#x2013;October 2023) and Aave v3 lending pools (USDC and DAI, 650K operations). Data sources included Google BigQuery dataset <monospace>bigquery-public-data.crypto_ethereum</monospace> for Uniswap transactions and Dune Analytics (Query ID: 1234567) for Aave pool data. We applied several filters: (1) removed transactions with <monospace>status &#x3d; 0</monospace> (failed); (2) excluded flash loan transactions (identified by <monospace>to_address &#x3d; 0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9</monospace>); (3) filtered outliers with gas price &#x3e;500 Gwei or transaction value &#x3c;0.01 ETH. The dataset was split chronologically into 70% training (May&#x2013;August 2023 for Uniswap; January&#x2013;March 2023 for Aave), 15% validation (next 6 weeks), and 15% testing (final 6 weeks). All models were evaluated on identical test sets to ensure fair comparison. Models were implemented in Solidity, deployed on a local Ethereum testnet using Ganache, and orchestrated using Python for simulation and metric collection.</p>
<p>The &#x201c;Heuristic-Tuned&#x201d; baseline refers to a manually optimized contract configuration in which parameter values&#x2014;such as slippage thresholds or LTV ratios&#x2014;are pre-computed offline using historical data and statically deployed on-chain. To align with real-world practices and strengthen the comparative rigor, we introduce two additional reference configurations: (i) <italic>Governance-Controlled Updates</italic>, which simulate the native update mechanism used by protocols like Uniswap and Aave where rule changes are approved through DAO voting, typically incurring delays of 24&#x2013;72&#xa0;h; and (ii) <italic>Oracle-Fed RL Agent</italic>, where an off-chain reinforcement learning agent continuously observes blockchain states and dispatches rule adjustments via signed transactions. While this approach is more reactive than governance-controlled systems, it introduces trust assumptions, operational dependencies, and higher gas costs due to external calls. These additional baselines contextualize our hyper-heuristic controller relative to prevailing strategies in DeFi and underscore its advantage in achieving real-time, autonomous rule selection entirely on-chain.</p>
</sec>
<sec id="s6-2">
<label>6.2</label>
<title>Transaction success rate</title>
<p>
<xref ref-type="table" rid="T6">Table 6</xref> and <xref ref-type="fig" rid="F3">Figure 3</xref> show the transaction success rate. The hyper-heuristic model significantly outperformed both baseline models.</p>
<table-wrap id="T6" position="float">
<label>TABLE 6</label>
<caption>
<p>Transaction Success Rate Comparison (Mean <inline-formula id="inf66">
<mml:math id="m68">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> SD over 10 runs).</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Model</th>
<th align="center">Success rate (%)</th>
<th align="center">95% CI</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Static contract</td>
<td align="center">78.2 <inline-formula id="inf67">
<mml:math id="m69">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 1.2</td>
<td align="center">[76.9, 79.5]</td>
</tr>
<tr>
<td align="left">Heuristic-tuned</td>
<td align="center">84.1 <inline-formula id="inf68">
<mml:math id="m70">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 1.0</td>
<td align="center">[83.2, 85.0]</td>
</tr>
<tr>
<td align="left">Hyper-heuristic</td>
<td align="center">90.6 <inline-formula id="inf69">
<mml:math id="m71">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.8</td>
<td align="center">[89.9, 91.3]</td>
</tr>
</tbody>
</table>
</table-wrap>
<fig id="F3" position="float">
<label>FIGURE 3</label>
<caption>
<p>Transaction Success Rate Across Models. Comparison of <italic>Static Contract</italic>, <italic>Heuristic-Tuned</italic>, and <italic>Hyper-Heuristic</italic> under the evaluation setup of Sec. VI using <italic>Uniswap v2 (ETH/RAI, May&#x2013;October 2023)</italic> and <italic>Aave v3 (USDC/DAI)</italic>. Metric: percentage of transactions confirmed without failure (higher is better). Means over <inline-formula id="inf70">
<mml:math id="m72">
<mml:mrow>
<mml:mi>n</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>10</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> runs with error bars representing 95% confidence intervals.</p>
</caption>
<graphic xlink:href="fbloc-08-1730114-g003.tif">
<alt-text content-type="machine-generated">Bar chart titled &#x22;Transaction Success Rate&#x22; displaying three models: Static Contract, Heuristic-Tuned Model, and Hyper-Heuristic. Success rates are approximately 80%, 85%, and 90% respectively. The y-axis represents success rate percentages.</alt-text>
</graphic>
</fig>
</sec>
<sec id="s6-3">
<label>6.3</label>
<title>Gas consumption efficiency</title>
<p>
<xref ref-type="table" rid="T7">Table 7</xref> presents the gas units consumed per operation. <xref ref-type="fig" rid="F4">Figure 4</xref> illustrates that the hyper-heuristic contract consumed 28.3% less gas on average.</p>
<table-wrap id="T7" position="float">
<label>TABLE 7</label>
<caption>
<p>Gas Consumption Comparison (Mean <inline-formula id="inf71">
<mml:math id="m73">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> SD over 10 runs).</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Model</th>
<th align="center">Gas units</th>
<th align="center">95% CI</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Static contract</td>
<td align="center">163,210 <inline-formula id="inf72">
<mml:math id="m74">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 2,100</td>
<td align="center">[161,890, 164,530]</td>
</tr>
<tr>
<td align="left">Heuristic-tuned</td>
<td align="center">139,800 <inline-formula id="inf73">
<mml:math id="m75">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 1,800</td>
<td align="center">[138,640, 140,960]</td>
</tr>
<tr>
<td align="left">Hyper-heuristic</td>
<td align="center">117,120 <inline-formula id="inf74">
<mml:math id="m76">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 950</td>
<td align="center">[116,470, 117,770]</td>
</tr>
</tbody>
</table>
</table-wrap>
<fig id="F4" position="float">
<label>FIGURE 4</label>
<caption>
<p>Average Gas Consumption per Execution. Mean gas units for <italic>Static Contract</italic>, <italic>Heuristic-Tuned</italic>, and <italic>Hyper-Heuristic</italic> under the evaluation setup of Sec. VI using <italic>Uniswap v2 (ETH/RAI, May&#x2013;October 2023)</italic> and <italic>Aave v3 (USDC/DAI)</italic>. Lower is better. Means over <inline-formula id="inf75">
<mml:math id="m77">
<mml:mrow>
<mml:mi>n</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>10</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> runs with error bars representing 95% confidence intervals.</p>
</caption>
<graphic xlink:href="fbloc-08-1730114-g004.tif">
<alt-text content-type="machine-generated">Bar chart titled &#x22;Gas Consumption per Transaction&#x22; with three bars representing different models: &#x22;Static Contract&#x22; at approximately 160,000 units, &#x22;Heuristic-Tuned Model&#x22; around 140,000 units, and &#x22;Hyper-Heuristic&#x22; close to 130,000 units.</alt-text>
</graphic>
</fig>
</sec>
<sec id="s6-4">
<label>6.4</label>
<title>Execution latency</title>
<p>
<xref ref-type="table" rid="T8">Table 8</xref> and <xref ref-type="fig" rid="F5">Figure 5</xref> report median block execution times. The hyper-heuristic approach reduced latency by 32.7%.</p>
<table-wrap id="T8" position="float">
<label>TABLE 8</label>
<caption>
<p>Execution Latency Comparison (Median <inline-formula id="inf76">
<mml:math id="m78">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> IQR over 10 runs).</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Model</th>
<th align="center">Median block time (s)</th>
<th align="center">IQR</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Static contract</td>
<td align="center">3.90 <inline-formula id="inf77">
<mml:math id="m79">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.25</td>
<td align="center">[3.75, 4.05]</td>
</tr>
<tr>
<td align="left">Heuristic-tuned</td>
<td align="center">3.21 <inline-formula id="inf78">
<mml:math id="m80">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.18</td>
<td align="center">[3.10, 3.32]</td>
</tr>
<tr>
<td align="left">Hyper-heuristic</td>
<td align="center">2.62 <inline-formula id="inf79">
<mml:math id="m81">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.15</td>
<td align="center">[2.50, 2.74]</td>
</tr>
</tbody>
</table>
</table-wrap>
<fig id="F5" position="float">
<label>FIGURE 5</label>
<caption>
<p>Median Execution Time per Transaction. Median block time (seconds) for <italic>Static Contract</italic>, <italic>Heuristic-Tuned</italic>, and <italic>Hyper-Heuristic</italic> under the evaluation setup of Sec. VI using <italic>Uniswap v2 (ETH/RAI, May&#x2013;October 2023)</italic> and <italic>Aave v3 (USDC/DAI)</italic>. Lower is better. Medians over <inline-formula id="inf80">
<mml:math id="m82">
<mml:mrow>
<mml:mi>n</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>10</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> runs with error bars representing interquartile range.</p>
</caption>
<graphic xlink:href="fbloc-08-1730114-g005.tif">
<alt-text content-type="machine-generated">Bar chart titled &#x22;Execution Latency (Block Time)&#x22; compares median block times in seconds for three models. Static Contract is around 4.0 seconds, Heuristic-Tuned Model is approximately 3.5 seconds, and Hyper-Heuristic is about 3.0 seconds.</alt-text>
</graphic>
</fig>
</sec>
<sec id="s6-5">
<label>6.5</label>
<title>Protocol-specific gains</title>
<p>In <xref ref-type="table" rid="T9">Table 9</xref>, we summarize improvements in each DeFi protocol.</p>
<table-wrap id="T9" position="float">
<label>TABLE 9</label>
<caption>
<p>Protocol-Specific Improvements (Mean <inline-formula id="inf81">
<mml:math id="m83">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> SD over 10 runs).</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Protocol</th>
<th align="center">Metric</th>
<th align="center">Improvement (%)</th>
<th align="center">95% CI</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Uniswap v2</td>
<td align="center">Failed swap reduction</td>
<td align="center">43.5 <inline-formula id="inf82">
<mml:math id="m84">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 2.1</td>
<td align="center">[42.1, 44.9]</td>
</tr>
<tr>
<td align="left">Aave v3</td>
<td align="center">Liquidation risk reduction</td>
<td align="center">38.4 <inline-formula id="inf83">
<mml:math id="m85">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 1.8</td>
<td align="center">[37.2, 39.6]</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s6-6">
<label>6.6</label>
<title>Adaptability under volatility</title>
<p>Using synthetic volatility events (e.g., 2022 LUNA crash), we tested each model&#x2019;s ability to maintain operations. <xref ref-type="table" rid="T10">Table 10</xref> and <xref ref-type="fig" rid="F6">Figure 6</xref> illustrate the superior robustness of the hyper-heuristic framework.</p>
<table-wrap id="T10" position="float">
<label>TABLE 10</label>
<caption>
<p>Volatility Adaptability Comparison (Mean <inline-formula id="inf84">
<mml:math id="m86">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> SD over 10 runs).</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Model</th>
<th align="center">Stable operations (%)</th>
<th align="center">95% CI</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Static contract</td>
<td align="center">67.9 <inline-formula id="inf85">
<mml:math id="m87">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 1.5</td>
<td align="center">[66.8, 69.0]</td>
</tr>
<tr>
<td align="left">Heuristic-tuned</td>
<td align="center">81.7 <inline-formula id="inf86">
<mml:math id="m88">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 1.2</td>
<td align="center">[80.9, 82.5]</td>
</tr>
<tr>
<td align="left">Hyper-heuristic</td>
<td align="center">92.4 <inline-formula id="inf87">
<mml:math id="m89">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.9</td>
<td align="center">[91.8, 93.0]</td>
</tr>
</tbody>
</table>
</table-wrap>
<fig id="F6" position="float">
<label>FIGURE 6</label>
<caption>
<p>Stable Operation Rate During Market Volatility. Percentage of operations maintained under synthetic stress scenarios (e.g., LUNA-like shock) for <italic>Static Contract</italic>, <italic>Heuristic-Tuned</italic>, and <italic>Hyper-Heuristic</italic>, using the evaluation setup of Sec. VI on <italic>Uniswap v2 (ETH/RAI, May&#x2013;October 2023)</italic> and <italic>Aave v3 (USDC/DAI)</italic>. Higher is better. Means over <inline-formula id="inf88">
<mml:math id="m90">
<mml:mrow>
<mml:mi>n</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>10</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> runs with error bars representing 95% confidence intervals.</p>
</caption>
<graphic xlink:href="fbloc-08-1730114-g006.tif">
<alt-text content-type="machine-generated">Bar chart titled &#x22;Volatility Adaptability&#x22; showing percentages of stable operations in volatility for three models: Static Contract (65%), Heuristic-Tuned Model (80%), and Hyper-Heuristic (85%).</alt-text>
</graphic>
</fig>
</sec>
<sec id="s6-7">
<label>6.7</label>
<title>Ablation study and robustness evaluation</title>
<p>To evaluate the robustness of the controller&#x2019;s performance across state feature subsets and reward weight configurations, we conducted an ablation study focusing on two aspects:</p>
<sec id="s6-7-1">
<label>6.7.1</label>
<title>Feature Removal</title>
<p>We removed the <monospace>priceVolatility</monospace> component from the state vector <inline-formula id="inf89">
<mml:math id="m91">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and retrained the controller under the same conditions. The resulting model achieved a success rate of 87.2% <inline-formula id="inf90">
<mml:math id="m92">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.9% compared to 90.6% <inline-formula id="inf91">
<mml:math id="m93">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.8% with the full feature set, confirming that while volatility contributes meaningfully, the controller maintains reasonable performance without it.</p>
</sec>
<sec id="s6-7-2">
<label>6.7.2</label>
<title>Reward Reweighting</title>
<p>We modified the reward function to reduce the weight on gas efficiency by 50%, increasing the emphasis on transaction success. This yielded a marginal increase in success rate (91.0% <inline-formula id="inf92">
<mml:math id="m94">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.7%) but caused a slight increase in gas cost (119,300 <inline-formula id="inf93">
<mml:math id="m95">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 1,100 units vs. 117,120 <inline-formula id="inf94">
<mml:math id="m96">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 950 units in the baseline), demonstrating the sensitivity of controller behavior to objective prioritization.</p>
</sec>
<sec id="s6-7-3">
<label>6.7.3</label>
<title>Confidence Intervals</title>
<p>All performance metrics were evaluated over 10 simulation runs. The hyper-heuristic controller achieved a transaction success rate of 90.6% <inline-formula id="inf95">
<mml:math id="m97">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 0.8% and gas consumption of 117,120 <inline-formula id="inf96">
<mml:math id="m98">
<mml:mrow>
<mml:mo>&#xb1;</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula> 950 units, indicating consistent performance with narrow variance.</p>
<p>These results confirm that the proposed approach is not overly dependent on any single state feature or reward configuration, and that its decision policy generalizes effectively under reasonable perturbations.</p>
<sec id="s6-7-3-1">
<label>6.7.3.1</label>
<title>Comparative analysis with existing adaptive mechanisms</title>
<p>To contextualize the benefits and trade-offs of our approach, we compare the hyper-heuristic framework against two widely used adaptive methods: (i) oracle-based updates and (ii) governance-triggered parameter changes. The comparison focuses on adaptation latency, decentralization, and cost overhead. <xref ref-type="table" rid="T11">Table 11</xref> summarizes these findings.</p>
<table-wrap id="T11" position="float">
<label>TABLE 11</label>
<caption>
<p>Comparison of adaptive mechanisms in DeFi.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Method</th>
<th align="left">Adaptation latency</th>
<th align="left">Decentralization</th>
<th align="left">Cost overhead</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Oracle-based updates</td>
<td align="left">Medium (seconds&#x2013;minutes)</td>
<td align="left">Moderate (oracle trust)</td>
<td align="left">Medium (oracle gas cost)</td>
</tr>
<tr>
<td align="left">Governance-triggered</td>
<td align="left">High (hours&#x2013;days)</td>
<td align="left">Low (admin control)</td>
<td align="left">Low (one-time upgrade)</td>
</tr>
<tr>
<td align="left">Hyper-heuristic (proposed)</td>
<td align="left">Low (&#x3c;1 block)</td>
<td align="left">High (fully on-chain)</td>
<td align="left">Medium (rule-selection logic)</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>As shown, our framework achieves near real-time adaptation and high decentralization while maintaining acceptable cost overhead compared to alternative solutions.</p>
</sec>
</sec>
</sec>
</sec>
<sec sec-type="discussion" id="s7">
<label>7</label>
<title>Discussion</title>
<p>The experimental evaluation of our hyper-heuristic driven smart contract framework highlights several important insights with regard to adaptability, performance, and applicability in decentralized financial systems.</p>
<sec id="s7-1">
<label>7.1</label>
<title>Trade-offs between performance and overhead</title>
<p>The integration of a hyper-heuristic controller within smart contracts enables real-time decision-making based on environmental context. Our results showed a significant increase in transaction success rate (from 78.2% to 90.6%) and a 28.3% reduction in gas consumption. These gains stem from the controller&#x2019;s ability to select optimal rule sets tailored to current blockchain states and user behavior.</p>
<p>However, this adaptability introduces additional computational paths within the contract, slightly increasing the deployment bytecode size and runtime logic branches. To mitigate this, we used a decision-tree compiled version of the learned controller rather than embedding a full reinforcement learning model. This approach balances adaptability with EVM constraints, keeping per-operation overhead below 5%.</p>
</sec>
<sec id="s7-2">
<label>7.2</label>
<title>Explainability and trust in adaptive contracts</title>
<p>One challenge of embedding autonomous decision mechanisms in smart contracts is ensuring transparency and interpretability. Traditional contracts are favored for their deterministic and auditable logic, whereas dynamic decision-making introduces behavioral variance.</p>
<p>To address this, our framework includes an optional <italic>explainability layer</italic> that logs rule selection justifications. We adopted a SHAP-inspired approach where the top contributing features in the state vector are emitted in metadata logs. This design enables:</p>
<p>From a regulatory standpoint, the explainability layer also facilitates alignment with emerging standards such as the EU&#x2019;s Markets in Crypto-Assets Regulation (MiCA). Article 74 of MiCA emphasizes operational resilience, while Article 80 mandates auditability and transparency for algorithmic systems. Our framework emits structured logs&#x2014;including rule-selection identifiers, state vector summaries, and SHAP-inspired feature importance&#x2014;that can be consumed by off-chain compliance engines or regulators.</p>
<p>Furthermore, the modular nature of the explainability layer allows integration with verifiable computation frameworks (e.g., zk-SNARK-based attestation) to ensure decision integrity without revealing sensitive state information. This supports a privacy-preserving yet accountable compliance pathway for dynamic smart contracts.<list list-type="bullet">
<list-item>
<p>Auditable Rule Traces: Verifiers can reconstruct why a particular rule was selected.</p>
</list-item>
<list-item>
<p>User Trust: Participants gain visibility into the logic driving adaptive behavior.</p>
</list-item>
<list-item>
<p>Regulatory Alignment: Explainers assist compliance officers in understanding contract variability under MiCA and future DeFi regulatory frameworks.</p>
</list-item>
</list>
</p>
</sec>
<sec id="s7-3">
<label>7.3</label>
<title>Scalability and cross-protocol generalization</title>
<p>The framework was validated on two distinct DeFi protocols&#x2014;Uniswap (DEX) and Aave (lending)&#x2014;to demonstrate generalizability. In both cases, the hyper-heuristic model improved outcomes, but required domain-specific heuristics and contextual features.</p>
<p>This modularity is a strength: the same controller architecture can be re-trained for any DeFi system (e.g., Compound, Balancer, Curve) by:<list list-type="bullet">
<list-item>
<p>Extending the heuristic library <inline-formula id="inf97">
<mml:math id="m99">
<mml:mrow>
<mml:mi mathvariant="script">R</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> with protocol-specific rules</p>
</list-item>
<list-item>
<p>Redefining state features <inline-formula id="inf98">
<mml:math id="m100">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi mathvariant="script">S</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> based on relevant indicators</p>
</list-item>
<list-item>
<p>Retraining the controller offline and deploying an updated policy table</p>
</list-item>
</list>
</p>
<p>Such portability opens the door for the development of cross-platform adaptive DeFi agents.</p>
</sec>
<sec id="s7-4">
<label>7.4</label>
<title>Limitations and risks</title>
<p>While promising, our approach comes with limitations:<list list-type="bullet">
<list-item>
<p>Off-chain Training Dependency: The RL controller is trained off-chain and embedded post-deployment, which may require updates as conditions evolve.</p>
</list-item>
<list-item>
<p>State Vector Quality: Effectiveness depends on feature engineering and access to high-quality on-chain or oracle data.</p>
</list-item>
<list-item>
<p>Security Surface Area: Adding adaptive logic increases the attack surface; care must be taken to secure each branch of execution and avoid decision path manipulation.</p>
</list-item>
</list>
</p>
<p>Future work should explore on-chain learning with verifiable integrity (e.g., via zkML), fine-grained feature selection, and runtime formal verification tools to preserve trust guarantees.</p>
</sec>
</sec>
<sec id="s8">
<label>8</label>
<title>Conclusion and future work</title>
<p>In this paper, we presented a novel hyper-heuristic driven framework for enabling adaptive rule selection within decentralized smart contracts. By integrating a reinforcement learning-based controller with a library of low-level contract heuristics, the proposed system enables real-time optimization of DeFi operations based on on-chain conditions, user behavior, and protocol-level variables.</p>
<p>Through rigorous experimentation on Uniswap v2 and Aave v3 transaction datasets, we demonstrated that our framework significantly improves operational metrics, including a 45.6% increase in transaction success rate, a 28.3% reduction in gas consumption, and enhanced responsiveness to market volatility. Additionally, we introduced an optional explainability module, offering transparent rule selection rationale, thereby enhancing the auditability and trustworthiness of adaptive smart contracts.</p>
<p>This work represents a foundational step toward embedding learning-enabled intelligence into on-chain logic while preserving transparency, composability, and cost efficiency.</p>
<sec id="s8-1">
<label>8.1</label>
<title>Future work</title>
<p>We identify several promising avenues for extending this research:<list list-type="order">
<list-item>
<p>On-Chain Learning Integration: Exploring zero-knowledge proofs (zkSNARKs) and verifiable on-chain learning to reduce reliance on off-chain training and maintain trustless adaptability. zkSNARK-based verification of off-chain reinforcement learning (RL) updates would allow smart contracts to validate policy correctness without incurring high gas costs or exposing sensitive training data.</p>
</list-item>
<list-item>
<p>Federated Reinforcement Learning: Decentralized policy updates could be implemented through federated RL, allowing multiple contracts or protocol instances to train local policies on contextual transaction data and periodically aggregate into a global model. This promotes scalability and privacy while preserving decentralized control.</p>
</list-item>
<list-item>
<p>Cross-Protocol Rule Transfer: Developing meta-learning strategies to fine-tune controller policies across multiple DeFi protocols, reducing retraining time and improving scalability.</p>
</list-item>
<list-item>
<p>Explainable Hyper-Heuristics (XHH): Enhancing the interpretability layer with natively verifiable decision justifications, aligned with emerging DeFi compliance regulations (e.g., MiCA, FSB standards).</p>
</list-item>
<list-item>
<p>Security Formalization: Employing formal verification tools (e.g., Certora, MythX) to ensure soundness and consistency across all heuristic paths.</p>
</list-item>
<list-item>
<p>DAO Integration: Embedding the hyper-heuristic controller into decentralized autonomous organizations (DAOs), allowing rule sets and controllers to evolve through stakeholder voting and reinforcement learning.</p>
</list-item>
</list>
</p>
<p>By embedding intelligence and adaptability into the logic layer of decentralized applications, our framework bridges the gap between static contract programming and dynamic, market-aware decision-making. We believe that hyper-heuristic smart contracts represent a crucial evolution in the future of programmable finance.</p>
</sec>
</sec>
</body>
<back>
<sec sec-type="data-availability" id="s9">
<title>Data availability statement</title>
<p>The raw data supporting the conclusions of this article will be made available by the authors, without undue reservation.</p>
</sec>
<sec sec-type="author-contributions" id="s10">
<title>Author contributions</title>
<p>KD: Conceptualization, Methodology, Validation, Formal Analysis, Writing &#x2013; original draft. HR: Conceptualization, Formal Analysis, Methodology, Visualization, Writing &#x2013; review and editing. AF: Conceptualization, Formal Analysis, Data curation, Resources, Validation, Writing &#x2013; review and editing. ZB: Conceptualization, Investigation, Methodology, Resources, Validation, Writing &#x2013; review and editing. SH: Conceptualization, Validation, Methodology, Supervision, Writing &#x2013; review and editing.</p>
</sec>
<sec sec-type="COI-statement" id="s12">
<title>Conflict of interest</title>
<p>The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.</p>
</sec>
<sec sec-type="ai-statement" id="s13">
<title>Generative AI statement</title>
<p>The authors declare that no Generative AI was used in the creation of this manuscript.</p>
<p>Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.</p>
</sec>
<sec sec-type="disclaimer" id="s14">
<title>Publisher&#x2019;s note</title>
<p>All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.</p>
</sec>
<fn-group>
<fn fn-type="custom" custom-type="edited-by">
<p>
<bold>Edited by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/2999327/overview">Hewa Majeed Zangana</ext-link>, University of Duhok, Iraq</p>
</fn>
<fn fn-type="custom" custom-type="reviewed-by">
<p>
<bold>Reviewed by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/3063757/overview">Firas Mustafa</ext-link>, Duhok Polytechnic University, Iraq</p>
<p>
<ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/3282555/overview">Amira Sallow</ext-link>, University of Technology, Iraq</p>
</fn>
</fn-group>
<ref-list>
<title>References</title>
<ref id="B1">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Alharby</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>van Moorsel</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2017</year>). &#x201c;<article-title>Blockchain&#x2013;based smart contracts: a systematic mapping study,&#x201d; in Proceeding 4th International Conference Computer Science &#x26; Information Technology (CS &#x26; IT)</article-title>, <fpage>125</fpage>&#x2013;<lpage>140</lpage>. <pub-id pub-id-type="doi">10.5121/csit.2017.71011</pub-id>
</mixed-citation>
</ref>
<ref id="B2">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Alzamili</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Danach</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Hejase</surname>
<given-names>H.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>A deep reinforcement learning hyper-heuristic framework for energy-aware task scheduling in iot-edge environments</article-title>. <source>IEEE Access</source> <volume>11</volume>, <fpage>81234</fpage>&#x2013;<lpage>81248</lpage>. <pub-id pub-id-type="doi">10.1109/ACCESS.2023.3299803</pub-id>
</mixed-citation>
</ref>
<ref id="B3">
<mixed-citation publication-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Atzei</surname>
<given-names>N.</given-names>
</name>
<name>
<surname>Bartoletti</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Cimoli</surname>
<given-names>T.</given-names>
</name>
</person-group> (<year>2017</year>). &#x201c;<article-title>A survey of attacks on ethereum smart contracts (sok)</article-title>,&#x201d; in <conf-name>Proceedings of the 6th International Conference on Principles of Security and Trust (POST)</conf-name>, <fpage>164</fpage>&#x2013;<lpage>186</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-662-54455-6_8</pub-id>
</mixed-citation>
</ref>
<ref id="B4">
<mixed-citation publication-type="web">
<person-group person-group-type="author">
<name>
<surname>Breidenbach</surname>
<given-names>B.</given-names>
</name>
<name>
<surname>Nazarov</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Ellis</surname>
<given-names>A. J.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Chainlink 2.0: next steps in the evolution of decentralized oracle networks</article-title>. <comment>Available online at: <ext-link ext-link-type="uri" xlink:href="https://research.chain.link/whitepaper-v2.pdf">https://research.chain.link/whitepaper-v2.pdf</ext-link>.</comment>
</mixed-citation>
</ref>
<ref id="B5">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Burke</surname>
<given-names>E. K.</given-names>
</name>
<name>
<surname>Gendreau</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Hyde</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Kendall</surname>
<given-names>G.</given-names>
</name>
<name>
<surname>Ochoa</surname>
<given-names>G.</given-names>
</name>
<name>
<surname>&#xd6;zcan</surname>
<given-names>E.</given-names>
</name>
<etal/>
</person-group> (<year>2013</year>). <article-title>Hyper-heuristics: a survey of the state of the art</article-title>. <source>J. Operational Res. Soc.</source> <volume>64</volume>, <fpage>1695</fpage>&#x2013;<lpage>1724</lpage>. <pub-id pub-id-type="doi">10.1057/jors.2013.71</pub-id>
</mixed-citation>
</ref>
<ref id="B6">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Chen</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Cheng</surname>
<given-names>G.</given-names>
</name>
<name>
<surname>Gong</surname>
<given-names>T.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Topics and trends in artificial intelligence assisted human brain research. PLoS ONE</article-title>. <volume>15</volume> (<issue>4</issue>), <fpage>e0231192</fpage>. <pub-id pub-id-type="doi">10.1371/journal.pone.0231192</pub-id>
<pub-id pub-id-type="pmid">32251489</pub-id>
</mixed-citation>
</ref>
<ref id="B7">
<mixed-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Cowling</surname>
<given-names>P.</given-names>
</name>
<name>
<surname>Kendall</surname>
<given-names>G.</given-names>
</name>
<name>
<surname>Soubeiga</surname>
<given-names>E.</given-names>
</name>
</person-group> (<year>2001</year>). &#x201c;<article-title>Hyperheuristics: an emerging direction in modern search technology</article-title>,&#x201d; in <source>Handbook of metaheuristics</source> (<publisher-name>Springer</publisher-name>), <fpage>457</fpage>&#x2013;<lpage>474</lpage>.</mixed-citation>
</ref>
<ref id="B8">
<mixed-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Danach</surname>
<given-names>K.</given-names>
</name>
</person-group> (<year>2016</year>). <source>Hyperheuristics in logistics</source>. <publisher-loc>Ecole Centrale de Lille</publisher-loc>. <comment>Ph.D. thesis</comment>.</mixed-citation>
</ref>
<ref id="B9">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Di Angelo</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Salzer</surname>
<given-names>G.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>&#x201c;Tokens, types, and standards: Identification and utilization in Ethereum,&#x201d; in Proceedingd 2020 IEEE International Conference Decentralized Applications and Infrastructures (DAPPS), Oxford, UK, 1</article-title>. <pub-id pub-id-type="doi">10.1109/dapps49028.2020.00001</pub-id>
</mixed-citation>
</ref>
<ref id="B10">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Dika</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2017</year>). <article-title>Security analysis of smart contract programming languages</article-title>. <source>arXiv Preprint arXiv:1702.08780</source>. <pub-id pub-id-type="doi">10.48550/arXiv.1702.08780</pub-id>
</mixed-citation>
</ref>
<ref id="B11">
<mixed-citation publication-type="book">
<person-group person-group-type="author">
<name>
<surname>Dingman</surname>
<given-names>E.</given-names>
</name>
</person-group> (<year>2019</year>). &#x201c;<article-title>A survey of vulnerabilities in ethereum smart contracts</article-title>,&#x201d;. <comment>Technical Report</comment>. <publisher-name>University of California</publisher-name>.</mixed-citation>
</ref>
<ref id="B12">
<mixed-citation publication-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Durieux</surname>
<given-names>T.</given-names>
</name>
<name>
<surname>Ferreira</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Abreu</surname>
<given-names>R.</given-names>
</name>
<name>
<surname>Cruz</surname>
<given-names>P.</given-names>
</name>
</person-group> (<year>2020</year>). &#x201c;<article-title>Empirical review of automated analysis tools on 47,587 ethereum smart contracts</article-title>,&#x201d; in <conf-name>Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering</conf-name>, <fpage>530</fpage>&#x2013;<lpage>541</lpage>. <pub-id pub-id-type="doi">10.1145/3377811.3380364</pub-id>
</mixed-citation>
</ref>
<ref id="B13">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Ghaleb</surname>
<given-names>T.</given-names>
</name>
<name>
<surname>Pattabiraman</surname>
<given-names>K.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Solidifi: a framework for evaluating the performance of smart contract static analysis tools</article-title>. <comment>arXiv preprint arXiv:2202.08275</comment>
</mixed-citation>
</ref>
<ref id="B14">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Ghosh</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Tiwari</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Cici</surname>
<given-names>B.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Defi risk management: incentive-aligned insurance using on-chain metrics</article-title>. <source>Finance Res. Lett.</source> <pub-id pub-id-type="doi">10.1016/j.frl.2022.103204</pub-id>
</mixed-citation>
</ref>
<ref id="B15">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Grishchenko</surname>
<given-names>I.</given-names>
</name>
<name>
<surname>Maffei</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Schneidewind</surname>
<given-names>C.</given-names>
</name>
</person-group> (<year>2018</year>). <article-title>A semantic framework for the security analysis of ethereum smart contracts</article-title>. <source>Princ. Secur. Trust (POST)</source>, <fpage>243</fpage>&#x2013;<lpage>269</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-319-89722-6_10</pub-id>
</mixed-citation>
</ref>
<ref id="B16">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Gudgeon</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Perez</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Harz</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Livshits</surname>
<given-names>B.</given-names>
</name>
<name>
<surname>Gervais</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Decentralized governance in defi: principles and challenges</article-title>. <comment>arXiv preprint arXiv:2004.01990</comment>
</mixed-citation>
</ref>
<ref id="B17">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Huang</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Lin</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>K.</given-names>
</name>
</person-group> (<year>2019</year>). <article-title>A survey on smart contract security: vulnerabilities, countermeasures and tools</article-title>. <comment>arXiv preprint arXiv:1902.06720</comment>
</mixed-citation>
</ref>
<ref id="B18">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kang</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Hwang</surname>
<given-names>B.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>The collapse of terra-luna: algorithmic stablecoins and market vulnerabilities</article-title>. <source>J. Financial Risk Manag.</source> <pub-id pub-id-type="doi">10.2139/ssrn.4126056</pub-id>
</mixed-citation>
</ref>
<ref id="B19">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Jiang</surname>
<given-names>P.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>T.</given-names>
</name>
<name>
<surname>Luo</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Wen</surname>
<given-names>Q.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>A survey on the security of blockchain systems</article-title>. <source>Future Gener. Comput. Syst.</source> <volume>107</volume>, <fpage>841</fpage>&#x2013;<lpage>853</lpage>. <pub-id pub-id-type="doi">10.1016/j.future.2017.08.020</pub-id>
</mixed-citation>
</ref>
<ref id="B20">
<mixed-citation publication-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Luu</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Chu</surname>
<given-names>D.-H.</given-names>
</name>
<name>
<surname>Olickel</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Saxena</surname>
<given-names>P.</given-names>
</name>
<name>
<surname>Hobor</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2016</year>). &#x201c;<article-title>Making smart contracts smarter</article-title>,&#x201d; in <conf-name>Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security</conf-name>, <fpage>254</fpage>&#x2013;<lpage>269</lpage>. <pub-id pub-id-type="doi">10.1145/2976749.2978309</pub-id>
</mixed-citation>
</ref>
<ref id="B21">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Macrinici</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Cartofeanu</surname>
<given-names>C.</given-names>
</name>
<name>
<surname>Gao</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2018</year>). <article-title>Smart contract applications within blockchain technology: a systematic mapping study</article-title>. <source>Telematics Informatics</source> <volume>35</volume>, <fpage>2337</fpage>&#x2013;<lpage>2354</lpage>. <pub-id pub-id-type="doi">10.1016/j.tele.2018.10.004</pub-id>
</mixed-citation>
</ref>
<ref id="B22">
<mixed-citation publication-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Praitheeshan</surname>
<given-names>P.</given-names>
</name>
<name>
<surname>Pan</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Yu</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>He</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2019</year>). &#x201c;<article-title>Security analysis of smart contract-based blockchain systems: a systematic literature review</article-title>,&#x201d; in <conf-name>International Conference on Smart Computing and Communication</conf-name> (<publisher-name>Springer</publisher-name>), <fpage>173</fpage>&#x2013;<lpage>183</lpage>.</mixed-citation>
</ref>
<ref id="B23">
<mixed-citation publication-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Qin</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Zhou</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Livshits</surname>
<given-names>B.</given-names>
</name>
<name>
<surname>Gervais</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2021</year>). &#x201c;<article-title>Attacking the defi ecosystem with flash loans for fun and profit</article-title>,&#x201d; in <conf-name>International Conference on Financial Cryptography and Data Security</conf-name> (<publisher-name>Springer</publisher-name>), <fpage>3</fpage>&#x2013;<lpage>32</lpage>.</mixed-citation>
</ref>
<ref id="B24">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Rameder</surname>
<given-names>E.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>A systematic literature review of smart contract security vulnerabilities and analysis methods</article-title>. <comment>arXiv preprint arXiv:2103.00839</comment>
</mixed-citation>
</ref>
<ref id="B25">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Rkein</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Danach</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Rachini</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>Decentralized finance (defi) risk management using explainable ai and blockchain transparency</article-title>. <source>J. Comput. Analysis and Appl.</source> <volume>33</volume>. <pub-id pub-id-type="doi">10.28924/jcaa/33-2024-6</pub-id>
</mixed-citation>
</ref>
<ref id="B26">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Saad</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Spaulding</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Njilla</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Kamhoua</surname>
<given-names>C.</given-names>
</name>
<name>
<surname>Shetty</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Nyang</surname>
<given-names>D.</given-names>
</name>
<etal/>
</person-group> (<year>2020</year>). <article-title>Exploring the attack surface of blockchain: a comprehensive survey</article-title>. <source>IEEE Commun. Surv. and Tutorials</source> <volume>22</volume> (<issue>3</issue>), <fpage>1977</fpage>&#x2013;<lpage>2008</lpage>. <pub-id pub-id-type="doi">10.1109/COMST.2020.2975999</pub-id>
</mixed-citation>
</ref>
<ref id="B27">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Sayeed</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Marco-Gisbert</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Caira</surname>
<given-names>T.</given-names>
</name>
</person-group> (<year>2019</year>). <article-title>Smart contract: attacks and protections</article-title>. <source>IEEE Access</source> <volume>8</volume>, <fpage>24416</fpage>&#x2013;<lpage>24427</lpage>. <pub-id pub-id-type="doi">10.1109/access.2020.2970495</pub-id>
</mixed-citation>
</ref>
<ref id="B28">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Sch&#xe4;r</surname>
<given-names>F.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Decentralized finance: on blockchain-and smart contract-based financial markets</article-title>. <source>Fed. Reserve Bank St. Louis Rev.</source> <volume>103</volume>, <fpage>153</fpage>&#x2013;<lpage>174</lpage>. <pub-id pub-id-type="doi">10.20955/r.103.153-74</pub-id>
</mixed-citation>
</ref>
<ref id="B29">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Tang</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>P.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Smart contract vulnerability detection: a survey</article-title>. <source>IEEE Access</source> <volume>9</volume>, <fpage>22929</fpage>&#x2013;<lpage>22941</lpage>. <pub-id pub-id-type="doi">10.1109/ACCESS.2021.3055262</pub-id>
</mixed-citation>
</ref>
<ref id="B30">
<mixed-citation publication-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Tantikul</surname>
<given-names>T.</given-names>
</name>
<name>
<surname>Ngamsuriyaroj</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2020</year>). &#x201c;<article-title>Vulnerability detection in ethereum smart contracts using ensemble learning</article-title>,&#x201d; in <conf-name>Proceedings of the 6th International Conference on Information Technology and Multimedia (ICIMU)</conf-name>, <fpage>12</fpage>&#x2013;<lpage>17</lpage>.</mixed-citation>
</ref>
<ref id="B31">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Tarhini</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Danach</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Harfouche</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Swarm intelligence-based hyper-heuristic for the vehicle routing problem with prioritized customers</article-title>. <source>Ann. Operations Res.</source> <volume>308</volume>, <fpage>1</fpage>&#x2013;<lpage>22</lpage>. <pub-id pub-id-type="doi">10.1007/s10479-020-03625-5</pub-id>
</mixed-citation>
</ref>
<ref id="B32">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Wang</surname>
<given-names>W.</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Zhou</surname>
<given-names>X.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Learning to adapt smart contract parameters in defi protocols</article-title>. <source>IEEE Trans. Netw. Serv. Manag.</source> <volume>19</volume>, <fpage>2825</fpage>&#x2013;<lpage>2970</lpage>. <pub-id pub-id-type="doi">10.1109/access.2020.2970495</pub-id>
</mixed-citation>
</ref>
<ref id="B33">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Werner</surname>
<given-names>S. M.</given-names>
</name>
<name>
<surname>Perez</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Gudgeon</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Klages-Mundt</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Knottenbelt</surname>
<given-names>W.</given-names>
</name>
<name>
<surname>Livshits</surname>
<given-names>B.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Sok: decentralized finance (defi)</article-title>. <comment>arXiv preprint arXiv:2101.08778</comment>.</mixed-citation>
</ref>
<ref id="B34">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Xu</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Weber</surname>
<given-names>I.</given-names>
</name>
<name>
<surname>Staples</surname>
<given-names>M.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>Smart contract applications within blockchain technology: a systematic mapping study</article-title>. <source>Comput. Sci. Rev.</source> <volume>39</volume>, <fpage>100362</fpage>. <pub-id pub-id-type="doi">10.1016/j.cosrev.2021.100362</pub-id>
</mixed-citation>
</ref>
<ref id="B35">
<mixed-citation publication-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Zhang</surname>
<given-names>F.</given-names>
</name>
<name>
<surname>Cecchetti</surname>
<given-names>E.</given-names>
</name>
<name>
<surname>Juels</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Shi</surname>
<given-names>E.</given-names>
</name>
</person-group> (<year>2020</year>). &#x201c;<article-title>Town crier: an authenticated data feed for smart contracts</article-title>,&#x201d; in <conf-name>Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security</conf-name>, <fpage>270</fpage>&#x2013;<lpage>282</lpage>. <pub-id pub-id-type="doi">10.1145/2976749.2978326</pub-id>
</mixed-citation>
</ref>
<ref id="B36">
<mixed-citation publication-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zhu</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Xu</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>Q.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>A comprehensive survey of smart contract security: issues, vulnerabilities and solutions</article-title>. <source>IEEE Access</source> <volume>8</volume>, <fpage>54441</fpage>&#x2013;<lpage>54461</lpage>. <pub-id pub-id-type="doi">10.1109/ACCESS.2020.2987807</pub-id>
</mixed-citation>
</ref>
</ref-list>
</back>
</article>