TOAD-ML: a trust-aware framework for validating oracle price feeds and detecting manipulation in decentralized finance

1 Introduction

Decentralized finance (DeFi) has emerged as a transformative paradigm in the blockchain ecosystem, enabling permissionless financial services such as lending, borrowing, derivatives trading, and asset management without reliance on centralized intermediaries. The three layers consist of smart contracts, public and permissionless blockchains, and some sort of off-chain computing resource for the Oracle services, which provides essential data that DeFi needs. A smart contract runs automatically once triggered, in a consistent and independent way, thanks to the transparency and deterministic execution features provided by public blockchain platforms, as described by smart contract specifications for platforms such as Ethereum (Merlo et al., 2023), Polkadot (Wang and Guan, 2023), and Binance Smart Chain (Mackinga et al., 2022).

As stated previously, all Oracle systems use on-chain data feeds from sources external to the blockchain to provide more realistic and accurate data, Chainlink and other decentralized feeds among them. With protocol performance directly tied to the on-chain data feeds, the availability of an attack vector targeting the data is apparent. Many such attacks in real-life exist: from market participants with privileged information, who could manipulate prices to create an outcome favorable to them, to those utilizing methods such as the infamous “flash loan attack” in order to destabilize market prices, creating a market tail risk.

One major threat with regard to DeFi protocols is a flash loan attack (Wang et al., 2021; Tsankov et al., 2018), where the attacker borrows a large amount of money (with almost no collateral) to use in a transaction, and if all goes well, the attacker repays it all within the same transaction. One method used in such attacks is creating a transaction that uses an AMM-based exchange to manipulate the price of a certain token on the platform. Once this change is propagated to Oracle, the information gained can be used in subsequent DeFi protocols as the asset’s real price. This, in turn, leads to draining funds from the protocol (the attacker buys up all the assets on the platform for much less than they are truly worth), acquiring uncollateralized loans or having unbalanced liquidations.

To prevent such manipulation, several ideas were proposed, focusing on the Oracle design and post-manipulation detection methods. Many such proposals include time-weighted average prices (TWAP) that average multiple measurements over certain time intervals, which may negate some forms of manipulation. These methods are generally unable to withstand the longer-term manipulation attacks targeting multiple timeframes; even if the short-term TWAP is insensitive to manipulated actions, the value at the end of the timeframe that represents longer-term price changes may be affected. Other suggested detection methods utilize anomaly detections where the price is measured by single data sources and then verified with statistical thresholds or machine learning techniques, which generally validate specific events but can only detect a system-wide manipulation if multiple price sources are integrated together, which is not typically available in Oracles’ architectures.

The final major weakness in the discussed solutions is that they are all reactive. Most of these frameworks will find anomalies after they occur and they affect the system, rather than giving an indication of anomalous risks that may have caused the attack to occur. While this is true for some applications, this drawback is amplified when applied to decentralized finance, which is often dealing with very high-speed transaction rates that make immediate responses challenging. Even with that, none of the existing frameworks present a continuous quantitative measure for the trustworthiness of Oracle data. Instead, most methods will simply lead to a qualitative output for what is deemed trust, such as degree or true/false.

Furthermore, there is a significant research gap in the field of passive/real-time monitoring of Oracle data reliability. While there exist many methods to detect anomalies in one specific data feed, a framework that can combine evidence from multiple data sources to determine an oracle ‘s data reliability is currently absent. As explained, a fully fleshed out Oracle monitoring service that uses fusion and forecasting methods to monitor data reliability is the optimal solution for all the stated issues, thus requiring exploration beyond selective anomaly detection.

Based on the current shortcomings of current DeFi Oracle implementations, the focus is to devise a method to be used as a security and validation layer for DeFi applications. This work proposes TOAD-ML (trust-aware oracle data validation for machine learning), a trust-aware Oracle data validation framework. Its main idea is to use multiple external and internal Oracle data sources to ensure that the price feeds that are supplied to DeFi protocols remain authentic and tamper-free. We use a data processing pipeline to establish an’ Oracle behavior of data; we then use this data to train and evaluate a classification machine model, which ultimately gives us a classification decision of whether data are valid or malicious, along with an indicator of the amount of trust the data have.

Alternatively, TOAD-ML could act proactively to provide protocol participants awareness that they were interacting with data that had been subject to corruption, prior to that protocol becoming completely unavailable to the public as a result of the manipulation. Trust-aware scoring would be invaluable in enabling protocols to make intelligent decisions about who can take further actions. For example, if transactions to protocol are consistently falling into a realm indicating that the data were corrupted, we might flag the transaction and then alert the community of a potential exploit or even attempt to automatically revert a malicious transaction.

However, the TOAD-ML dataset does not fit the requirements of the HBS-ML’s training phase, since it is composed of real-world and simulated attack prices against Oracle (e.g., other sources are also feed into the TOAD-ML evaluation to make attacks efficient and stealthy: DEX aggregate prices, Oracle round, etc.). Hence the real-world data fed into HBS-ML are the labeled Oracle attacks generated by TOAD-ML, together with the rounds of Oracle price calculation, Oracle rounds, which represent the prices that would have been reflected by Oracle.

The main contributions of this work are as follows:

• A multi-sources validation is used via different exchanges and Oracle systems to protect information accuracy, including on-chain and off-chain DeFi and other markets.
• A machine learning method that is aware of trust and that produces both anomaly labels and continuous measures of trustworthiness for Oracle updates.
• A DeFi manipulation early warning tool that flags potential manipulation in advance of actual harmful activity, as demonstrated in the case study in Section 6.1.
• A cross-dataset evaluation strategy utilizing heterogeneous data sources and realistic attack sets to promote accuracy and robustness.

2 Literature review

The rapid growth of DeFi has been accompanied by increasing security challenges, particularly those associated with oracle manipulation and unreliable external data feeds. This section provides background information of existing works in four main areas. First, we delve into Oracle Systems, their vulnerabilities, and the related attack scenarios in detail. Second, we analyze Oracle manipulation attack in current literature (Zhao et al., 2022; Homoliak et al., 2020; Kitzler et al., 2023). Third, we discuss ML models applied in detecting anomalies for security, and SoliAudit, which combines machine learning with fuzz testing for smart contract vulnerability assessment (Liao et al., 2019).

The need for reliable data feeds from real-world sources has motivated a wave of new mechanisms designed for the decentralized context, collectively termed ORACLES. Early on, frameworks such as Augur used the concept of decentralized prediction markets for achieving consensus, and they proved to be instrumental in motivating the need for a more scalable infrastructure solution, although subject to manipulation by malicious parties.

Researchers like Aspembitova and Bentley also thoroughly covered Oracle Systems, using attack costs, profitable strategies, and mitigation strategies to inform their analysis. This article shows that under a given range of market and network conditions, such oracles are capable of being attacked with profitable success. The authors discuss several technical methods to secure and protect oracles but do not cover any attempts at automated trust management.

One major source of vulnerability that has emerged in DeFi is oracle manipulation attacks, in which attackers manipulate an oracle by altering its inputs, thereby impacting system prices. Using a unique methodology for tracking events of this kind, Zhou et al. (2022) demonstrated that price manipulation-related attacks make up an overwhelming portion of DeFi incidents studied within their work, with flash loans often used in tandem.

Mackinga et al. (2022) demonstrated a powerful TWAP oracle attack that can fool even common mitigation strategies and exploit the fact that attackers can control enough sustained, multi-block price distortions. This attack is demonstrated against Chainlink’s TWAP system itself, which uses TWAP for the system’s on-chain aggregation.

In addition, an article about cyclic arbitrage opportunities by Wang et al. (2021) reported that such activities, along with the price discrepancy of crypto assets between two markets, also lead to a change of the oracle value in the market.

More recently, the approach has shifted toward behavioral analysis of transactions at the block and network level rather than at individual oracles. For example, POMABuster (Xi et al., 2024) implements a pattern-based machine learning framework on transactions to identify Oracle price manipulations; however, POMABuster does not actually assess the reliability of any specific value, it merely predicts when data are “malicious.” Mo et al. (2023) developed an automated system that could detect when a smart contract was receiving unexpected price feeds.

Deng et al. (2024) have taken up the topic of oracle deviations. They suggest adding some smart contracts in the decentralized system to defend against malicious price updates. However, the proposed solutions are predominantly rule-based and do not utilize machine learning techniques.

To tackle the increasing complexity of smart contracts and the potential for more sophisticated attack patterns, various researchers have started incorporating various types of machine learning algorithms into security architectures or analyses of smart contracts. For example, Aspembitova and Bentley (2023) applied various types of machine learning models to detect various types of smart-contract vulnerabilities, while Xu et al. (2021) proposed a novel machine learning-based analysis model for smart contract vulnerability detection. Peterson et al. (2022) proposed a CBGRU-based method that improves on previous vulnerability detection methods in terms of efficiency and effectiveness, including fuzzing-based approaches such as ContractFuzzer (Jiang et al., 2018).

Zhang et al., in contrast, were more concerned with code—and its various layers of semantics—and developed ensemble and hybrid models for discovering smart-contract vulnerabilities that leverage a combination of code similarity and machine learning methods (Zhang et al., 2022a; Zhang et al., 2022b). Chen et al. (2022) proposed CBGRU, a detection method for smart contract vulnerabilities based on a hybrid deep learning model. A limitation of their approach, as with the others reviewed here, is their lack of ability to catch runtime issues.

A comprehensive overview in ML for DeFi is offered by Venkatraman and Kuppusamy (2026). They are covering many methods such as anomaly detection, anomaly forecasting, classification, and ensemble-based approaches for a secure DeFi system. However, there is no specialized framework discussed by them especially for Oracle.

These tools have provided valuable advances in auditing and testing of smart contracts and have identified various vulnerabilities in major smart contracts, including colour-inspired inspection methods for identifying potential attacks (Huang, 2018). However, these tools have not been applied to external data dependency risks where vulnerabilities are created not in the contract code itself but from the values on the network that the contract depends upon.

In addition, broad-scope research on blockchain security with security threat modeling has been proposed in Zhao et al. (2022). It introduces a security reference architecture that supports different layers of applications and provides a guideline for the evaluation of trust and reliability in decentralized applications.

Using an established method of analyzing the effectiveness of existing toolset for Ethereum smart contracts, Kushwaha et al. (2022) found issues with the static analysis of these contracts; this finding could potentially extend to contracts that dynamically use data sources to make contract decisions. Additionally, to address distributed control, consensus mechanisms were used to make agreements on the state of the blockchain (Aggarwal and Kumar, 2021).

In addition to the above areas, blockchain has been applied in different areas to enable trustworthy data processing. For example, Merlo et al. (2023) and Lo et al. (2019) proposed ways to use blockchains for healthcare applications and the Internet of Things (IoT) to keep health data secure and share device data. Wang and Guan (2023) proposed a scheme for secure data sharing to address data trustworthiness. Wang et al. (2023) further proposed a smart contract token-based access control system for industrial IoT environments.

2.1 Research gap and motivation

Several key limitations can be identified from the above discussion:

• Single-source dependency: many approaches rely on isolated data sources, limiting their ability to detect cross-market inconsistencies.
• Reactive detection: existing methods often identify attacks after they occur, reducing their effectiveness in preventing financial loss.
• Lack of trust quantification: most frameworks provide binary outputs without offering a continuous measure of oracle reliability.
• Limited integration of ML with oracle validation: although lots of machine learning algorithms have been presented on vulnerability discovery, oracle trust evaluation is not studied well.

These gaps demonstrate the need for an integrated platform combining data validation across multiple sources, real-time detection of anomalies, and interpretability through trust scores. We developed TOAD-ML, a new model to address the gaps through an ensemble of ML algorithms which predict, detect, and explain data trust in a trusted framework.

3 System model and problem definition

In this section, we formalize the oracle validation problem that we discuss throughout the entire manuscript. We describe the system components and the different inputs and outputs that this framework takes. Then, we mathematically represent the system’s objective function.

3.1 Oracle system model

In a DeFi ecosystem, an oracle system acts as an intermediary that supplies external data—primarily asset prices—to on-chain smart contracts. Let us denote the oracle system as:where:

O = P o t ,

• P _o(t) represents the price reported by the oracle at time t.

To evaluate the reliability of oracle data, the system incorporates multiple independent price sources:

• P _*m*(t): market price from centralized aggregators (e.g., CoinGecko);
• P _*d*(t): decentralized exchange price (e.g., Uniswap TWAP);
• P _*l*(t): multi-token reference prices (e.g., DeFiLlama). Thus, the multi-source price set at time t is defined as:

P t = P o t , P m t , P d t , P l t ,

Note that P(t) is defined here as an unweighted observation tuple: the four synchronized price readings collected at time t, with no combination or fusion applied at this stage. Fusion of these sources occurs downstream first analytically, through the deviation terms Δm, Δd, and Δl and the weighted aggregate Δagg (Section 3.3), and subsequently as part of the learned representation, through the engineered feature vector x(t) used by the classifier (Section 4.4).

All of these sources give, over time, a redundant variety of views on the asset’s true market value.

3.2 Formal problem statement

The formulation below fixes the notation for a standard supervised classification setup and is not itself claimed as a contribution of this work; the methodological contribution lies in the joint estimation of a continuous trust score alongside the binary label, and in the trust-calibration layer described in Section 4.5 (Stage 2), which fuses the analytically derived trust score τ(t) with the model prediction y(t).

Given a sequence of multi-source price observations over time:the objective is to learn a function:where:

D = t 1 , P t 2 , … , P t n ,

f : D → τ t , y t ,

• τ(t)∈[0,1]: trust score, representing the reliability of the oracle price at time t.
• y(t)∈{0,1}: anomaly label, where,
• ○ 0: normal;
• ○ 1: manipulated/suspicious.

Both outputs should be estimated so that the arbitrator can alter oracle before any downstream financial impact from the manipulation.

3.3 Mathematical formulation price deviation modeling

A fundamental indicator of manipulation is the deviation between the oracle price and other reference sources. The deviation between Oracle and each source is computed as:

∆ m t = P 0 t − P m t ∣ P m t ,

∆ d t = P 0 t − P d t ∣ P d t ,

∆ l t = P 0 t − P l t ∣ P l t .

These relative-deviation measures follow the standard cross-source consistency formulation used in oracle-manipulation analysis, consistent with the TWAP-deviation attack modeling in Mackinga et al. (2022) and the deviation-based mitigation strategies discussed in Aspembitova and Bentley (2023).

The aggregate deviation score is then defined as:where:

Δ a g g t = w 1 Δ m t + w 2 Δ d t + w 3 Δ l t ,

• w ₁, w ₂, and w ₃ are weighting coefficients such that w ₁ + w ₂ + w ₃ = 1.

This formulation captures cross-source disagreement, which is a strong signal of potential manipulation.

3.3.1 Temporal consistency

To account for abrupt price movements, temporal deviation is defined as:where Po(t) denotes the oracle price at time t, and Po(t−1) denotes the oracle price at the previous time step.

∆ t t = P o t − P o t − 1 / P o t − 1

This first-difference formulation follows standard practice in financial time-series anomaly detection and is consistent with the sudden spike/drop signatures documented in flash-loan attack case studies (Zhou et al., 2022; Wang et al., 2021).

Large values of Δt(t) indicate sudden spikes or drops, often associated with attack patterns.

3.4 Trust function formulation

The trust score is designed to quantify the reliability of oracle data by combining deviation and temporal consistency:where:

τ t = exp − α · Δ a g g t − β · Δ t t ,

• α and β are scaling parameters controlling sensitivity properties;
• τ(t)→1: high trust (consistent with all sources);
• τ(t)→0: low trust (high deviation or instability).

This exponential formulation ensures smooth degradation of trust as inconsistencies increase.

This functional form is a design choice rather than an analytically derived result: it is motivated by two structural requirements—that τ(t) remains bounded in (0,1), and that it degrades smoothly rather than discontinuously as deviation and volatility increase—and its contribution is validated empirically rather than theoretically, via the ablation results in Section 6.1 (Table 1), where removing the trust-scoring layer reduces accuracy by 3.84% and area under the receiver operating characteristic curve (AUC-ROC) by 0.05.

TABLE 1. Ablation study results.

3.5 Risk classification model

The anomaly detection task is formulated as a supervised or semi-supervised classification problem. Given feature vector:

x t = Δ m t , Δ d t , Δ l t , Δ t t , … ,

The classifier predicts:where:

y t = 0 , i f τ t ≥ θ 1 , i f τ t < θ ,

• θ is a predefined threshold.

Alternatively, a machine learning model fML can directly learn:

y t = f M L x t .

3.6 Optimization objective

The learning objective is to minimize classification error while maintaining reliable trust estimation:where:

L = λ 1 · L c l s + λ 2 · L t r u s t ,

• L _*cls*: classification loss (e.g., cross-entropy);
• L _*trust*: regression loss for trust score;
• λ ₁ and λ ₂: balancing parameters.

This multi-objective formulation follows standard multi-task learning principles by jointly optimizing the classification accuracy and trust score estimation.

In other words, we formalize this problem as a multi-source consistency check problem by modeling how each oracle maintains its price, and we estimate the trustworthiness of each oracle price feed by the amount of discrepancy with parallel feeds and the variation within a price feed to detect anomalies. With these estimations, we are able to estimate the possibility of manipulation and anomaly of certain oracle updates and perform anomaly detection of an oracle price. TOAD-ML combines the trust estimation and anomaly detection into one framework for an early detection of possible malicious updates.

4 Proposed framework: TOAD-ML

In this section, we present the detailed design of the TOAD-ML framework. TOAD-ML is designed as an end-to-end framework, starting from the comprehensive identification of diverse DeFi-related data entities, to building a staged validation process, then applying machine learning techniques to identify potential oracle manipulation events, and ultimately quantifying the real-time trust in oracle feed integrity. Our framework is inspired by the limitations in current approaches.

4.1 Overall architecture

The TOAD-ML system is a modular pipeline, in which each stage adds some reliability and ease of interpretation for oracle validation. The proposed approach has five main stages of data flow, namely, ingestion, preprocessing, feature extraction, ML detection, and trust scoring:

4.1.1 Step 1: data ingestion

Data gathering: Price data and attack labels need to be collected from several independent and heterogeneous sources, such as on-chain oracle feeds, decentralized exchange feeds, centralized market references, and attack-labeled datasets. This heterogeneity makes it harder for one manipulated feed to dominate the final decision.

4.1.2 Step 2: data preprocessing

Raw data obtained from varying sources can differ in structure, time resolution, and record presence. Preprocessing for such data involves munging it so that it is consistent and accurate; e.g., filling missing data, aligning times, and equalizing price scales.

4.1.3 Step 3: feature engineering

As the feeding is currently in the raw price values for any machine learning model, we need to convert the raw data into a representation that carries more information. This phase focuses on creating feature representations for any feeding.

4.1.4 Step 4: machine learning model

The features which we engineer from data are provided to a supervised or a hybrid-learning framework that identifies the patterns that causes oracle manipulation. By training the framework on both attacked and normal market behavior data, the algorithm implicitly learns the features of an attack.

4.1.5 Step 5: trust scoring and risk classification

The final stage generates two outputs:

• A binary anomaly label (normal or manipulated).
• A continuous trust score that indicates the trustworthiness of the oracle data.

4.2 Data sources and integration

TOAD-ML is as good as the sum of the parts of all the data fed into it. It is more about the strength of the collective rather than the individual importance of each of the sources that contribute data to TOAD-ML.

D1: DeFiHackLabs (attack labels)

• Source: https://github.com/SunWeb3Sec/DeFiHackLabs
• Type: labeled attack dataset.
• Purpose: provides real-world DeFi exploit scenarios, including oracle manipulation cases.
• Key parameters:
• ○ Transaction hash;
• ○ Attack type (oracle manipulation, flash loan, etc.);
• ○ Block number;
• ○ Timestamp;
• ○ Exploited protocol.

This dataset is used to generate ground truth labels for supervised training and evaluation.

D2: CoinGecko historical price data

• Source: https://www.coingecko.com/en/coins/ethereum/historical_data
• Type: Centralized market price data.
• Purpose: Acts as a baseline reference for asset valuation.
• Key parameters:
• ○ Timestamp;
• ○ Open, high, low, close (OHLC) prices;
• ○ Trading volume;
• ○ Market capitalization.

CoinGecko data provide a relatively stable benchmark for detecting deviations in oracle prices.

D3: Chainlink Oracle data (on-chain rounds)

• Source 1: https://data.chain.link/feeds/ethereum/mainnet/eth-usd
• Source 2: https://docs.chain.link/data-feeds/historical-data
• API Access: https://app.infura.io/register
• Type: On-chain oracle feed data.
• Purpose: Primary input under evaluation.
• Key parameters:
• ○ Round ID;
• ○ Answer (price value);
• ○ StartedAt timestamp;
• ○ UpdatedAt timestamp;
• ○ AnsweredInRound data are retrieved using the function:

getRoundData(roundId).

This dataset represents the oracle values that must be validated for reliability.

D4: Uniswap V3 TWAP (time-weighted average price)

• Source 1 (GraphQL): https://thegraph.com/explorer/subgraphs/5zvR82QoaXYFyDEKLZ9t6v9adgnptxYpKpSb xtgVENFV
• Source 2 (verification): https://info.uniswap.org/#/pools/0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640.

• Type: Decentralized exchange pricing.
• Purpose: Provides manipulation-resistant price estimates.
• Key parameters:
• ○ Timestamp;
• ○ sqrtPrice;
• ○ Token0Price, Token1Price;
• ○ Volume;
• ○ Liquidity;
• ○ poolHourData.

TWAP reduces short-term volatility but is still vulnerable to sustained manipulation, making it an important comparison baseline.

D5: DeFiLlama Multi-Token Price Data

• API endpoint: https://docs.llama.fi/coin-prices-api
• Documentation: https://defillama.com/docs/api
• Type: Multi-token aggregated price data.
• Purpose: Cross-validation across multiple assets.
• Key parameters:
• ○ Timestamp;
• ○ Price;
• ○ Token identifier;
• ○ Confidence intervals (if available).

Supports validation across ETH, BTC, LINK, UNI, AAVE, and other tokens.

To conclude the validation process, an integration space was formed that provided multiple datasets confirming one specific aspect: whether the oracle price had successfully followed the spot price.

4.2.1 Timestamp synchronization

Since different sources operate at varying frequencies (seconds, minutes, and hours), alignment is necessary. Let:

• t _*o*, t _*m*, t _*d*, and t _*l* denote timestamps from different sources.

A unified timeline t is constructed using nearest-neighbor alignment:

P t = P x argmin t i − t t i .

Data are resampled to a fixed interval (e.g., hourly), and interpolation is applied where necessary.

4.3 Data preprocessing

To ensure consistency and quality, the following preprocessing steps are applied:

4.3.1 Missing value handling

Missing values are handled using:

• Forward filling:

P t = P t − 1 .

• Linear interpolation for longer gaps.

4.3.2 Time alignment

All datasets are:

• Resampled to a uniform interval.
• Synchronized to a global timeline.

44.3.3 Normalization

To eliminate scale differences:

P ′ t = P t − P min P max − P min .

4.3.4 Outlier filtering

Z-score normalization is used:

Z t = P t − μ σ .

If ∣ Z ∣ > 3, the observation is flagged for further inspection. Only observations identified as erroneous or corrupted (e.g., invalid records, duplicated entries, or data acquisition errors) are corrected or removed. Extreme price deviations associated with genuine oracle manipulation events are retained because they represent meaningful attack characteristics rather than statistical noise. The attack detection timeline, including oracle price, TWAP price, market price, deviation percentage, predicted label, and calibrated trust score at each time point from t₁ to t₅, is summarised in Table 2.

TABLE 2. Attack detection timeline.

Outlier handling was performed only to identify erroneous or corrupted observations generated during data acquisition, such as missing values, duplicated records, or invalid measurements. Z-score analysis was, therefore, used solely as a data quality assessment mechanism rather than as an attack filtering technique. Extreme price deviations associated with documented oracle manipulation events, including labeled attack intervals from the DeFiHackLabs (D1) dataset, were intentionally retained throughout model training and evaluation because they represent meaningful attack characteristics rather than statistical noise. This preprocessing strategy preserves genuine manipulation patterns while minimizing the influence of erroneous data artifacts.

4.4 Feature engineering

The main differences of TOAD-ML from traditional oracle-monitoring systems are that feature engineering is performed to target the multi-source disagreement, time breaking, and adversarial attack pattern of the input oracle system.

4.4.1 Unified deviation score

Instead of treating deviations independently, TOAD-ML defines:

Δagg(t) = w1Δm(t) + w2Δd(t) + w3Δl(t), as defined in Section 3.3 (equal weighting w1 = w2 = w3 = 1/3 is used as the default configuration).

This acts as a global inconsistency indicator across:

• Market (CoinGecko).
• DEX (Uniswap TWAP).
• Aggregator (DeFiLlama).

4.4.2 Temporal instability index

where:

TI t = α · Δ t t + 1 − α · σ t ,

• Δ _*t*(t): Short-term drift.
• σ _*t*: Volatility.

4.4.3 Capturing sudden + persistent manipulation patterns

Here, C(t) denotes the cross-source consistency component defined in Section 4.6 (equivalent to A(t) in the trust score decomposition) and F(t) denotes the update frequency, i.e., the time elapsed since the previous oracle round (t − t_prev).

4.4.4 Oracle reliability signal

R t = 1 F t · e − β Δ a g g t .

4.4.5 Interpretation

• Frequent updates → higher trust.
• High deviation → penalized.

4.4.5.1 Final feature vector (TOAD-ML)

x t = Δ m , Δ d , Δ l , Δ a g g , T I , C t , R t .

4.5 TOAD-ML learning model

In the next phase, a trained classifier with missing feature values would estimate the probability of a transaction, but the output may need to be used alongside several rules to assess confidence. The hybrid TOAD-ML model has the ability to overcome the inherent lack of interpretable, quantitative trust estimation seen in every modern DeFi oracle security system. Theoretically, it has the ability to extend classical statistical learning theory to more robust confidence modeling. Algorithm 1 summarizes the proposed TOAD-ML pipeline, including multi-source data collection and alignment, preprocessing, deviation and temporal feature extraction, XGBoost-based manipulation detection, trust-score computation, and final trust calibration.

Algorithm 1 TOAD-ML Framework. Pseudocode describing the proposed Trust-Aware Oracle Data Validation for Machine Learning (TOAD-ML) pipeline. The algorithm details the sequential processing stages from multi-source data ingestion and preprocessing, through cross-source deviation feature engineering and temporal feature extraction, to XGBoost-based anomaly classification, analytical trust score computation, and final trust calibration layer output producing both a binary manipulation label y(t) and a calibrated trust score τ′(t).

4.5.1 Stage 1: detection model (supervised learning layer)

The first stage utilizes a supervised learning function:where x(t) represents the engineered feature vector and f _*θ* denotes the XGBoost classifier, a gradient-boosted decision tree ensemble. From a theoretical standpoint, XGBoost approximates a function in a functional space of additive trees, optimizing:where each f _*k* is a regression tree. This formulation allows TOAD-ML to capture non-linear dependencies, feature interactions, and heterogeneous distributions that are inherent in multi-source price feeds.

y t = f θ x t ,

y ^ t = ∑ k = 1 k f k x t , f k ∈ F ,

The choice of XGBoost is justified by its ability to minimize a regularized objective function:where l(⋅) is the classification loss (log-loss) and Ω ⁽ fk ⁾ penalizes model complexity. This ensures generalization robustness, which is critical in adversarial DeFi environments where manipulation patterns evolve dynamically.

L c l s = ∑ l y , y ^ + ∑ Ω f k ,

4.5.1.1 Stage 2: trust calibration layer (confidence modeling)

While stage 1 provides a binary prediction y(t), it does not inherently quantify confidence or reliability. TOAD-ML addresses this through a trust calibration layer:where:

τ ′ t = σ w 1 τ t + w 2 y t ,

• τ(t) is the analytically derived trust score,
• y(t) is the model prediction,
• σ(⋅) is the sigmoid function ensuring bounded output in (0,1).

Theoretically, this layer can be interpreted as a Bayesian-inspired posterior adjustment, where:

• τ(t) acts as a prior belief derived from domain knowledge (e.g., price consistency and volatility),
• y(t) acts as a likelihood estimate from data-driven learning.

Thus, τ′(t) approximates a posterior trust probability, effectively fusing symbolic reasoning (rules) with statistical inference (ML). This hybridization is a key novelty of TOAD-ML, improving both interpretability and decision reliability.

4.5.2 Joint optimization objective

To ensure coherence between prediction and trust estimation, TOAD-ML introduces a multi-objective loss function:where:

L = L c l s + λ · L t r u s t ,

• L _*cls* = ^∑ ylog(ŷ) is the standard cross-entropy loss,
• L _*trust* = ⁽ τ ⁽ t ⁾ − ŷ⁾² enforces consistency between trust score and predicted probability,
• λ is a regularization parameter controlling the trade-off.

From a theoretical perspective, this formulation resembles multi-task learning, where the model jointly optimizes:

• Classification accuracy;
• Trust alignment.

It can be viewed as a regularizer on a model’s trust level. The regularizer’s effect on the hypothesis space limits the model’s attention to those hypotheses whose predictions are reliable in accordance with the observed reliability indicator.

The TOAD-ML learning model can be viewed as a confidence-aware risk minimization framework, where:

• Stage 1 minimizes the empirical risk;
• The second stage adjusts the predictions by means of domain-knowledge-based priors;
• Joint loss is about consistency and calibration.

This design is particular as the final output is not strictly a classification result anymore but rather a trust-aware inference. Therefore, it makes the system suitable for high-stake DeFi applications where a wrong decision could cost financially.

4.5.3 Consistency score

The consistency score quantifies the agreement between the reported oracle price and the aggregated multi-source reference price. A higher consistency score indicates that the oracle price closely follows the consensus value obtained from trusted external sources. It is computed as:where Δ agg t denotes the normalized aggregate price deviation defined in Equation 8. The value of C t ranges from 0 to 1, with values closer to 1 indicating higher agreement between the oracle price and the reference price.

C t = 1 − Δ a g g t ,

4.5.4 Update frequency

Oracle update frequency reflects how regularly Oracle updates its reported price. It is computed as the inverse of the elapsed time between two consecutive Oracle updates:where t i and t i − 1denote two consecutive Oracle update timestamps. Higher values of F t indicate more frequent Oracle updates and contribute positively to the overall trust assessment.

F t = 1 t i − t i − 1 ,

4.6 Trust score formulation

We can define trust scores as follows. Oracle A will have a higher trust score if it is in agreement with most of the sources, under the same conditions, for long periods of time and if Oracle A itself tends to be in agreement with its older value, as we would expect if the system were running smoothly.

The overall trust score is expressed as:where A(t), S(t), and U(t) correspond to agreement, stability, and update reliability components, respectively.

t = w a A t + w s S t + w f U t , w h e r e w a + w s + w f = 1 ,

4.6.1 Cross-source agreement

Agreement is the price provided by Oracle consistent with the one obtained from different sources (e.g., TWAP price, price according to the top N exchanges, etc.). It is defined as:

Δagg(t) as defined in Section 3.3 (weighted combination of Δm, Δd, and Δl); k here denotes the three reference sources used; i.e., k = 3.

The greater the aggregate deviation, the lower the scoring, and, in essence, it was seen as evidence of fiddling or a source that did not “belong.”

4.6.2 Temporal stability

We calculate these variables on the second day of each month and record the value in our spreadsheet. Temporal stability can be described as the degree to which each of the price fluctuations are in their correct order:

S t = e − γ σ t σ t = 1 n ∑ i = 1 n P t − i − μ 2 ,

where σ _*t* represents rolling volatility and γ controls sensitivity. Stable price behavior leads to values close to 1, while high volatility leads to exponential decay, reflecting reduced reliability.

4.6.3 Update consistency

The frequency of the oracle updates can tell if it is fraudulent because it is updating without enough data or the oracle is not working as it should. This aspect is modeled as:where t _*prev* denotes the previous update timestamp. Frequent updates yield higher values, while longer gaps reduce the trust score.

U t = e − β t − t p r e v ,

4.6.3.1 Integrated trust expression

Combining all components:

t = wa 1 − Δ a g g t + w s e − γ σ t + w f e − β ∣ t − t p r e v ∣ .

This formulation ensures that the trust score remains bounded within (0,1) and degrades smoothly under anomalous conditions.

4.6.4 “Empirical interpretation”

A high trust score, where (t)->1, occurs whenever the oracle has very little deviation from the references, few fluctuations, and a regular update rate. It shows good agreement with the market behavior and present and stable data reporting.

Conversely, when (t)->0, a low trust score, it is a reflection of a large deviation between Oracle and the reference prices, a rapid volatility spike, or slow fluctuating update times. These signs typify manipulation, delayed reporting, or Oracle failure.

As with the trust function in Section 3.4, this interpretation is supported by the empirical behavior reported in Table 3 and the ablation results in Table 1 rather than by a formal derivation.

TABLE 3. Trust score behavior analysis.

4.6.5 Role within TOAD-ML

Within the TOAD-ML framework, the trust score functions as both an independent reliability indicator and a calibration signal for the learning model:

τ ′ t = σ w 1 τ t + w 2 y t .

By comparing predictions with signal values, TOAD-ML successfully combines deep learning algorithms with fundamental signals to obtain predictive models with higher accuracy and reliability. This integration ensures that TOAD-ML makes predictions only when certain patterns are detected and the corresponding signals indicate a reliable relationship.

5 Experimental setup

In this section, we lay out the experimental setup to analyze the effectiveness of TOAD-ML. We provide details on the data sources utilized, how we integrate them, the configuration of the training and testing protocols, and the metrics used in assessing TOAD-ML performance.

5.1 Dataset construction

To avoid potential label leakage, ground-truth labels were obtained exclusively from documented Oracle manipulation incidents reported in publicly available datasets and verified attack reports. The proposed trust score and all engineered predictive features were computed only after the labels had been assigned and were used solely as input variables during model training. Consequently, the labeling process remained independent of feature construction, reducing the possibility of artificially inflated predictive performance due to circular labeling.

5.2 Multi-source data integration (D1–D5)

The dataset is constructed by aggregating heterogeneous data streams from five distinct sources:

5.2.1 D1: DeFiHackLabs

Provides labeled attack data, including Oracle manipulation incidents and exploit timelines.

5.2.2 D2: CoinGecko

Supplies real-time market price data for various tokens.

5.2.3 D3: Chainlink

Offers Oracle price feeds and round-based updates.

5.2.4 D4: Uniswap V3 TWAP

Provides time-weighted average prices from decentralized exchanges.

5.2.5 D5: DeFiLlama

Supplies aggregated multi-token price validation across protocols.

Each dataset contains time-stamped entries, which are synchronized using a unified temporal index. Let:

D i = t , P i t , i ∈ 1 , 2 , 3 , 4 , 5 .

A unified dataset is constructed as:

D = ⋃ P o t , P m t , P d t , P l t , y t t ,

where:

5.2.6 Po(t)

Oracle price (Chainlink).

5.2.7 Pm(t)

Market price (CoinGecko).

5.2.8 Pd(t)

DEX TWAP (Uniswap).

5.2.9 Pl(t)

Aggregated price (DeFiLlama).

5.2.10 y(t)

Label.

5.3 Timestamp alignment

Since data sources operate at different frequencies, time alignment is performed using nearest-neighbor interpolation:

P t = P i argmin t i − t t i .

This ensures consistency across all sources at each time-step.

5.4 Labeling strategy

The labeling process is derived from known attack intervals in D1:

y t = 1 , i f t ∈ T a t t a c k 0 , o t h e r w i s e .

Additionally, heuristic labeling is applied for unlabeled regions using deviation thresholds:where δ is a predefined anomaly threshold.

y t = 1 i f Δ a g g t > δ ,

This hybrid labeling approach ensures:

• Ground-truth accuracy from known exploits.
• Generalization to unseen anomalies.

5.5 Training configuration train–test split

The dataset is partitioned into training and testing sets using a ratio of 80:20:

D t r a i n = 0.8 · D , D t e s t = 0.2 · D .

To preserve temporal dependencies, a time-aware split is used, ensuring that training data precede testing data chronologically.

5.5.1 Cross-validation

A k-fold cross-validation (k = 5) strategy is applied on the training set to improve robustness:

L c v = 1 k ∑ i = 1 k L i .

5.5.2 Hyperparameter configuration

The XGBoost model is tuned using grid search with the following parameters:

• Learning rate (η): 0.01–0.1.
• Maximum tree depth: 4–10.
• Number of estimators: 100–500.
• Subsample ratio: 0.7–1.0.
• Regularization parameters (λ and α).
• The optimal configuration is selected based on the validation performance.

Trust-score weight selection: The weighting coefficients used in the deviation aggregate (w1, w2, and w3 in Δagg, Section 3.3) and in the composite trust score (wa, ws, and wf in τ(t), Section 4.6) were selected via grid search on the validation split, using the same time-aware cross-validation procedure described above for the XGBoost hyperparameters. Candidate weights were constrained to sum to 1 and were evaluated by validation-set AUC-ROC; the configuration reported in Table 4 corresponds to the best-performing combination found.

TABLE 4. Model performance comparison.

Bold values indicate the best-performing result among the compared methods.

5.5.3 Training objective

The model minimizes the joint loss:ensuring both classification accuracy and trust alignment.

c L = L ls t + λ · L rust ,

5.6 Evaluation metrics

The performance of the proposed TOAD-ML framework was evaluated using both classification-oriented and trust-oriented performance metrics to comprehensively assess its ability to detect Oracle manipulation and estimate Oracle reliability. Classification performance was measured using accuracy, precision, recall, F1-score, AUC-ROC, and Matthews correlation coefficient (MCC). Since Oracle manipulation datasets are inherently imbalanced, F1-score, AUC-ROC, and MCC were included to provide a more reliable assessment than accuracy alone.

The AUC-ROC evaluates the model’s ability to distinguish manipulated Oracle events from legitimate Oracle updates across different classification thresholds. A higher AUC value indicates better discrimination capability. It is computed as:where TP denotes the true positive rate and FPR represents the false positive rate.

A U C = ∫ 0 1 T P F P R − 1 x d x ,

Detection latency is an important deployment-oriented metric for real-time blockchain security systems, representing the elapsed time between the occurrence of an Oracle manipulation event and its detection by the proposed framework. Although detection latency is recognized as an important practical evaluation metric, it was not independently benchmarked in the current study because the primary objective was to evaluate the predictive capability and trust assessment performance of the proposed TOAD-ML framework. Therefore, the experimental evaluation presented in this work focuses on predictive performance metrics, while comprehensive latency benchmarking under different deployment environments is identified as an important direction for future research.

To evaluate the reliability of the generated trust scores, the proposed framework further utilizes the calibration error, which measures the agreement between the predicted trust-score and the observed ground truth. It is computed as:where τ(t) denotes the predicted trust score, y(t) represents the corresponding ground-truth label, and N is the total number of evaluated observations. Lower calibration error indicates that the estimated trust-scores more accurately reflect the true reliability of Oracle price feeds.

C a l i b r a t i o n E r r o r = 1 N ∑ t = 1 N ∣ τ t − y t ∣ ,

All experimental results presented in the subsequent section were evaluated using the above-described performance metrics to provide a comprehensive assessment of the predictive performance and trustworthiness of the proposed TOAD-ML framework.

6 Results and discussion

In this section, we provide the final results based on the predictive performance, the contribution of individual components of our proposed TOAD-ML framework, the performance in a real-world scenario where malicious websites were blocked, and the proposed trust-score’s behavior on different features.

6.1 Performance evaluation

Once trained, TOAD-MLis tested on the evaluation set for classification of suspicious events, as shown in Table 4. This result is later benchmarked against that of three other machine learning models: SVM, RF, andXGBoost. It should be noted that the version of XGBoost used in the comparison is the one without the calibration layers, as it is used in the current practice for classification-based DeFi price anomaly detection. TOAD-ML, on the other hand, relies on its unique score that takes into account the sources from which events originate in order to identify anomaly in DeFi.

Based on the table above, we can see that TOAD-ML performed well across all evaluated metrics and outperformed all the baseline models on all benchmarks. Specifically, TOAD-ML achieved the highest accuracy and AUC, and it greatly reduced the number of false positives and false negatives. In other words, with our approach, we successfully separated normal and manipulated price states.

6.1.1 Detection latency

Since detection latency was not independently benchmarked in the current implementation, no quantitative latency results are reported. The latency metric defined in Section 5.3 is included as a deployment-oriented performance measure and will be comprehensively evaluated in future work.

6.1.2 Ablation study

To quantify the contribution of individual TOAD-ML components, an ablation study was performed. Key elements such as TWAP data, multi-source fusion, and trust scoring were systematically removed to assess their impact. The results of this study are presented in Table 1.

The ablative study further demonstrated that the multi-source fusion contributes the most to the overall performance, emphasizing the importance of using cross-source validation to find malicious transactions in the TOAD-ML framework. TWAP is important to find subtle price manipulation, and trust scores enhance the prediction reliability. Similar exponential confidence formulations have also been widely adopted in anomaly detection and probabilistic confidence estimation literature.

6.1.3 Case study: Oracle attack detection

To illustrate TOAD-ML’s effectiveness, we created a small example using a well-known real-world Oracle manipulation scenario on DeFiHackLabs. In this experiment, TOAD-ML attempted to predict the Oracle manipulation event. We recorded the temporal sequence of Oracle price, TWAP price, and market price.

The general behavior of the attacks can be visualized from Figures 1–4. Figure 1 shows the relative price trends during the attack and non-attack periods, emphasizing the divergence among TWAP, Oracle price, and the market price. The deviation rate presented in Figure 2 shows how the prices deviate from TWAP to show the abnormality. The trust-score change in Figure 3 reflects the accuracy degradation of the oracle. Figure 4 presents how the detection rate is applied based on the normal/attack labels of the data.

6.1.4 Trust-score analysis

The trust score of the oracle indicates normal, mildly abnormal, and tampered states in which the oracle is trustworthy. The average deviation, volatility, update gaps, and trust scores for each state are mentioned in Table 3.

The trust score effectively differentiates the operational states: high values indicate stable state, and on the right, we see our trusted scores, and on the bottom, we have time. With the time axis, we can clearly see three patterns—we can divide them into three groups: values close to 1 represent a consistent and normal behavior, values around 0.5 may represent something unexpected or anomalous, and a value close to 0 represents manipulation.

To confirm the effectiveness of TOAD-ML in comparison to the existing state-of-the-art methods, TOAD-ML was tested against four comparable state-of-the-art detection models. POMABuster by Xi et al. and the model by Deng et al. were used as test cases since they also leverage the capability of real time validation. Models by Mackinga et al. and Mo et al. were selected to perform multi-source validation since their works focus on this aspect.

The comparative figures for POMABuster (Xi et al., 2024) and the models of Deng et al. (2024), Mackinga et al. (2022), and Mo et al. (2023) shown in Table 5 are drawn from the original publications rather than re-implemented on our dataset, since these methods differ in their scope, target tokens, and evaluation windows. This comparison should, therefore, be read as an indicative positioning against the reported literature rather than a controlled head-to-head evaluation on identical data; only the SVM, random forest, and XGBoost baselines in Table 4 were trained and tested on our exact dataset and split.

TABLE 5. Comparative analysis of Oracle attack detection methods.

Bold values indicate the best-performing result among the compared methods.

The comparative results presented in Table 5 are intended to provide a qualitative comparison with representative Oracle attack detection methods reported in the literature. Since these studies were evaluated using different datasets, experimental settings, and evaluation protocols, their reported performance values were not directly reproduced in this work. Therefore, the comparison should be interpreted as a literature-based comparison highlighting methodological differences rather than a direct experimental benchmark.

Figures 5, 6 show the performance comparison of Oracle attack detection. We used the AUC value for the classification of ROC curve.

6.1.5 Detection capability

When compared against existing works, our TOAD-ML method obtains the best performance metrics: accuracy 96.72% (4% above prior works) and AUC 0.97 (3% above previous best). Most of the improvements can be explained due to the engineered features, which characterize differences in behavior more efficiently and are more sensitive to sophisticated attacks than simplistic source-matching rules or thresholds.

6.1.6 Real-time support

The model by Mackinga et al. (2022) supports real-time detection. However, their implementation only uses TWAP data for a single source, which can lead to unreliable detections if that source experiences an error or delay. TOAD-ML can process multiple TWAP streams in real-time.

6.1.7 Multi-source inputs

A distinguishing feature of TOAD-ML is its integration of heterogeneous data sources:

• Chainlink Oracle rounds: Round-by-round ETH/USD, BTC/USD, and LINK/USD prices.
• CoinGecko historical prices: Market-level ETH/USD hourly prices.
• Uniswap V3 TWAP: Hourly pool data for ETH/USDC 0.05% and WBTC/USDC 0.3% pools.
• DeFiLlama multi-token prices: ETH, BTC, LINK, AAVE, UNI, and MKR hourly prices.

Our methodology integrates multi-source data, which allows for better cross-validation of detections and makes it possible to discover subtler or coordinated manipulations of data. Most existing methods use only one or two sources.

7 Conclusion

The key idea of the work is to design an Oracle manipulation detection system for price feeds on DeFi protocols. Such a system must identify price manipulations and provide insights into the reliability of the price feeds in time. We construct a dataset consisting of various price sources (Chainlink rounds, TWAP, CoinGecko market price, and DeFiLlama multi-token hourly price) and validated attack labels from DeFiHackLabs. Based on this dataset, we build TOAD-ML, which comprises of two stages: detection and trust calibration. The detection stage is based on XGboost to detect anomalies from the multi-sourced information, while the trust calibration stage estimates a trust score for each data point based on the evidence it receives from other sources. Our experiments show that TOAD-ML outperforms baseline methods by achieving 96.72% accuracy and 0.97 AUC-ROC. We demonstrate through ablations that the optimal performance requires leveraging data from multiple sources and incorporating the temporal behavior of price data. The constructed framework is further verified by using it in a controlled experiment and identifying the manipulation on price feeds caused by two notorious flash loans that have drained millions of USD on stablecoin exchanges. We note that the performance may be sensitive to the Z-score threshold used in preprocessing and to the specific tokens and time intervals evaluated; further validation across a broader range of market conditions is left for future work. A limitation of the current study is that inference latency was not independently evaluated under different blockchain deployment environments. Future work will include comprehensive computational benchmarking to assess the real-time performance and scalability of the proposed TOAD-ML framework in practical DeFi deployments. Although the proposed feature engineering strategy avoids label leakage by separating label generation from feature construction, future work will further validate the framework using additional independent datasets and cross-domain evaluations to assess its generalizability under diverse Oracle attack scenarios.

Our experiments demonstrate the potential of TOAD-ML in identifying Oracle manipulation and providing valuable guidance to protocols on the trustworthiness of their oracle feeds, thereby mitigating financial risks and improving the security of the DeFi ecosystem.

Generative AI statement

The author(s) declared that generative AI was used in the creation of this manuscript. Generative AI tools were used to assist with language refinement, grammar correction, text organization, and improving the readability of the manuscript. The authors reviewed, verified, and edited all AI-assisted content and take full responsibility for the accuracy, originality, and scientific integrity of the final manuscript. Generative AI was not used for data collection, data analysis, result interpretation, or the generation of scientific conclusions.

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.

Publisher’s note

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.

Footnotes

Edited by: Andrea Michienzi, University of Pisa, Italy

Reviewed by: Nimrita Koul, REVA University, India

Pisal Setthawong, Assumption University - Bangna Campus, Thailand