Ondo Finance - 0xE1D's results

Ondo Finance Report Analysis:

Overview: The RWADynamicOracle contract provides the implementation for an oracle designed to return the daily price of USDY given certain predefined ranges. The contract relies on OpenZeppelin's AccessControlEnumerable and Pausable contracts to manage roles and provide pausing capabilities.

Key Findings:

- Access Control:
The contract uses OpenZeppelin's AccessControlEnumerable to manage roles, providing a flexible and secure way to handle permissions.

- SETTER_ROLE is in charge of updating price ranges, while the PAUSER_ROLE and DEFAULT_ADMIN_ROLE have the ability to pause and unpause the oracle respectively.

- Price Ranges:
The contract operates by defining ranges for which the daily price of USDY is known.
The price for a given day is computed using a daily interest rate, a start price, and the number of days that have passed since the start of the range.

- Pausability:
The contract can be paused using the pauseOracle function, which restricts the getPrice function to be called.
Only accounts with the PAUSER_ROLE can pause the contract, while unpausing is restricted to those with the DEFAULT_ADMIN_ROLE.

- Price Derivation:
The derivePrice function is used internally to compute the price of USDY for a given range and timestamp. The computed price considers the days elapsed since the start of the range.
Prices are rounded up to the 8th decimal for precision using roundUpTo8.

- Errors & Events:
The contract uses custom error types like InvalidPrice, InvalidRange, and PriceNotSet to revert transactions when necessary.
Two main events, RangeSet and RangeOverriden, are emitted when price ranges are set or modified, providing transparency to users.

Specific Vulnerabilities:

No specific vulnerabilities were identified in the provided code. However, some considerations should be taken into account:

Manipulation of block.timestamp: The contract frequently relies on block.timestamp (or its alias now) to determine the current price. While it's generally safe, miners can manipulate it slightly. However, the impact in this contract is minimal due to the nature of the operations involved.

Rounding Behavior: The function roundUpTo8 rounds values, which might lead to slight imprecisions. While this is a design decision, it's essential to be aware of potential accumulated rounding errors in larger systems that might use this oracle.

Simulation Complexity: The simulateRange function recreates the entire range list to add a simulated range. This operation is computationally heavy, especially as the number of ranges increases, which can make the function costly in terms of gas.

Overlapping Ranges: The setRange and overrideRange functions contain checks to ensure that new or modified ranges do not overlap with existing ranges. However, these functions rely heavily on the correct sequence of operations and external inputs to maintain this integrity. A single oversight or malicious action with admin rights could disrupt the proper functioning of the oracle.

The DestinationBridge smart contract acts as a bridge for cross-chain transactions. It interacts with the Axelar Gateway, implements rate limiting for token minting, and provides a method for administrative management. The contract also integrates an allowlist for authorizing token transfers.

Key Findings:

- Strong Dependency on External Contracts: The contract heavily interacts with external contracts, especially the Axelar Gateway, a token contract (IRWALike), and an allowlist (IAllowlist). The safety and reliability of these contracts directly affect the DestinationBridge contract.

 Versioning Mechanism: The contract uses a constant VERSION to ensure that cross-chain messages are compliant with expected versions.
Approval System: The contract has a multi-signature-like approval system. Transactions require approvals from multiple signers before processing, with the threshold varying based on the transaction amount.

- Rate Limiter for Minting: Minting of tokens is controlled by a time-based rate limiter.
Pausing Mechanism: The contract can be paused or unpaused, which affects the execution of cross-chain messages.

Chain and Source Whitelisting: Not every chain or source address can send cross-chain messages. The contract owner can specify which chains and corresponding source addresses are valid.

Specific Vulnerabilities:

- Potential Centralization in Approvals: Only addresses marked as "approvers" can approve transactions. If these approvers are not decentralized or if their private keys are compromised, it can risk the security of cross-chain transfers.

- Minting Overflow Not Checked: When minting tokens using the TOKEN.mint function, there doesn't seem to be a check for overflow. If the amount variable becomes extremely large due to some error, it might lead to an integer overflow.

- Possible Front-Running: The approve function can potentially be front-run, allowing attackers to approve a transaction before a legitimate approver. Although the impact might be minimal due to the multi-signature-like system, it's still worth considering.

- Chain and Source Management: The addChainSupport function uses the keccak256 hash of the source contract address for approval. If there's any mistake in adding this hash, or if there are collisions (though very unlikely), it could hinder cross-chain operations.

- Reliance on External ALLOWLIST Contract: The contract assumes that the external ALLOWLIST contract works perfectly. Any vulnerabilities or issues in the ALLOWLIST contract can indirectly impact this contract, especially in the _mintIfThresholdMet function.

- No Function to Update External Contracts: If any of the external contracts (TOKEN, AXELAR_GATEWAY, ALLOWLIST) have vulnerabilities or need upgrades, there is no function in DestinationBridge to update the addresses of these contracts.

- Token Rescue Function: The rescueTokens function allows the owner to withdraw any ERC20 tokens from the contract. If used maliciously, this can result in loss of funds for users.

- Potential for Pausing Abuse: The owner has the capability to pause the contract, which can stop cross-chain operations. If the owner's address is compromised or acts maliciously, this can disrupt the system.

The SourceBridge smart contract primarily serves as a bridge for initiating cross-chain token transfers. This contract facilitates the process by burning tokens on the source chain and communicates with the AxelarGateway to instruct minting of the equivalent amount on the destination chain. Additionally, the contract provides administrative functions to manage chain bridging details and allows for arbitrary batched calls.

Key Findings: - Destination Chain Management: The smart contract allows for setting destination chain addresses, ensuring flexibility for bridging to multiple chains.

- Bridging through Burning Tokens: The primary function for cross-chain transfers is burnAndCallAxelar which burns tokens on the source chain and sends a call to AxelarGateway to mint the same amount on the destination chain.

- Gas Handling: The contract integrates with the IAxelarGasService to handle gas fees for transactions. It ensures that the appropriate gas fee is provided before a bridging operation.
- Versioning and Nonce: The contract uses a constant VERSION for payloads and a monotonically increasing nonce to differentiate transactions.

- Multicall Functionality: The contract allows for batched external calls via the multiexcall function, enabling batch operations and interactions.

Specific Vulnerabilities: - Unchecked Destination Chain Address: While the contract checks if a destination chain's address exists in the mapping, it does not verify the validity of the address. Incorrectly set addresses can lead to failures in token transfers.

- Potential for Front-Running: The burnAndCallAxelar function can potentially be front-run, causing unexpected behaviors or exploiting gas prices.

- Centralized Control: Many functions, including setting destination chain addresses and pausing the contract, are restricted to the owner. If the owner's address is compromised or acts maliciously, it could jeopardize the contract's operations.

- Uncontrolled Multicall: The multiexcall function can make arbitrary external calls. While restricted to the owner, it still presents a potential attack vector if the owner's address is compromised.

- Static Versioning: The constant VERSION might lead to issues if there's a need to update the contract or handle different versions in the future.

- Potential Gas Fee Abuse: The contract relies on incoming transactions to cover gas fees. However, if the fee is consistently set too low by users or if gas prices surge, it might hinder the contract's operations.

- Lack of Recovery Functions: There aren't any functions to recover mistakenly sent tokens or ETH to the contract.

The RWADynamicOracle smart contract functions as an oracle determining the price of an asset named USDY, based on dynamic interest rates set over defined time ranges. The contract employs OpenZeppelin's AccessControlEnumerable and Pausable to manage access controls and pausing functionality. The central structure of the contract is the Range, which possesses start and end timestamps, a daily interest rate, and the closing price of the previous range. Price derivation revolves around the elapsed days since the commencement of a range, compounded by the daily interest rate.

Key Findings - Heavy Dependence on Admin Role: The contract largely leans on its admin (or those with SETTER_ROLE) to set price ranges. This centralized approach makes it essential for the admin to remain active and vigilant, which can be a potential bottleneck or security concern.

- Well-structured and modular: The code exhibits segmentation into particular sections, such as public functions, admin functions, and internal functions, making it more navigable.

- Use of OpenZeppelin: OpenZeppelin's renowned libraries have been employed for access control and pausable functionality, bolstering the security.

- Role-based access control: Access is role-regulated, with distinctive roles like the DEFAULT_ADMIN_ROLE, SETTER_ROLE, and PAUSER_ROLE to determine who can execute certain functions.

- Pausing mechanism: A pausing feature has been embedded, allowing the contract to halt in emergency scenarios, thus obstructing further interactions.

- Fallback mechanism: The getPrice function has been crafted to return the last acknowledged price if the current timestamp surpasses the conclusion of the most recent range.

Specific Vulnerabilities - Overlapping Ranges: Within the setRange function, there's an examination ensuring the new range doesn't intersect with the end time of the preceding range. Nonetheless, if several ranges are preset and they overlap, this can spur errors in price derivation.

- Rounding: The roundUpTo8 function invariably rounds up if the remainder reaches or exceeds 0.5e10. This continuous upward rounding might cultivate a systematic bias.

- Dependence on external data: The contract's heavy reliance on the ranges provided for price determination can lead to miscalculations if inaccurate ranges are input. Verification of these ranges might be beneficial.

- Simulating Ranges: Utilizing the simulateRange function can furnish anticipated prices, but misuse can result in deceptive outcomes.

- Limited Comments: Certain functions, namely derivePrice, lack comprehensive comments, demanding more effort in auditing without an adequate context.

- Potential for outdated prices: In the absence of regular range updates, the contract might derive prices from obsolete interest rates.

The entire protocol is adeptly structured, showcasing a clear delineation of functions and modular organization. However, its functionality is substantially tethered to centralized roles, especially the admin. This reliance on a central authority could introduce potential bottlenecks or vulnerabilities. Furthermore, there is a noticeable lack of safeguards during initialization and contract creation processes; many constructor and initialization functions do not verify the validity of the input addresses, which could lead to inadvertent errors or potential security concerns.

Time spent:

50 hours