A Smart Contract Cannot See the Outside World — The Moment You Have to Trust Whoever Tells It the Price

Money Disappears Even When Nothing Is Broken

Decentralized finance (DeFi)—services that handle lending, borrowing, and trading without middlemen like banks by running programs on a ledger, with each such service called a protocol. A 2022 systematic review paper (preprint) examined 77 academic papers, 30 audit reports, and 181 real-world incidents together to categorize accidents in these services. In the authors' data, the losses tallied between April 30, 2018, and April 30, 2022, were at least $3.24 billion. In that data, the most frequent accident types were "Price Oracle Attacks" (15%) and "Permissionless Compositionality" (10.5%), which arises because anyone can call each other without permission. Yet almost no academic papers covered both of these, and the authors view this as a gap between academia and practice (arXiv:2208.13035).

It turns out that academic papers covering the most frequently occurring accident types were practically nonexistent. Among the accidents in that space, there is a pattern like this: The code ran exactly as written, and what shook was the value fed into the code.

A sentence frequently used for these services is "Code is law." The program is a smart contract—meaning conditions and what to do under those conditions are written on the ledger in advance, and when someone calls it, it executes automatically without human judgment ("What Is A Smart Contract?"). Because the contract terms are locked into a program and tens of thousands of computers run that program identically to verify it, it means neither a banker nor a notary can change their mind. This sentence is only half true, and the remaining half created the numbers above.

Suppose a lending service's program says, "If the value of the collateral falls below a set line compared to the money lent, liquidate the collateral." Liquidation is the process of cleaning up loans where the collateral value has dropped below the threshold before the lent money turns into a loss, with someone paying off the debt instead and taking over the collateral cheaply. That someone is the liquidator. The program executes this rule without fail. However, the program cannot know on its own what the value of the collateral is right now. All that is written on the ledger (chain) is who sent what to whom, and how much that token trades for in the market is a fact outside the ledger. Someone has to feed it in.

"What Is A Smart Contract?" defined an oracle as something that gathers facts from outside the ledger and feeds them into a smart contract, concluding that the receiving end becomes a place that must be trusted. This article narrows that space down to a single price and follows it. Therefore, in this article, an oracle is everyone who tells the price to the smart contract. Both the entity bringing in market prices from outside the ledger and the entity reading values from transactions inside the ledger (as we will see later) are included here, making it slightly broader than the definition in the primer.

This article follows where the promise that "you don't need to trust anyone" breaks the moment an oracle enters. It does not put safety or risk labels on specific protocols, nor does it cover attack methods, market prices, or outlooks.

Code Cannot Know Facts Outside the Chain

The foundation that allows blockchains to run without a trusted institution is determinism. Determinism, as defined in "What Is a Smart Contract?", is the property where applying the same rules to the same input yields the same result no matter who executes it. Only then can tens of thousands of computers running calculations separately converge on a single answer, verifying each other and reaching consensus.

Because of this same property, blockchains cannot independently fetch external non-deterministic data—that is, data whose answers can change depending on when and who asks. The real-world data that DeFi relies on does not sit directly on the ledger, and so oracles emerged as a solution to feed that data into the ledger (arXiv:2201.02358). The oracle problem is the problem of how to move data from outside the ledger into the ledger, and without that path, smart contracts can only use data already on the ledger.

The shape of this problem is old. One study (preprint) defines the oracle problem as "the receiver's inability to know whether information from an oracle is true and unbiased," tracing it all back to the ancient Oracle of Delphi. Even in ancient times, philosophers and historians debated how much oracle prophecies could be trusted, and how to increase and protect that trust (arXiv:2511.03319).

The oracle problem cannot be solved by cryptographic tools like signatures alone. A digital signature is a mark that can only be created by someone holding a private key and verified by anyone with a public key ("Keys and Locks"). A signature confirms that a value came from the owner of that key. There is no way to verify within the ledger whether that value is true.

The first study to measure a running oracle in practice (preprint) found two things. First, the designs of major platforms relying on oracle data treated oracles as trusted parties bearing little or no responsibility, which the authors noted as surprising. Second, in large-scale measurements, the prices reported by oracles regularly deviated from the exchange rates at the time, oracles experienced operational issues, and anomalies were mixed into the reports (arXiv:2005.04377). This means that a mechanism built to be trusted was actually producing misaligned values as well.

Research from the auditing side calls this the "oracle paradox." While blockchains provide a fairly immutable stream of records, proof that those records accurately capture physical events does not undergo truly independent verification. Regarding proposals to set up humans as trusted oracles, this study cites the conclusion of auditing research. Humans are the weakest link in almost every internal control, and their vulnerability to collusion, bribery, error, and fraud is not entirely eliminated by blockchain technology (DOI: 10.2308/isys-19-024).

One literature review extracts a regularity from this. The more trustworthy a system already is, the smaller the impact of the oracle problem (DOI: 10.3390/info11110509). Read in reverse, the greater the goal of eliminating trusted entities, the more painfully the oracle problem hits.

The sentence "No one needs to be trusted" is true only within the ledger. The moment even a single fact from outside the ledger is needed, trust shifts to the narrow passage known as the oracle.

When the Input Shakes, the Code Does the Wrong Thing According to the Rules

Let us return to the collateral example from earlier. If a price that differs from the actual market price at that moment enters the rule that liquidation occurs when the collateral value falls below a threshold, the program executes an incorrect liquidation without bugs, exactly according to the rules. That result cannot be undone. The fact that it cannot be undone was originally the boast of this device.

Oracle manipulation is an attack that shakes the price fed into the contract by the oracle, causing the contract to exchange money based on that incorrect price. The attacker becomes able to swap tokens at prices that deviate wildly from the market (arXiv:2502.03718). A study published in a peer-reviewed journal in 2026 notes that this attack has evolved beyond a simple economic attack into a complex attack that probes the logic of smart contracts across multiple transactions, resulting in hundreds of millions of dollars in losses (DOI: 10.1145/3817054).

The mechanism that lowers the threshold for this attack comes from the nature of a single transaction. A single transaction sent to the ledger is called a transaction, and within a single transaction, multiple contracts can be called sequentially. Atomicity is the property where either everything in a single transaction succeeds completely or never happened at all.

A flash loan is a loan that uses this property to allow someone to borrow a large amount without collateral and pay it back before the same transaction ends. If it cannot be paid back, the act of borrowing itself never happened, so the lender bears no risk of default (arXiv:2206.10708). A flash loan in itself is not a tool solely for attacks. The problem is the barrier of capital. Shaking the price used as an oracle requires substantial capital, but a flash loan temporarily hands that capital even to those who lack it. A study analyzing the structure in which lending protocols rely on price oracles (preprint) also concludes that the emergence of flash loans has magnified this risk, making it possible for large losses to occur through increasingly complex oracle manipulations (arXiv:2401.08520).

A 2021 study (preprint) provides the first broad overview of actual incidents, viewing many attacks as market attacks rather than mere misuse of a single protocol. The loose business logic of one protocol is leveraged using money borrowed from another protocol to execute the attack. Composability is the property where different protocols interlock and work together like building blocks. The authors note that attackers increasingly turn this permissionless composability—the strength of DeFi—against DeFi itself (arXiv:2106.10740). Without this property, DeFi cannot exist, yet this same property becomes the pathway for accidents.

Numbers that offer hope to defenders also appear in the same taxonomy. 103 attacks (56%) were not executed atomically. This means they did not end in a single transaction but proceeded across multiple steps, leaving time for defenders to intervene in between. Furthermore, 15.3% of attackers (33 cases) leaked information hinting at their identity while transacting with centralized exchanges (arXiv:2208.13035). A centralized exchange is one of the exchanges from "Where Are My Coins?", meaning a place where coins are swapped for money or other coins, operated by a single company.

The code followed the rules, and what was shaken was the input that entered the rules. The code has no ability to doubt that input.

The Price Inside the Ledger Moves Through Trades

The easiest oracle is the price that is already on the ledger. A significant portion of the exchanges on the ledger use liquidity pools instead of an order book that matches buy and sell orders. A liquidity pool is a shared pool of funds holding two kinds of tokens together, and traders swap tokens by putting one kind into this pool and taking the other out. An AMM (Automated Market Maker) is a contract that sets prices according to a formula determined by the amount of tokens contained in the pool, allowing exchanges to happen at any time without anyone quoting prices. In the most common form, the ratio of the two amounts is the price itself, so there is no need to buy data from the outside.

Here is the trap. The price of an AMM is not a fact observed from the outside, but the current state of that pool. The state of the pool changes through trades. Therefore, this price is a value that anyone can directly move through trades.

A 2026 formal study (preprint) calculates how much it costs to move this value. The authors define manipulation cost as "the minimum valuation loss the attacker must endure to move the oracle by a given multiple," in other words, the smallest loss the attacker takes on when evaluated at market price. When set up as a game where the designer chooses how to combine prices from multiple pools and the attacker shakes that combined value, the results varied depending on the combining method when the pools were independent of each other. In the weighted median, which is the median value given different weights for each pool, weights proportional to liquidity, meaning the amount of assets contained in the pool, maximize the minimum manipulation cost regardless of the size of the distortion. With the weighted average, the larger the distortion, the easier it is to shake, and there is no single best weight across all distortion sizes. However, in a model where arbitrage trades flow between pools, the manipulation cost depends only on the total depth of the pools, and became identical among symmetric combining methods (arXiv:2606.03548).

Manipulation resistance is not divided into present or absent, but is an amount that is priced. Designing an oracle is the job of determining how much must be burned to move this value by this much, and if that value is smaller than the profit that can be extracted by shaking it, an incentive to shake it arises.

The reason an oracle hurts particularly in a lending protocol is that the trigger for liquidation is precisely the oracle price. A 2026 study (preprint) modeled the strategy of a liquidator trying to maximize profit in a lending protocol that uses an AMM price as an oracle. The authors write that the way liquidation works exposes the protocol to predatory price manipulation and other MEV. MEV is, as defined in "Is Blockchain Really Decentralized", the profit that can be extracted from the position of inserting, removing, and reordering transactions to go into the next page of the ledger, in other words, the newly attached block. The liquidator in this model slips their own transaction before and after someone else's transaction to shake the pool's price and triggers profitable liquidations.

The same study proves that the AMM's trading fee is a decisive security knob. This fee is different from the fee in "The Right to Write a Line in the Ledger", which is the price attached to have your one line entered into the ledger; it is the share returned to those who deposited assets into the pool when swapping with the pool. The fee does more than just reduce the attacker's profit; it can make manipulation itself unprofitable. The authors suggest here that the fee can harden the oracle from the inside without the time-averaged delay we will see later (arXiv:2602.12104).

There Is a Price on a Buffer

A widely used buffer is TWAP. TWAP (Time-Weighted Average Price) uses a value averaged by giving weight to the time each price stayed during a set time window, instead of the price of the moment. The idea is that even if you shake the moment, the average does not move easily.

There is a price on this buffer. A 2024 study (preprint) noting that arithmetic mean TWAP oracles are widely used reports that previous studies pointed out that TWAP is also vulnerable to price manipulation, which is why TWAP oracles usually set a fairly long time window to block it. When the window becomes long, the delay becomes long, and the error deviating from the market price also grows (arXiv:2410.07893). The more sluggish it becomes to manipulation, the more sluggish it becomes to the truth. The two are both ends of the same handle.

Then, a 2024 study (preprint) examined whether each protocol can just pick and use a safe number. The authors built a tool that automatically analyzes contracts to find the range of setting values (parameters) that run safely even if the oracle value goes wrong. When this tool was run on a test set gathering 10 DeFi protocols, the setting values that the majority were using at the time of the study fell short of guaranteeing safety when oracle values are distorted significantly (arXiv:2401.06044).

Code audit, by the definition in "What Is a Smart Contract?", is the work of a person or tool reading code to find gaps before putting the contract on the ledger. Oracles are not protected by this alone. Even if there are no bugs in the code, if the numbers that code uses are not caught to withstand external shakes, the result is the same.

The Choice to Pick an Oracle Is Hard to Undo

The choice of an oracle by a protocol ties it to a technical dependence, making it difficult to change once chosen. This is the finding of a survey (preprint) that directly asked 32 DeFi protocol founders, executives, and oracle engineers. The assets entrusted to the responding protocols totaled over 55% of the entire DeFi ecosystem using oracles. Based on these responses, the authors suggest that immutability amplifies this lock-in, making it difficult to switch data providers. Immutability, as defined in "What Is a Smart Contract?", is the property where code recorded in the ledger cannot be changed thereafter. Also, when usable external solutions existed, protocols generally chose to outsource rather than build themselves (arXiv:2512.03088).

For the protocols that responded to the survey, deciding where to place trust was hard to reverse once chosen, and when usable external solutions existed, they generally outsourced that role. The virtue that "code cannot be changed" becomes a weakness here, making it difficult to switch away from a poorly chosen dependence.

Making a choice requires numbers to compare, but those numbers are also shaky. One preprint independently verified indicators self-reported by commercial oracle systems using data on the ledger. Gas is a fee charged for the computational effort of running contracts on Ethereum. When event records and transaction receipts from the Ethereum ledger were collected directly and recalculated, the gas savings claimed by one provider were a median of 29.8%, not the claimed 65.7%. The dispute rate of another system was 0.80%, lower than the reported 1.4% (DOI: 10.2139/ssrn.6561059, preprint). The latter discrepancy was in a favorable direction compared to the report. What these two figures together tell us is that self-reported numbers and independently measured numbers can diverge in both directions.

Does Decentralization Eliminate Trust or Shift It?

The standard prescription for the oracle problem is decentralization. "The Right to Write a Line in the Ledger" defined decentralization as a state where the power to write in the ledger is not concentrated in one or two places, but scattered among multiple independent participants. In the case of oracles, this means scattering the power to report values. Instead of a single location, multiple participants report values, and those reports are combined through voting based on staked tokens or reputation (DOI: 10.1145/3567582).

The basis for the optimistic side is formal analysis. One oracle design based on voting games (preprint) calculated the probability that an attacker with limited funds succeeds in manipulating the oracle's verdict. The results show that, depending on the chosen settings, manipulation can be made as difficult as desired, and under those conditions, there is a Nash equilibrium where all rational participants are forced to act honestly (arXiv:1808.00528). An equilibrium, in the definition from "The Right to Write a Line in the Ledger", is a state where no participant has anything more to gain by changing their strategy alone, so everyone stays put.

The basis for the skeptical side comes in two prongs. The first is measurement. When we measure layers labeled as decentralization, they are usually narrow. One social network analysis (preprint) found a clear core-periphery structure in the transaction network where tokens of a representative lending protocol flow. The shape showed a few addresses gathering transactions in the center while the rest stayed on the edges, and at the center were two of the largest centralized exchanges. The same study also reports a statistical relationship where periods with a more decentralized transaction network saw less fluctuation in that token market (arXiv:2206.08401). Saying that the scope of decentralization is narrow is different from saying that scope is meaningless. It is the same pattern of concentration measured across layers from mining to governance in "Is Blockchain Really Decentralized".

Governance is the process of deciding a protocol's rules and settings through votes by token holders, and the problem of those voting rights being bought and sold is covered by "The Power to Change the Rules Is Also for Sale". There are sharper numbers for this governance. One preprint reports that in proposals setting risk-related parameters, the median share of voting rights held by the top five addresses was 96.0%. Because variance across protocols was large, the three locations given as examples by the authors were 91.2%, 84.3%, and 57.7%. The authors specify that this evidence should not be read as a determination of who actually exerts control, but as clues to filter through by pathway (DOI: 10.2139/ssrn.7003865, preprint). Risk settings, such as what to use as an oracle, can also come up for this kind of vote.

The second prong is principle. A preprint that critiques blockchain designs through the lens of political science argues that in actual applications, the power of central actors does not disappear, but merely shifts to new points of control lacking democratic legitimacy (arXiv:2405.06097). Because this is a strong normative claim that even goes so far as to say blockchain research should be stopped, we read it as one perspective among many. What this article takes from it is not the conclusion, but the shape of the question asking whether power has disappeared or shifted.

There is also an expectation that artificial intelligence will solve this problem. One position paper (preprint) acknowledges that AI techniques improve oracle data quality, source selection, and resilience. At the same time, it reports that AI cannot eliminate the very act of relying on unverified external inputs, concluding that AI should be understood not as a replacement for trust assumptions, but as a supplementary layer within oracle design (arXiv:2507.02125).

Designs that withstand manipulation always come with a cost. Time averaging introduces delay, fees are a cost imposed on traders, and shifting to external oracles creates hard-to-reverse dependencies. The range that defenses can withstand also depends on conditions. A study presenting an analytical framework for flash loan attacks simulated an attack case on a platform and predicted that while the existing defense mechanism of fair reserves fully protects the platform in normal markets, it breaks down under extreme volatility where the token price drops by 60% within an hour, causing over 8 million dollars in damage (DOI: 10.3390/informatics10010003). There is no such thing as a safe design on its own; there are only designs whose values have been set to withstand specific conditions.

Liquidation involves an even sharper trade-off. One preprint calls this the paradox of adversarial liquidation. For a lending protocol to function properly, there must be an incentive for liquidators to act immediately when a loan becomes distressed. However, setting that reward too high also creates an incentive to front-run the liquidation process and shake the price, and the resulting outcome is disadvantageous to the borrower (DOI: 10.2139/ssrn.4540333, preprint). The oracle price is what triggers liquidation, and the party that profits from that liquidation has the incentive to shake that price.

There is also a case showing what attempts to profit by shaking prices leave behind in a lending protocol. In November 2022, on a major lending protocol, an individual attempted to artificially drive down the price of a token by massively selling tokens they had borrowed from that protocol onto exchanges. Although the attempt failed, it left behind unrecoverable debt exceeding 1.5 million dollars by the standards of that time. The authors diagnose that the volume of that borrowable token was excessively large and protocol design made rapid intervention difficult. They conclude that major DeFi lending protocols face a bind of 「limiting scope or compromising on 'decentralization'」 (arXiv:2302.04068).

The List of Incidents Is a List of What Was Reported

The final layer on the defending side is detection. Several detection studies have been published, each reporting high grades.

One real-time detection study (preprint) shifted its gaze from the victim to the attacker. Since an attacker typically has to upload a malicious contract to the ledger prior to an attack, the researchers built a tool to recognize such contracts solely from the machine code (bytecode) posted on the ledger. What catches the eye is a side discovery. This tool reported 616 items judged to be attack contracts on the actual ledger, and the authors tallied this as 9.25 million dollars in losses, of which only 19 had been publicly reported (arXiv:2502.03718).

The list of incidents we know is closer to a list of what has been discovered and reported than to the list of actual incidents.

Detection combined with large language models has also emerged. A 2025 study (preprint) starts from the observation that among 95 price manipulation attacks reported over the preceding three years, 44.2% occurred in protocols using non-standard, custom price calculation methods, and existing tools were weak against them. The authors used this tool to help an industry partner identify 147 actual price manipulation attacks, 81 of which were previously unknown past events (arXiv:2502.11521). It points in the same direction as the previous finding.

Three caveats are attached to these grades.

First, detection papers almost without exception self-report the performance of their own tools. The recall (the proportion of actual attacks caught) and precision (the proportion of alerts that are actual attacks) put forward by detection papers are mostly values measured by the authors, and because data and criteria differ from paper to paper, it is difficult to compare them side by side.

Second, the scope covered is narrow. A 2026 study (preprint) points out that existing detection tools typically handle only specific attack types, leaving their detection scope severely narrow (arXiv:2607.22184). There are also flash loan attacks unrelated to price. According to a 2025 study (preprint), existing research has mainly focused on price manipulation attacks such as oracle manipulation, while these attacks unrelated to price have been rarely covered and are difficult to catch. Targeting this category, that study built a tool to catch and stop attacks during execution, and estimates that if it had been pre-deployed to past events, it could have saved over 400 million dollars in losses (arXiv:2503.01944). A tool to fill the empty category has appeared, at least for this category.

Third, the same research can be used in both directions. To find possible flash loan attacks in advance, researchers also build tools that automatically generate attacks (arXiv:2206.10708). The structural tension in this field is that the results found to defend can also be read in the opposite direction.

Facts That Observation Cannot Create

The discussion so far has assumed that a true value exists outside and that the problem is bringing it in accurately. There are facts for which that assumption does not hold.

A preprint points out that oracle literature has implicitly treated all external data as brute facts (DOI: 10.2139/ssrn.7300959, preprint). Brute facts are facts that exist regardless of human agreement, like temperature, price, or delivery status, which multiple independent observers can approach by observing the same direction. Because observation broadens as you increase people, decentralization works. Institutional facts are facts that come into being only when an authorized institution grants them. A securities identification number is an example of this, so no matter how many independent observers you gather, observation cannot make that number come into being. The authors conclude that for institutional facts, the design goal is not about reducing places to trust, but rather achieving legal equivalence so that the representation on the ledger has the same effect as the external legal act.

The authors place price on the side of brute facts. However, as this article sees it, this distinction also leaves one question for price. Someone ultimately has to decide which trading venue's price, at which time, combined in what way, is to be regarded as the price of that asset. The way of combining prices from multiple pools and the time window for taking an average, which we saw earlier, are such choices.

Part of this problem is closed by a theorem. In "What Is a Smart Contract?", the promise to hand over deposited money when goods arrive is exactly this case. A study (preprint) deals with transactions buying and selling off-chain goods on a blockchain. The buying side does not want to release money before receiving the goods, the selling side does not want to hand over the goods before receiving the money, and neither side wants to use a middleman. The authors prove that if both parties are rational and the smart contract language is Turing complete—meaning a language capable of writing any computation—no escrow contract exists that prevents either party from extortion without relying on a third party (arXiv:2110.09857). An escrow contract is a contract that holds money until a transaction is finished. This result is not the kind that can be bypassed by tweaking oracle design. At least in transactions like this, you either trust someone, or leave room for one side to be extorted, or both.

Evidence in the Opposite Direction

There is also empirical evidence that in the NFT market, public ledgers blunt obvious wash trading. One preprint analyzed 7.4 million transactions across a collection of 561 NFTs, which are tokens representing unique digital assets. Wash trading, where people buy and sell among themselves to pretend there is activity, had a negligible impact on market outcomes. The author interprets this as the transparent ledger neutralizing obvious trade-based manipulation while giving participants enough information to spot seemingly insider activity (DOI: 10.2139/ssrn.4397409, preprint). However, in the same study, purchases by seemingly insider parties predicted the subsequent performance of that collection.

The same attack yielded different results depending on the ledger. Front-running, where someone peeks at another person's pending trade and jumps ahead to buy or sell first, is an example of MEV given in "Is Blockchain Really Decentralized". One preprint compared transaction records of a pair of large liquidity pools on Ethereum and Polygon, which the authors classify as an L2. The share lost by the attacked trader to the front-runner was an average of 0.27% (Ethereum) and 0.04% (Polygon) of the initial transaction amount (DOI: 10.2139/ssrn.4370843, preprint). Starting from the difference in validation methods between the two ledgers, the authors read this as empirical evidence favoring the L2 side against front-running. However, the evidence is based on transaction records from a single pair of large liquidity pools. What an L2 inherits is covered in "Is an L2 Really as Safe as Ethereum?".

Some point out that the frameworks for measuring risk are themselves insufficient. A 2026 preprint proposes adding three dimensions to existing risk assessment frameworks: composability risk, comprehension debt, and risk changes over time. When retrospectively analyzing 12 major incidents from 2024 to 2026, at least one new dimension was required to fully explain the root cause in 5 out of the 12 incidents (arXiv:2605.05145). The name "comprehension debt" serves as a reminder that the code being public is a different thing from someone actually understanding the system created by those codes interlocking with one another.

What Can Be Verified and What Must Be Trusted

The list of what can be verified inside the ledger is short but solid: who owns what and how much, in what order transactions were written, and what the rules of the contract are. Anyone can check these at any time without having to take someone else's word for it.

A much longer list remains outside the ledger: what the current price of this token is (arXiv:2005.04377), whether the party that reported that price was honest (arXiv:2511.03319), whether the pool from which the price was pulled was deep enough against manipulation (arXiv:2606.03548), how late the averaged time window captures the truth (arXiv:2410.07893), whether the governance that chose that oracle was actually broad (DOI: 10.2139/ssrn.7003865, preprint), and whether that choice can be undone later (arXiv:2512.03088).

This list is less a list of failures than a list of designs.

The phrase "code is law" is true regarding rules. Code is indeed executed without exception. However, those rules operate by taking inputs, and whether an input is true is not the kind of thing the code can judge.

The interpretation of this article is as follows: decentralized finance has not eliminated places to trust, but it has moved many of those places onto the ledger where they can be inspected. Yet being able to inspect something is different from someone actually inspecting it, and the incidents publicly reported in the detection research mentioned earlier were only a fraction.

So the remaining question is this: What are you trusting, and what is the price of that trust?

This question comes with the caveat that it is hard to undo. The immutability of smart contracts is a virtue that preserves rules, but it is also a shackle that binds poorly chosen dependencies in place so they are hard to swap out (arXiv:2512.03088). Choosing where to place trust is a choice in this system that is difficult to fix later.

The ledger proves facts within itself. Regarding facts outside the ledger, it merely records who was supposed to report them and how. Proof and recording are different tasks, and what this system has changed is the recording side. What has been chosen to be trusted is now written in the code.

Source Papers

• "SoK: Decentralized Finance (DeFi) Attacks" (2022) — arXiv:2208.13035 (preprint) — 77 papers, 30 audits, 181 incidents. At least $3.24 billion in losses from 2018 to 2022. Price oracle attacks at 15% and permissionless composition at 10.5% are the most common, yet academic papers are scarce. 103 attacks (56%) are non-atomic.
• "Towards Trustworthy DeFi Oracles" (2022) — arXiv:2201.02358 (preprint) — Because blockchains are deterministic, they cannot acquire external non-deterministic data on their own.
• "Two thousand years of the oracle problem" (2025) — arXiv:2511.03319 (preprint) — Defines the oracle problem as "the receiver's inability to know the truth" and traces it back to Delphi.
• "A First Look into DeFi Oracles" (2020) — arXiv:2005.04377 (preprint) — Designs treat oracles as low-accountability trusted parties, with reported prices regularly deviating from contemporary exchange rates.
• "Trust but Verify: The Oracle Paradox of Blockchain Smart Contracts" (2021) — DOI: 10.2308/isys-19-024 — There is no independent verification proving that a record reflects a physical event. Humans are the weakest link in internal controls.
• "Understanding the Blockchain Oracle Problem" (2020) — DOI: 10.3390/info11110509 — The more a system is already trusted, the smaller the impact of the oracle problem.
• "DeFiTrace" (2026) — DOI: 10.1145/3817054 — Price oracle manipulation evolves into compound, multi-transaction attacks. Anomaly detection trained exclusively on normal transactions.
• "SecPLF" (2024) — arXiv:2401.08520 (preprint) — Flash loans amplify risk, making severe losses possible through complex oracle manipulation.
• "Flash Crash for Cash" (2021) — arXiv:2106.10740 (preprint) — Many exploits are market attacks, with attackers turning permissionless composability against DeFi itself.
• "Cost of Manipulation in AMM-Based Oracles" (2026) — arXiv:2606.03548 (preprint) — Defines manipulation cost as minimum evaluated loss. Weighted median is optimal when proportional to liquidity, but the weighted average becomes increasingly vulnerable as distortion grows.
• "Liquidation Dynamics in DeFi and the Role of Transaction Fees" (2026) — arXiv:2602.12104 (preprint) — Liquidation dynamics expose systems to predatory price manipulation, while proving that AMM trading fees are a decisive security parameter.
• "Ormer" (2024) — arXiv:2410.07893 (preprint) — TWAPs are also vulnerable to manipulation, prompting longer windows, which in turn introduce delay and deviation errors.
• "Safeguarding DeFi Smart Contracts against Oracle Deviations" (2024) — arXiv:2401.06044 (preprint) — Parameters currently in use across a majority of benchmarks are inadequate to guarantee safety against large oracle deviations.
• "How DeFi Protocols Choose Oracle Providers" (2025) — arXiv:2512.03088 (preprint) — Survey of 32 protocols. Immutability amplifies lock-in, making it difficult to switch providers, and protocols generally prefer outsourcing.
• "Settlement Verification in DeFi Credit" (2026) — DOI: 10.2139/ssrn.6561059 (preprint) — Recalculating self-reports with on-chain data: claimed gas savings of 65.7% versus a median of 29.8%, dispute rates of 1.4% versus 0.80%.
• "Connect API with Blockchain: A Survey on Blockchain Oracle Implementation" (2023) — DOI: 10.1145/3567582 — Classification of oracles into voting-based and reputation-based.
• "Astraea: A Decentralized Blockchain Oracle" (2018) — arXiv:1808.00528 (preprint) — Manipulation can be made arbitrarily difficult depending on parameters, and a Nash equilibrium exists where honesty is enforced.
• "Is decentralized finance actually decentralized?" (2022) — arXiv:2206.08401 (preprint) — Two large centralized exchanges at the core. At the same time, more decentralized networks predict higher returns and lower volatility.
• "Measuring the DeFi Control Layer" (2026) — DOI: 10.2139/ssrn.7003865 (preprint) — Median of 96.0% voting stake held by the top 5 in risk parameter proposals (varying by protocol, e.g., Aave 91.2%, Uniswap 84.3%, Radiant 57.7%). Authors specify reading as filtered input per channel.
• "A trustless society? A political look at the blockchain vision" (2024) — arXiv:2405.06097 (preprint) — Normative argument that power is not dissolved, but shifts to democratically unjustified control points.
• "Can Artificial Intelligence solve the blockchain oracle problem?" (2025) — arXiv:2507.02125 (preprint) — AI improves data quality but cannot eliminate the underlying dependence on unverified off-chain inputs. Not a replacement for trust assumptions.
• "The Flash Loan Attack Analysis Framework" (2022) — DOI: 10.3390/informatics10010003 — Simulation of a single platform case. Existing defenses (fair reserves) protect in normal environments but break down in a 60% drop within one hour, predicting over $8 million in damages.
• "The Paradox of Adversarial Liquidation in Decentralised Lending" (2023) — DOI: 10.2139/ssrn.4540333 (preprint) — Rewards large enough to set liquidators in motion also create the incentive to sway prices.
• "Short Squeeze in DeFi Lending Market" (2023) — arXiv:2302.04068 (preprint) — Over $1.5 million in unrecoverable bad debt despite failed attempts. A dilemma between scoped limits and compromising on "decentralization."
• "Following Devils' Footprint" (2025) — arXiv:2502.03718 (preprint) — Found 616 attack contracts and $9.25 million in losses, but only 19 were publicly reported.
• "Detecting Various DeFi Price Manipulations with LLM Reasoning" (2025) — arXiv:2502.11521 (preprint) — Non-standard price model protocols account for 44.2% out of 95 cases over 3 years. 81 out of 147 verified cases are previously unknown incidents.
• "DeFiScreener" (2026) — arXiv:2607.22184 (preprint) — Existing tools address only specific attack types, severely limiting detection coverage.
• "Protecting DeFi Platforms against Non-Price Flash Loan Attacks" (2025) — arXiv:2503.01944 (preprint) — Category of flash loan attacks unrelated to price. Estimate suggests over $400 million in losses could have been averted if deployed in past incidents ahead of time.
• "FlashSyn" (2022) — arXiv:2206.10708 (preprint) — Automated attack synthesis for defense evaluation. An example of dual-use tension.
• "The Oracle Problem in Regulated Tokenization" (2026) — DOI: 10.2139/ssrn.7300959 (preprint) — Distinction between natural facts and institutional facts. The design goal of institutional facts is not trust minimization, but legal equivalence.
• "Irrationality, Extortion, or Trusted Third-parties" (2021) — arXiv:2110.09857 (preprint) — Under two rational participants and a Turing-complete language, no extortion-free escrow exists without a third party.
• "Market Manipulation on the Blockchain" (2023) — DOI: 10.2139/ssrn.4397409 (preprint) — 7.4 million transactions across 561 collections. Wash trading has negligible impact on market outcomes — interpreted as transparent ledgers neutralizing blatant manipulation.
• "Comparing Price Manipulation Attacks Across Layer 1 and Layer 2" (2023) — DOI: 10.2139/ssrn.4370843 (preprint) — Affected trader losses average 0.27% in one setting versus 0.04% in another for the same type of exploit.
• "Toward a Risk Assessment Framework for Institutional DeFi" (2026) — arXiv:2605.05145 (preprint) — Adds three dimensions: composability risk, debt of understanding, and temporal risk dynamics. 5 out of 12 incidents require the new dimensions.