Decent - fouzantanveer's results

Conceptual Overview

Purpose and Functionality: Decent is a blockchain-based project designed to simplify and enhance the experience of conducting transactions across multiple blockchain networks. In the ever-growing landscape of blockchain technology, one significant challenge users face is the fragmentation of liquidity and assets across different chains. Decent addresses this by enabling seamless transactions, such as payments or asset transfers, using funds or tokens from any blockchain network.

Problem Solving and Need in Web3: The primary problem Decent solves is the complexity and inconvenience in managing assets across multiple blockchains. In the current state of Web3, users often have to navigate through a maze of exchanges, wallets, and bridge services to move assets or make payments on different chains. This not only complicates the user experience but also increases the transaction time and cost. Decent streamlines this process, allowing users to interact with various blockchains easily, using a single interface.

How Decent Works: Decent works by aggregating different functionalities like swapping (exchanging one token for another), bridging (transferring tokens from one blockchain to another), and executing transactions on-chain. It allows users to perform actions like minting an NFT or participating in a DeFi protocol on one blockchain while paying with tokens from another chain. For instance, a user can pay with Ethereum on the Ethereum network for a transaction executed on the Polygon network.

Distinct Features:

• Cross-Chain Transactions: Decent's most notable feature is its ability to facilitate transactions across various blockchains seamlessly. This interoperability is a significant step towards a more integrated and user-friendly blockchain ecosystem.
• Single-Click Transactions: Decent simplifies the transaction process to a single click, significantly improving user experience and accessibility.
• Support for Various Tokens: The platform is designed to interact with any ERC20 token with liquidity, meaning it can handle a wide range of cryptocurrencies.
• Interaction with NFTs: Decent theoretically supports interactions with any ERC721 token, such as NFTs, enabling functionalities like minting through its system.
• Fee Management: The platform includes mechanisms to handle transaction fees efficiently, ensuring that the costs are transparent and minimized.

Insights for Consideration: From a non-technical standpoint, Decent represents a significant leap in making blockchain technology more accessible and practical for everyday users. Its ability to bridge the gaps between various blockchains addresses one of the critical pain points in the current blockchain ecosystem – the siloed nature of different networks. By enabling easy cross-chain interactions, Decent not only enhances the user experience but also opens up new possibilities for decentralized applications (dApps) and services that can operate across multiple blockchains.

In essence, Decent can be viewed as a unifying platform that brings coherence to a fragmented blockchain landscape, making it more user-friendly and efficient. This is especially pertinent in the context of the growing DeFi and NFT spaces, where users frequently interact with multiple blockchains. Decent's approach of simplifying these interactions while maintaining security and efficiency is a noteworthy contribution to the Web3 ecosystem.

Understood, let's dive deeper into the architecture of Decent, focusing on the user interaction flow and the interplay between various contracts and functions.

Architecture

Explanation:

**User Interaction: Represents the initial user action that triggers the process.

• UTB Contract: The central contract that receives the user's call.
• Action Determination: The UTB contract determines whether the action is a swap or a bridge.
• Swapper and Bridge Adapter Contracts: Depending on the action, it interacts with either the Swapper or the Bridge Adapter.
• Token Swap and Bridge Logic: The respective contract executes its core logic, either swapping tokens or bridging them to another chain.
• Execution of Transaction: After the swap/bridge, the transaction needs to be executed.
• UTB Executor Contract: This contract is responsible for executing the transaction.
• Transaction Success or Failure: The outcome of the transaction is determined.
• Completion and Reversion Logic: Depending on the outcome, the process either completes the transaction or handles reversion/refunds.
• User Balance/Status Update: Finally, the user's balance or status is updated, and feedback is provided. **

Sequence Diagram of important functions

This diagram illustrates two key transaction flows in the Decent project:

swapAndExecute Flow: The user initiates a swap-and-execute transaction, leading to a series of calls between the UTB, UniSwapper, and UTBExecutor contracts, with fee collection handled by the UTBFeeCollector.

bridgeAndExecute Flow: Here, the user initiates a bridge-and-execute transaction. The UTB contract interacts with a BridgeAdapter to handle cross-chain bridging, then executes the transaction via the UTBExecutor, and manages fees with the UTBFeeCollector.

User Interaction and Contract Workflow in Decent

1. Starting Point: User Interactions with UTB

   • The journey typically begins with the user interacting with the UTB (Universal Transaction Bridge) contract.

   • Scenario 1: Swap and Execute

     • User wants to perform an action (like minting an NFT) on Chain B but wishes to pay with Token A from Chain A.
     • They interact with swapAndExecute in UTB.
     • Internal Workflow:
       • performSwap: First, if needed, it swaps Token A to a desired intermediate token (using a registered ISwapper, such as UniSwapper if Uniswap is involved).
       • performSwap calls swap on the relevant ISwapper, which handles the logic of interacting with a DEX to perform the actual swap.
       • Post swap, UTB calls UTBExecutor with the swapped token to execute the target action on Chain B.

   • Scenario 2: Bridge and Execute

     • User wants to perform a transaction on Chain B using Token A from Chain A without swapping.
     • They call bridgeAndExecute in UTB.
     • Internal Workflow:
       • swapAndModifyPostBridge: If any pre-bridge token swap is needed, it's performed here.
       • callBridge: This function then calls a bridge operation using a IBridgeAdapter like DecentBridgeAdapter or StargateBridgeAdapter, depending on the chains involved.
       • On the destination chain, the bridged amount is used by UTBExecutor to complete the desired action.

2. Fee Collection - In both scenarios, fees are handled by the UTBFeeCollector. - The collectFees function is called, ensuring that transaction fees are appropriately gathered. The collectFees function in the Decent project's UTBFeeCollector contract is technically structured to handle the intricacies of fee collection across various transactions. This function is invoked with a FeeStructure parameter, which outlines the fee details, including the token type (native or ERC20) and the fee amount. For ERC20 fees, the function executes a transferFrom operation, moving the specified fee amount from the user's account to the fee collector. In the case of native currency fees, the collection is handled through direct value transfers within the transaction.

   A key technical aspect of collectFees is its security and verification process. The function typically includes mechanisms to authenticate the fee structure, possibly using digital signatures to validate that the collected fees align with predetermined criteria or agreements. This verification is crucial for maintaining the integrity of the fee collection process.

3. Handling Refunds and Failures

   In the Decent project, the mechanism for handling refunds and transaction failures is a crucial aspect of its architecture, particularly given the complexity of cross-chain transactions. The contracts are designed to manage various scenarios where a transaction might not go as planned, necessitating a refund.

   When a user initiates a transaction that involves a swap, such as through the UniSwapper contract, the system calculates the exact amount of tokens needed for the swap. If there's an excess – for instance, if the actual amount required for the swap is less than the user provided – the contract is designed to automatically refund the surplus to the user. This process is managed within the swapping contract itself, ensuring that users only spend what is necessary for their transaction.

   In the context of bridging operations, managed by contracts like the DecentBridgeAdapter, the refund mechanism is slightly more complex due to the nature of cross-chain transactions. If a transaction fails after the assets have been bridged to the destination chain, the protocol must ensure that these assets are either returned to the user's original chain or held securely until the user can retrieve them. The bridge contract, therefore, includes logic to detect transaction failures on the destination chain and initiate the appropriate refund process.

   The overarching UTB (Universal Transaction Bridge) contract plays a critical role in orchestrating these operations. It oversees the entire transaction flow – from initiating swaps or bridges to executing the final transaction step. If a failure occurs at any point in this flow, the UTB contract is responsible for triggering the necessary refund actions. This could involve coordinating with the involved swapper or bridge adapter contracts to ensure that the user’s funds are safely returned.

   In essence, the refund mechanism in Decent is an integral part of its transactional architecture, ensuring that users are protected from losing funds in failed transactions. The system is designed to recognize when a transaction doesn't proceed as expected and to automatically take steps to safeguard users' assets, whether that involves refunding excess tokens from a swap or managing more complex scenarios in cross-chain bridges. This approach not only enhances the security and reliability of the platform but also bolsters user trust in engaging with these advanced blockchain operations.

4. DcntEth: ERC-20 Compliance and Token Handling

   • DcntEth.sol complies with the ERC-20 standard and is likely used for handling Decent's native tokens within these transactions.
   • It might be involved when the transaction in UTBExecutor requires dealing with DcntEth tokens (minting or burning in cross-chain operations).

5. DecentEthRouter: Routing Logic

   • It plays a crucial role in managing cross-chain operations, especially in scenarios involving the LayerZero protocol.
   • Its functions might be called post-bridge to handle the delivery of assets or execution of calls on the destination chain.

6. DecentBridgeExecutor: Final Execution

   • For operations that involve bridging, DecentBridgeExecutor might come into play, especially for executing complex cross-chain transactions.

Insights into the Logic of Core Functions

• Flexibility and Interoperability: The architecture is designed for flexibility, allowing users to pay with different tokens across various chains. The use of swappers and bridge adapters makes the system adaptable to various DEXs and bridge services.
• Security and Efficiency: Security is a paramount concern, especially in functions that handle asset transfers and swaps. The use of onlyOwner and similar modifiers ensures controlled access to critical functionalities.
• User-Centric Design: The architecture prioritizes user convenience, minimizing the steps they need to take for cross-chain interactions while ensuring that transactions are processed efficiently and securely.

Logic of swapAndExecute in UTB.sol

1. Function Purpose:

   • swapAndExecute is designed to facilitate transactions that require a token swap before execution. This is typically used for transactions within the same blockchain.

2. Operational Flow:

   • Token Swap: The function begins by calling performSwap, which exchanges the user's token to the required token for the transaction. This involves interacting with a swapper contract (like UniSwapper), which handles the swap logic with an external DEX like Uniswap.
   • Executing Transaction: Post swap, the swapped tokens are used to execute the desired transaction. This is done by calling the UTBExecutor contract with the necessary parameters (target contract, payload, etc.).
   • Fee Handling: Concurrently, the function manages transaction fees through interactions with the UTBFeeCollector.

3. Key Considerations:

   • The function must handle various token standards and ensure accurate execution of swaps.
   • It deals with potential edge cases, such as insufficient liquidity or swap failures, and includes mechanisms to revert or adjust the transaction accordingly.

Logic of bridgeAndExecute in UTB.sol

1. Function Purpose:

   • bridgeAndExecute allows users to execute transactions on a different blockchain using funds from their current blockchain. This involves bridging assets across chains.

2. Operational Flow:

   • Pre-Bridge Swap (If Needed): If the user’s tokens need to be swapped before bridging, swapAndModifyPostBridge is invoked. This function swaps the tokens and prepares them for the bridge operation.
   • Bridging: The function then calls a bridge adapter (like DecentBridgeAdapter or StargateBridgeAdapter) to transfer the assets to the target blockchain. This involves complex interactions with cross-chain protocols.
   • Post-Bridge Execution: Once the assets are on the destination chain, UTBExecutor on that chain executes the intended transaction.
   • Fee Management: Similar to swapAndExecute, this function also handles fees through the UTBFeeCollector.

3. Key Considerations:

   • Ensuring the security and reliability of cross-chain transfers is crucial.
   • The function must account for differences in blockchain protocols and handle potential failures or delays in bridging.

Conclusion

Both swapAndExecute and bridgeAndExecute embody the essence of Decent's cross-chain capabilities. They showcase not only technical sophistication in handling complex blockchain operations but also an intuitive understanding of user needs in the DeFi space. These functions are pivotal in enabling users to navigate the multi-chain landscape seamlessly, making Decent a notable project in the realm of blockchain interoperability. In summary, Decent's architecture is a sophisticated web of smart contracts each designed for specific roles yet collectively working towards a seamless cross-chain transaction experience. From initiating transactions in UTB to executing actions on destination chains via UTBExecutor and DecentBridgeExecutor, the system harmonizes different blockchain operations under one umbrella. The design reflects a deep understanding of cross-chain dynamics and user needs in the blockchain space.

Quality of Codebase:

After an in-depth analysis of the Decent project's codebase, it's clear that the quality is Excellent, showcasing thoughtful architecture and intricate inter-function logic. The codebase demonstrates a sophisticated understanding of blockchain mechanics, especially in terms of cross-chain interactions.

1. Modularity and Readability:

   • The code is well-structured and modular. Functions and contracts are purposefully segmented, enhancing readability and maintainability. This modularity is evident in the separation of concerns between contracts like UTB, UTBExecutor, and various adapters.

2. Complex Logic Handling:

   • Core functions like swapAndExecute and bridgeAndExecute in UTB.sol are implemented with complex yet clear logic. These functions efficiently orchestrate the sequence of operations – swapping, bridging, and executing transactions across different chains.

3. Security Practices:

   • The use of modifiers for access control and adherence to standard security practices, such as checks-effects-interactions pattern, reflects a security-conscious approach. However, the project could benefit from implementing more comprehensive security checks, especially in handling ERC20 approve and transferFrom methods.

Recommendations:

1. Optimization of State Variable Access (GAS-1):

   • To optimize gas usage, it's recommended to cache state variables in local stack variables in functions where they are accessed multiple times.

2. Use of calldata Over memory (GAS-2):

   • Wherever possible, switching function parameters to calldata instead of memory will reduce gas costs, particularly in functions that don't mutate these parameters.

3. Custom Error Handling (GAS-4):

   • Implementing custom error messages instead of revert strings can optimize gas usage, making the code more efficient.

Core Logics of the Project:

1. Cross-Chain Transaction Management:

   • The heart of Decent lies in its ability to manage complex cross-chain transactions seamlessly. This involves a series of swaps and bridges, handled by respective contracts with high efficiency.

2. Fee Collection and Management:

   • UTBFeeCollector demonstrates sophisticated logic for handling transaction fees in various scenarios, crucial for maintaining the economic model of the platform.

3. Security and Efficiency in Swapping and Bridging:

   • The swapping (via UniSwapper) and bridging (via adapters like DecentBridgeAdapter) processes are carefully crafted, balancing security and efficiency. Particularly, the integration with external protocols like Uniswap and the handling of token transfers and approvals are executed with precision.

Conclusion:

Overall, the Decent codebase is technically sound, reflecting a high degree of sophistication in handling cross-chain transactions. While there is always room for optimization, especially in gas usage and security checks, the foundational logic and structure exhibit a high quality of blockchain development practices. The modular design, combined with the intricate interplay of functions and contracts, positions Decent as a technically advanced project in the blockchain space.

Approach in Evaluating the Decent Codebase

Initial Overview from Code4rena: I began by exploring the Code4rena audit overview for Decent (link). This provided a high-level understanding of the project's goals and key components. The overview highlighted Decent's emphasis on cross-chain interoperability and its unique approach to handling transactions, which was insightful for framing the subsequent deep dive into the documentation and code.

Detailed Documentation Review: Next, I examined the detailed documentation on docs.decent.xyz. Though there was not much about the smart contracts yet I reviewed the documentation as I was interested in the front end of web3 websites. All the smart contract related info was in the c4 Overview.

4naly3er Report Analysis: The 4naly3er report provided a useful external perspective. The report provides critical technical insights, particularly highlighting areas for gas optimization and security enhancements. Key issues include the need for state variable caching to reduce expensive storage reads (GAS-1), the more efficient use of calldata over memory for non-mutated function arguments to decrease gas costs (GAS-2), and the application of unchecked blocks for operations that won't cause overflow, thus saving gas by avoiding superfluous safety checks (GAS-3). Additionally, the report underscores the importance of validating approve calls in ERC20 operations (NC-1) and adjusting function visibility from public to external where appropriate for gas savings (NC-2). These findings are pivotal for refining the Decent codebase, focusing on optimizing contract efficiency while maintaining robust security protocols.

Automated Findings Review: Exploring the automated findings helped pinpoint potential vulnerabilities and common issues in the code. This gave me an understanding of the programmers' strengths and weaknesses, guiding my code review towards critical areas that might require more thorough scrutiny.

In-Depth Codebase Review: Armed with comprehensive project knowledge, I delved into the codebase, file by file:

1. src/UTB.sol (232 SLOC): This contract is central to the project, managing the core functions swapAndExecute and bridgeAndExecute. Its intricate logic for handling different transaction types was both complex and elegantly implemented.

2. src/UTBExecutor.sol (52 SLOC): This contract, while smaller, is crucial for executing external contract calls post-swap/bridge. Its streamlined and secure execution flow was noteworthy.

3. src/UTBFeeCollector.sol (50 SLOC): The fee collection logic here is vital for the economic model of Decent. The secure and efficient handling of fee transactions in various token types was impressive.

4. Bridge Adapters (DecentBridgeAdapter.sol & StargateBridgeAdapter.sol): These adapters (137 and 190 SLOC, respectively) implement the bridging functionality. Their ability to interface with different bridging protocols while maintaining a consistent approach to handling assets was a testament to the system’s flexibility.

5. src/swappers/UniSwapper.sol (145 SLOC): As an implementation of ISwapper for Uniswap V3, this contract stood out for its adaptability in swap logic and integration with a major DEX.

6. Decent-Bridge Contracts (DcntEth.sol, DecentEthRouter.sol, DecentBridgeExecutor.sol): These contracts (27, 290, and 57 SLOC, respectively) form the backbone of the bridge logic. The DecentEthRouter.sol, in particular, with its comprehensive bridging logic, was a highlight for its complex yet efficient handling of cross-chain transactions.

Testing and Observations: Following the setup instructions, I ran tests using forge test. One notable observation was how the tests covered a range of scenarios, ensuring that each contract function behaved as expected under different conditions. The tests provided a practical demonstration of the contracts' robustness and the effectiveness of their error-handling mechanisms.

Unique Insights: Throughout this process, what stood out was the harmonious integration of multiple contracts, each with its distinct role, yet all contributing to a cohesive user experience. The project's ability to abstract complex cross-chain interactions into user-friendly functionalities was particularly impressive. Additionally, the meticulous attention to security and efficiency in contract design was evident across the codebase.

Conclusion

In conclusion, my approach to evaluating Decent's codebase was thorough and multi-faceted, encompassing an initial overview, detailed documentation analysis, external report review, and an in-depth examination of each contract. The project's sophisticated handling of cross-chain transactions, combined with its emphasis on security and user experience, positions it as a notable contribution to the blockchain space.

Risks related to the project

Evaluating the Decent project's risk model involves a thorough analysis of various aspects, including administrative, systemic, technical, and integration risks. These risks must be carefully considered to understand their impact on the project's security, functionality, and reliability.

1. Admin Abuse Risks:

• Centralization of Control: The presence of functions like setExecutor, setWrapped, registerSwapper, and registerBridge in UTB.sol and similar administrative functions in other contracts imply a level of centralization. These functions, controlled by the owner or specific roles, could potentially be abused, leading to manipulation or disruption of the system's normal operations.
• Mitigation Strategies:
  • Implement a multi-signature mechanism for critical administrative functions to distribute control.
  • Introduce time-locks for sensitive operations, providing users with a window to react to unfavorable changes.

2. Systemic Risks:

• Dependency on External Protocols: The reliance on external bridges and DEXes like Uniswap for swapping (via UniSwapper.sol) introduces systemic risks. These include liquidity issues, smart contract vulnerabilities in these protocols, or changes in their operation models.
• Inter-Contract Dependencies: The functionality of the system heavily relies on the seamless interaction between contracts like UTB, UTBExecutor, and various adapters and swappers.
• Mitigation Strategies:
  • Regularly update and audit the list of supported protocols and bridges to ensure their security and reliability.
  • Implement robust error handling and fallback mechanisms to manage failures in inter-contract calls.

3. Technical Risks:

• Smart Contract Vulnerabilities: Common risks like reentrancy attacks, overflow/underflow, and unhandled exceptions are pertinent. Although the project demonstrates good security practices, the complexity of functions like swapAndExecute and bridgeAndExecute increases the surface area for potential exploits.
• Gas Optimization: As highlighted in the 4naly3er report, there are several areas where gas optimization can be improved. Inefficient gas usage could make the system economically unviable in the long term, especially during high network congestion.
• Mitigation Strategies:
  • Continuously audit and test the smart contracts, especially after major updates or integration of new features.
  • Implement the suggested gas optimizations to ensure economic efficiency.

4. Integration Risks:

• Interoperability with Multiple Chains: As a cross-chain solution, integration risks include handling different blockchain protocols, transaction finality times, and consensus mechanisms.
• External Dependency: The project's reliance on LayerZero and other bridging protocols for cross-chain functionality introduces risks associated with these external systems.
• Mitigation Strategies:
  • Conduct thorough testing for each blockchain integration, considering their unique characteristics and potential edge cases.
  • Monitor the external protocols and adapt to changes or updates in their systems.

Conclusion:

In conclusion, while the Decent project showcases a technically sophisticated approach to cross-chain transactions, it is not immune to risks typical of complex blockchain systems. Admin abuse risks highlight the need for decentralized governance mechanisms, systemic risks point to dependencies on external systems, technical risks underline the importance of continuous security practices, and integration risks stress the challenges of operating in a multi-chain environment. Proactively addressing these risks through robust design choices, ongoing audits, and adaptive strategies is crucial for the project's long-term success and security.

Recommendations for Software Engineers

Understanding the technical importance of resource management in the context of the Decent project, particularly for the contracts like UniSwapper and bridge contracts, is critical for software engineers. Here's a more technical examination of why each point is significant:

Contract Complexity

• Technical Aspect: In UniSwapper, multiple calls to external contracts such as DEXs (e.g., Uniswap) are made. Each of these calls consumes gas, and when compounded across several operations within a single transaction, the cumulative gas cost can escalate quickly.
• Evidence in Project: Consider a function like swapExactIn in UniSwapper.sol. It first approves the token for swapping, then performs the swap via the Uniswap router. Both steps consume gas, and if this function is part of a larger transaction workflow, the total gas cost can become significant, impacting transaction feasibility.

External Calls and Gas Costs

• Technical Aspect: External calls, particularly those interacting with complex protocols, have variable gas costs that can be hard to predict. Misestimating these costs can lead to transaction failures or inefficiencies.
• Evidence in Project: In bridgeAndExecute within UTB.sol, the contract interacts with bridge adapters. These operations involve external calls whose gas costs can vary based on the current state and activity of the respective blockchain network.

Handling of State Variables

• Technical Aspect: Efficiently handling state variables, especially in smart contracts, is crucial for minimizing gas usage. Every read from and write to storage incurs gas, and these costs can multiply in contracts with frequent state interactions.
• Evidence in Project: In UTB.sol, the contract maintains mappings for swappers and bridge adapters. If these mappings are accessed repeatedly within a single function or transaction flow, it could lead to higher gas consumption than necessary. For instance, frequent access to swappers or bridgeAdapters mappings in the midst of complex transaction logic could be optimized.

Transaction Failure Risks

• Technical Aspect: Underestimating gas requirements, particularly in functions orchestrating multiple steps or interacting with external contracts, can lead to transaction failures. This not only wastes gas but also impacts user confidence.
• Evidence in Project: Functions like swapAndExecute and bridgeAndExecute orchestrate a sequence of actions, including token swaps and cross-chain bridges. If gas estimation for these sequences is not accurate, especially under varying network conditions, it could lead to incomplete transactions, thereby affecting the reliability of the service.

In essence, for software engineers working on the Decent project, focusing on these aspects is not just about optimizing gas costs; it's about ensuring the reliability, efficiency, and user experience of the platform. The challenge lies in managing the complex interplay of contract interactions, state management, and dynamic gas estimations, all crucial for the seamless operation of a cross-chain DeFi platform.

Weakspots

There's potential risk for MEV or transaction frontrun in collectFees()

Analysis of the collectFees Function:

1. Function Implementation:

   • The collectFees function, typically part of a fee management system in blockchain projects, is designed to handle the collection and possibly the redistribution of transaction fees.
   • In Decent's UTBFeeCollector.sol, the function takes the fee details and a signature as parameters. It verifies the signature, ensuring the fee collection request is legitimate.

2. Funds Transfer and Adjusting Fee Parameters:

   • The function does involve transferring ERC20 tokens as part of fee collection. It's essential to verify if this transfer is from a user to the contract (which is less risky) or involves more sensitive transfers (like redistributing funds to other parties).

3. MEV and Frontrunning Risks:

   • MEV risks primarily arise when there's potential for transaction order manipulation to yield profit. In collectFees, if the function transfers fees to different parties or adjusts fee parameters, it might be a potential target for such attacks.
   • Frontrunning risks could occur if attackers can foresee profitable outcomes from the execution of collectFees (e.g., fee distribution) and preemptively submit their transactions.

4. Lack of Deadline Parameter:

   • The absence of a deadline or a similar mechanism in collectFees does not directly expose it to MEV or frontrunning if the function's internal logic doesn't involve operations where transaction ordering can be exploited for profit.
   • However, if the function influences other contract states or financial distributions in a way that could be gamed, then not having a temporal constraint might increase the risk.

Impact and Consideration:

• If collectFees is strictly for collecting fees without influencing other contract states or financial distributions significantly, the lack of a deadline might not pose a high risk.
• However, if the function has a broader impact – for example, it triggers other financial operations or state changes – then the absence of a deadline could make it more susceptible to MEV and frontrunning.

Time spent:

09 hours