What Is a Smart Contract? — A Promise Everyone Runs the Same Way, Exactly as Written

An Investment Club Without People

In the spring of 2016, an investment club opened its doors on top of a ledger called Ethereum. Participants put in money and received the chance to vote on which businesses, among those put forward by newly formed companies, should receive investment. The work of sending money back and forth and settling the math between the investors and the companies was handled automatically by a program written into the ledger. The name of the club was The DAO (DOI: 10.4018/jcit.2019010102).

The club collapsed not long after opening its doors. Someone whose identity was not revealed made off with a share amounting to more than 50 million dollars out of the 168 million dollars gathered. Following this, the participants of this ledger went through a vote and decided to roll the ledger back to the state before the incident. The method used to roll it back was a fork, which we saw in "What Is a Blockchain"—namely, the act of splitting the ledger's chain into two branches. The money was returned to the investors, and the club closed its doors (DOI: 10.4018/jcit.2019010102).

Regarding this rollback, a paper points out two things. One is that there is room to view this as a bailout, meaning an act where the side that should have borne the loss was rescued from the outside. The other is that it violated the principle that once written, a ledger does not change, as well as the spirit of "Code is Law," which dictates that whatever happens according to what is written in the code is accepted as is. Pointing out that Bitcoin was born in 2008 in opposition to the bailouts of American banks, the paper views this as an irony (DOI: 10.4018/jcit.2019010102).

In a club made to run without people, the final decision was ultimately made by people gathering together. This article follows the questions left behind by this incident. What does it mean for a promise written down in a ledger to be executed without people, exactly as written? What happens when that promise is written incorrectly, when one needs to know things outside the ledger, or when one wants to fix what has been written? We do not cover what things cost right now or the methods of attack that can be copied. Because how the law treats this promise differs from country to country, we carry the discussion only as far as the arguments of legal scholars.

Promises Written in the Ledger

"The Right to Write a Line in the Ledger" used a single-line promise as an example: "If Ga sends 10, transfer 5 entrusted to this line to Ga." A smart contract is something that records conditions and what to do under those conditions in advance in the ledger, and when someone calls that line, it checks the conditions and executes them as written without human judgment. Calling that line means sending a transaction to that line. Let us unpack this definition layer by layer.

The idea itself is older than blockchains. A 1997 paper introduced smart contracts as devices that formalize and enforce relationships among people over a computer network using a defined format. It bundles the procedure for exchanging promises together with the screen the user sees. According to that paper, security devices like cryptography can protect many relationships that can be written in algorithms. It argued that this can prevent parties from breaking promises, and third parties from peeking or interfering. However, that protection comes with limits. They are time, the user's interface, and how completely the algorithm describes the contents (DOI: 10.5210/fm.v2i9.548). The final limit is the question of whether every single case can be completely described in code.

That idea moved onto the blockchain ledger. Bitcoin and Ethereum became equipped with the ability to record rules for processing transactions or short commands. This feature grew into full programs running on the ledger. Around 2016, tens of thousands of such contracts on Ethereum held millions of dollars' worth of value (DOI: 10.1145/2976749.2978309). The usage of the name also changed. At first, it referred to the automated processing of legal contracts in general, but now it is widely used as a name for pieces of code running on a blockchain (DOI: 10.1109/tse.2019.2942301). This article also uses it in the latter sense.

When someone calls that line, the witnesses of "What Is a Blockchain" each run that code. The witnesses are computers—specifically, nodes—that hold a copy of the ledger in its entirety and exchange it with one another. The execution result becomes something that all nodes that ran the code trust and agree on (DOI: 10.1109/access.2020.2992698). For separately run computations to converge on a single answer, whoever runs it with the same input must arrive at the same answer. Determinism is the property where applying the same rules to the same input yields the same result no matter who executes it.

That is why a mediator in the middle is unnecessary. Since the code takes charge of execution, as long as the uploaded code remains unchanged, neither of the two parties who made the promise can back out halfway (DOI: 10.1109/access.2019.2921624). What happens when someone holds the key to change the code will be examined later. Binding the promising party so they cannot change their mind later and forcing them to keep their promise is cited as an advantage of smart contracts. There is also a cost. Because there is no trusted intermediary, the cost of building and running something on a blockchain swells (DOI: 10.1146/annurev-financial-110921-022806). One of the reasons for this is that computations that could simply be done once by a single trusted person must instead be repeated by every single node.

A smart contract is a program on the ledger where all witnesses repeat the same computation to arrive at the same answer, and therefore there is no human judgment in the middle.

Whatever Is Written Down Becomes the Rule

In 2016, the funds from that collective drained away through a crack left in the code. The attack poked at the subtle details of how Ethereum runs code. Because Ethereum is open to anyone, any program can call a function that another program has made public, even if the caller is a user whose name is hidden. For this reason, carefully written code can become dangerously intertwined with code of unknown origin through mutual calls, making the use of secure smart contracts very difficult (DOI: 10.1145/2993600.2993611).

A vulnerability is a crack left in the code that allows anyone—simply by calling it according to the written rules—to produce a result the creator never intended. The witnesses merely calculate as instructed, with no way of knowing what the creator actually meant.

Every type of crack has a name. Reentrancy is a crack where a function that has been called is invoked again before it finishes its own job. If a function that pays out money has this crack, an attacker's contract can repeatedly call that function before the first call finishes, emptying the contract's funds (DOI: 10.1109/netcrypt65877.2025.11102145). This happens because if the code sends money before subtracting the paid share from the ledger, every time it is called again, it sees the share as still undiminished and pays out once more. The 2016 incident involving that collective is cited as the most widely known example of this type. Methods to block and find this crack are also organized, and the paper presenting these findings concludes that mitigating this risk is essential to preserving the integrity of blockchain applications and ensuring the widespread adoption of smart contracts (DOI: 10.1109/netcrypt65877.2025.11102145).

There are more instances where a simple mistake led to massive losses. The incident involving that collective and the hacking of a wallet called Parity resulted in millions of dollars in losses solely due to simple mistakes left in smart contract code (DOI: 10.1109/access.2020.2970495).

Fixing them is also difficult. Immutability is the property that code once posted to the ledger cannot be changed thereafter. Ethereum's smart contracts have this property by default (DOI: 10.48550/arxiv.2304.03405, preprint survey). While the entrusted shares and records change every time they are called, the code itself does not. The rollback in the first section was an event where participants voted to revert the ledger to its state before the incident. That is why it was criticized for breaking the principle that once written, the ledger is never altered (DOI: 10.4018/jcit.2019010102). Code that has been posted cannot receive security patches—that is, modifications to patch up cracks. Developers are therefore under pressure to equip themselves with solid security strategies before deployment (DOI: 10.1109/access.2020.2970495).

This property works in both directions. A contract posted to the ledger is expected to remain unchanged barring special circumstances, and no one can tamper with it. A 2022 paper calls this both an advantage and a flaw. It is an advantage that the contract remains intact and transparent, and a flaw that security patches and the addition of features are blocked (DOI: 10.48550/arxiv.2206.00716, preprint).

Creators themselves cite these difficulties. They point out that there are no effective ways to guarantee the safety of smart contract code, and that development tools are still very rudimentary. This was confirmed by interviewing 20 developers and surveying 232 practitioners in 2019. The researchers also offer several directions for improving the development experience (DOI: 10.1109/tse.2019.2942301).

Because there is no human judge, mistakes left in the code are executed exactly as written, and code once posted cannot be easily fixed.

The Difference Between Having a Vulnerability and Being Drained

That is why finding vulnerabilities before deployment is so important. A code audit is the process of having humans or tools read the code to find vulnerabilities before deploying a contract to the ledger. Several automated tools exist to find vulnerabilities, and these tools produce different answers. This difference was revealed in a 2020 comparison where nine tools were run side by side in two experiments. It was a comparison that ran analyses a total of over 428,000 times (DOI: 10.1145/3377811.3380364).

The first experiment looks at what tools miss. When the tools were run on 69 contracts with pre-marked vulnerabilities, all nine tools combined caught 42% of the vulnerabilities. The single most accurate tool caught 27%. This means the tools missed more than half of the marked vulnerabilities.

The second experiment looks at where tools sound false alarms. When run on all 47,518 Ethereum contracts with open-source code, 97% were flagged as having vulnerabilities. The researchers interpreted this to mean that there are quite a few false alarms. The tools also did not agree well with each other. Vulnerabilities caught by four or more tools together were rare, and there were only two such types (DOI: 10.1145/3377811.3380364).

Using multiple tools does not guarantee peace of mind. Even when using ten widely used detection tools, known vulnerabilities still remain. A paper reporting this in 2020 warns that this gives a dangerously false sense of security, and offers recommendations along with future research directions (DOI: 10.1109/access.2020.2970495).

Instead of hunting for vulnerabilities, there is also a way to prove them. Formal verification is a method where the properties a code must uphold are written in the language of mathematics, and proofs are used to check whether the code maintains those properties. A 2019 survey reviewing 53 papers on smart contract security verification concludes that correctness verification relying on formal methods has become a more important and effective way to determine whether a contract is reliable and correct. This survey writes that its future is bright (DOI: 10.1109/access.2019.2921624).

Being flagged as having a vulnerability and actually being drained are different. When six academic studies tracked 23,327 contracts reported to have vulnerabilities, 1.98% were actually drained after deployment. Measured in money, the difference is even larger. The drained money did not exceed 0.27% of the funds locked in them. The researchers' explanation is as follows. Funds were heavily concentrated in a very few contracts, and those contracts were actually impossible to drain (arXiv:1902.06710, 2019 arXiv preprint).

However, that explanation does not cover cases where money is deposited into code with vulnerabilities. An incident where someone siphoned away funds at a 2016 gathering actually happened, and those funds only returned after a controversial vote that split the ledger. The losses caused by the Parity wallet hack were also real.

There is a gap between being flagged as having a vulnerability and actually being drained, and the tools that look for vulnerabilities also produce different answers.

If You Let People Fix It, People Will Fix It

Millions of dollars worth of funds are trapped in broken contracts. Humans make mistakes, technology advances, and flaws are discovered too late. This is why a way to modify deployed contracts became necessary, and contracts like these hold large amounts of money, making them targets for attack (DOI: 10.48550/arxiv.2304.03405, preprint survey).

The simplest path is to deploy a revised version as a new contract. This path is expensive. The cost of deploying the new version and the cost of clearing the old version add up. Because fixing is expensive, deploying it without flaws from the start costs less. This is why testing before deployment is essential, and various paths to assist with that testing have emerged (arXiv:2112.03426, preprint survey).

An upgradable contract is a contract structured so that the code detailing what it does can be swapped out even after deployment. The method commonly used is a proxy. A proxy keeps the deposited shares and records itself, while the code detailing what to do is brought from another contract and executed. Each contract has a unique address used to call it within the ledger, and users call the address of the proxy. If the proxy changes the code it fetches, the contract's actions change while this address remains the same. Structured this way, flaws discovered belatedly can be patched even after deployment.

From the user's side, this is also a risk. The method of changing a contract without changing its address allows someone to secretly change functions and cause users to lose money. A 2024 study thus reports that this method increases potential risks and invites user distrust, categorizing the motivations for upgrades to issue development recommendations (DOI: 10.1145/3643916.3644426).

Then who swaps out the code? In 2022, the proxy contracts found on Ethereum numbered 1,400,000. Counting only distinct ones among them, upgradable proxies numbered 8,225. Of those 8,225, roughly 50% had a single address held by a single key control the upgrade. This means that with just that one key, the code could be swapped out. Roughly 14% were controlled by multi-signature wallets as seen in "Where Are My Coins?", meaning wallets that move only when a set number out of multiple keys sign together. Even there, a small number of people could change the entire operation of the contract (DOI: 10.48550/arxiv.2206.00716, preprint).

Cases where powers left in the code, such as the authority to mint new tokens, block transfers, or withdraw funds, are used as an exit are examined separately in "A Rug Pull Is Not a Hack — It Is a Permission".

In contracts structured to be fixable, the person holding the key to fix them becomes a new place that must be trusted, and if they are left unfixable, there is no way to patch the flaws.

The Ledger Does Not Know the Outside World

"If A sends 10" is a matter inside the ledger, so the witnesses verify it themselves. "When the goods shipped to A arrive" is different. A smart contract cannot reach outside data on its own and must send and receive information with external data sources. An oracle is the party that gathers facts from outside the ledger and feeds them into the smart contract.

There is always the risk that an oracle may be corrupted, malicious, or provide inaccurate data. Several oracle designs have emerged to mitigate this risk, and a review comparing these trust mechanisms highlights open challenges (DOI: 10.1109/access.2020.2992698). While calculations inside the ledger are repeatedly checked by every witness, those calculations cannot verify whether the incoming outside news is correct. The moment you have to trust whoever tells you the price is explored further in "A Smart Contract Cannot See the Outside World".

Facts from outside the ledger must be brought in by someone, and the party bringing them in becomes a place where trust is required.

Though the Name Is a Contract

There were predictions that banks, lawyers, and courts would soon become unnecessary. Mass media and many tech articles portrayed smart contracts as unbiased, infallible programs that make, fulfill, and even enforce promises. In that picture, smart contracts are a technology that frees trading parties from the shackles of traditional legal and financial institutions. A 2017 legal paper compares these claims against market realities and blockchain's technical limits, concluding that smart contracts can hardly be viewed as such a semi-mythical technology (DOI: 10.1080/17579961.2017.1378468).

What legal scholars asked was whether smart contracts are a better solution to the problems contract law addresses. One research team’s answer is twofold. Smart contracts can open up new possibilities, significantly transform commerce, and demand new legal responses. Yet they do not push contract law aside. The researchers argue that following this reasoning reveals the role of contract law. That role is an institution that sets things right when something goes wrong. Thus, the research team concludes that rather than eliminating contract law, smart contracts illuminate that role even more brightly (DOI: 10.5040/9781509937059.ch-001, legal argument). Setting things right means, for example, making the party that broke a promise pay for damages, or sorting out the meaning of an agreement when a dispute arises over what was promised.

There are also arguments that start from how contracts are actually used in practice. People sometimes include clauses that will not be enforced, leave things intentionally vague, or deliberately choose not to enforce clauses that could be enforced. In these uses, a contract is less a document to be enforced in a courtroom than a social tool for managing mutual relationships. A 2017 paper criticizes smart contracts for relying on a thin and narrow understanding of what law does. The paper argues that the rigidity built into smart contracts by design can sever these social uses of law. While seeing features in smart contracts worth contributing to social justice and fairness, the author suggests that their social and relational context must be carefully considered when discussing, designing, and using them (DOI: 10.17351/ests2017.107). Code that executes strictly as written leaves no room to leave clauses vague or to let things slide even when enforcement is possible.

The friction between law and technology is also visible in practice. These self-executing and self-enforcing contracts could fundamentally change how legal practice is understood and operated. Yet smart contracts still remain within the boundaries of the general legal system. This is the judgment of a 2020 study compiling interviews with 30 literature, information technology, law, and industry experts (DOI: 10.1177/0268396220924669).

In the same study, while there were many cases testing possibilities, there were still very few instances of actual large-scale use. The researchers traced a primary reason for this slow diffusion to the mismatch between what the law demands and what information technology can do. The researchers pointed out 20 problems currently facing smart contracts and prescribed a fix for each. While viewing information systems research as playing an important role in advancing smart contracts, they note that management and organizational issues may continue to remain stumbling blocks (DOI: 10.1177/0268396220924669).

The literature in this section views smart contracts as failing to take parties outside the boundaries of the law. Among them, one research team concludes that smart contracts cannot take over the role of contract law in setting things right when things go wrong.

Putting a One-Line Promise On-Chain

Let us recall from "Where Are My Coins?" the person who split their coins across two places. This person makes a promise with A, and writes that promise into code to upload to the ledger. "If A sends 10, transfer the 5 I have deposited to A." This person deposits 5 into the contract, and pays a fee as the value to upload it.

When A sends 10, this transaction calls that line into action. The witnesses each run the code, produce the same answer because the input is the same, and agree on the result (DOI: 10.1109/access.2020.2992698). The 5 is transferred to A. As long as the uploaded code remains unchanged, this person cannot change their mind halfway through and back out (DOI: 10.1109/access.2019.2921624). Therefore, A does not need to separately trust whether this person will keep the promise. This is precisely the benefit mentioned earlier: making the promise kept.

Now suppose this person wrote the condition incorrectly. "If 10 is sent" was written as "If 1 is sent." Applying the definition that it executes exactly as written, the incorrectly written condition is also executed as is. The witnesses have no way of knowing that this person meant 10, so even if A sends 1, they transfer the 5 as written. Because the uploaded code cannot be changed, this loophole remains as it is (DOI: 10.48550/arxiv.2304.03405, preprint survey).

Once it is executed in that manner, there is no place within the code written by this person to revert the result. This scene cannot determine whether A will actually send 1. What can correct this matter from outside the code depends on the country and circumstances, so this article does not cover it. The tool comparison seen earlier and the 1.98% are the result of counting the types of loopholes that tools look for (DOI: 10.1145/3377811.3380364; arXiv:1902.06710). Those studies do not state whether tools catch such loopholes where the writer's intent and the written numbers diverge.

The next promise is about goods. This person decides to sell goods to A, and writes, "Transfer the 10 A has deposited to this person when the goods reach A." The 10 is inside the ledger, but whether the goods have arrived is an affair outside the ledger, so someone must feed in "arrived." If that oracle inputs false news, the witnesses have no way to verify that news, and the code transfers the 10 just as it came in. The risk that an oracle will feed in corrupted, malicious, or inaccurate data always exists (DOI: 10.1109/access.2020.2992698).

Finally, suppose this person discovers a loophole and wants to fix it. A fixed version can be newly uploaded, but uploading the new version and removing the old version cost fees together (arXiv:2112.03426), and A must also be informed where the new version is. If it was structured as a proxy from the start, only the code specifying the tasks can be swapped out to patch the loophole.

The question then is who holds the key to make the fixes. If this person holds it alone, it takes a shape similar to about 50% of the upgradable proxies counted in 2022. Even if this person holds multiple keys—like the multisig in "Where Are My Coins?"—all by themselves, from A's perspective it is the same as one person holding it. If they share the keys with a few other people via multisig, it takes a shape similar to about 14%. Even then, a mere handful of people can change the entire operation of the contract (DOI: 10.48550/arxiv.2206.00716, preprint). The party holding the key can change what the contract does while keeping the called address the same, and that change can result in a loss for the user (DOI: 10.1145/3643916.3644426). That key is both a way to patch loopholes and, at the same time, a new place where A must place their trust.

Gathering the scenes together, while no one holds the key to change the code, A does not need to separately trust that this person will not change their mind halfway. If this person holds the key to make fixes, A must trust precisely that very thing. What the witnesses guaranteed is that the code written at that time executes as written, and this was achieved without a middleman.

Instead, the two parties still had to rely on someone for what was written, who could change it, and what came in from the outside. Incorrectly written conditions can harm the writer, while the swappable key and incorrect outside news can harm A. The places where trust must be placed do not vanish; instead, they shift to the code, the person who wrote that code, the person holding the fix key, and the party bringing in outside news. This sentence is this article's synthesis of the preceding grounds.

Where to Look Next

With this piece, "Blockchain from Scratch" comes to an end. The six articles in the next bundle, "Things That Collapsed the Moment Money Was on the Line," assume you understand smart contracts and pick up right where various sections of this article leave off.

What the guarantee that code runs as written actually fails to guarantee is examined in "The Code Did Exactly What It Promised — What Algorithmic Stablecoins Guaranteed, and What They Could Not" (/articles/algorithmic-stablecoin-collapse). This is a case where the conditions written into the code to defend its own value operated exactly as intended, yet still collapsed.

When bringing in prices instead of items in a scene, the reality that you must trust whoever provides the price—whether it is brought in from outside the ledger or read from trades inside the ledger—is followed up in "A Smart Contract Cannot See the Outside World — The Moment You Have to Trust Whoever Tells It the Price" (/articles/defi-oracle-manipulation). A single paragraph on oracles in this article is the starting point for that piece.

The dual nature of permissions left in code—such as the power to mint new tokens, freeze transfers, or claw back funds—acting as an exit door, while those same permissions are also used for normal operations, is covered in "A Rug Pull Is Not a Hack — It Is a Permission" (/articles/rug-pull-anatomy).

When the guarantees that witnesses provided within a single ledger cross over between separate ledgers, it is examined in "A Bridge Does Not Inherit the Chain's Guarantees — Why Cross-Chain Bridges Keep Getting Drained" (/articles/cross-chain-bridge-hacks).

In an organization run by voting, much like that gathering in 2016, the act of buying the votes themselves to change the rules is tackled in "The Power to Change the Rules Is Also for Sale — When Governance Itself Becomes the Attack Surface" (/articles/dao-governance-attacks).

The design of moving execution outside the ledger to reduce the cost of every witness repeating the same calculations, along with the recurring question of who holds the key to fix things, is explored in "Is an L2 Really as Safe as Ethereum? — What a Rollup Inherits, and What It Does Not" (/articles/l2-rollup-security).

Source Papers

Preprints, surveys, legal arguments, and single studies state their grade or research design in the body.

• "Understanding a Revolutionary and Flawed Grand Experiment in Blockchain" (2018) — DOI: 10.4018/jcit.2019010102 — The DAO on Ethereum in the spring of 2016. Investors voted to fund ventures, and transactions executed autonomously. More than 50 million dollars out of 168 million dollars was drained, leading to a quick failure. The community voted to revert to the pre-hack state (a fork), returned funds to investors, and shut down the DAO. This could be seen as a bailout and arguably violated ledger immutability and the "code is law" ethos — an irony given that Bitcoin was born in backlash to the 2008 bank bailouts.
• "Formalizing and Securing Relationships on Public Networks" (1997) — DOI: 10.5210/fm.v2i9.548 — Smart contracts bind protocols and user interfaces together to formalize and protect relationships over a network. Relationships specifiable by algorithms, such as via cryptography, can be protected from party violations and third-party eavesdropping or interference, but only up to the limits of time, user interfaces, and the completeness of the algorithmic specification. Applications include credit, content rights, and payments.
• "Making Smart Contracts Smarter" (2016) — DOI: 10.1145/2976749.2978309 — Bitcoin and Ethereum support transaction processing rules and scripting functions, which evolved into smart contracts as full-fledged programs running on blockchains. Tens of thousands of contracts hold millions of dollars worth of value on Ethereum (abstract opening verified only).
• "Smart Contract Development: Challenges and Opportunities" (2019) — DOI: 10.1109/tse.2019.2942301 — The term originally referring generally to the automation of legal contracts is used for low-level code scripts on blockchains. An interview of 20 developers plus a survey of 232 practitioners found: no effective way to guarantee code safety, rudimentary tools, language and virtual machine limits, performance constrained by resources, and scarce online materials. Improvement directions are proposed.
• "Trustworthy Blockchain Oracles: Review, Comparison, and Open Research Challenges" (2020) — DOI: 10.1109/access.2020.2992698 — The essence of smart contracts is decentralized execution where all execution nodes trust and agree on the execution results. Unable to access external data on their own, oracles collect and feed data in. There is always a risk that oracles might feed corrupted, malicious, or inaccurate data. Trust characteristics are compared alongside open challenges.
• "A Survey on Security Verification of Blockchain Smart Contracts" (2019) — DOI: 10.1109/access.2019.2921624 — Because code executes, neither side can back down (trustless execution). Attacks cause massive losses. Surveying and classifying 54 related papers, it concludes that correctness verification leaning on formal methods has become a more important and effective method, with a bright future.
• "Smart Contracts and Decentralized Finance" (2023, survey) — DOI: 10.1146/annurev-financial-110921-022806 — Advantages such as overcoming the commitment problem, the difficulty of integrating external information and legal enforcement, and the absence of trusted intermediaries inflate implementation costs. An overview of DeFi applications is provided.
• "Formal Verification of Smart Contracts" (2016) — DOI: 10.1145/2993600.2993611 — Because of Ethereum's openness, programs and pseudonymous users can invoke public methods of other programs, dangerously entangling trusted and untrusted code, and writing secure contracts can be very difficult. The DAO attack probed subtle details of EVM semantics to transfer about 50 million dollars' worth of value.
• "Reentrancy Vulnerability in the Blockchain Ecosystem: Historical Attacks, Detection Approaches, and Mitigation Strategies" (2025) — DOI: 10.1109/netcrypt65877.2025.11102145 — Reentrancy is a vulnerability that allows a function to be called repeatedly before the first function call finishes. The 2016 DAO attack is the most infamous case. Detection and prevention techniques are discussed, concluding that mitigation is critical.
• "Smart Contract: Attacks and Protections" (2020) — DOI: 10.1109/access.2020.2970495 — Because of immutability, security patches cannot be applied after upload, demanding strong security strategies before deployment. The DAO and Parity wallet hacks caused millions in losses due to simple bugs. Four attack categories and seven major attack techniques are analyzed. Using 10 widely used detection tools leaves known vulnerabilities behind, giving a dangerous false sense of security. Recommendations and future research are discussed.
• "A Comprehensive Survey of Upgradeable Smart Contract Patterns" (2023, preprint) — DOI: 10.48550/arxiv.2304.03405 — Ethereum contracts cannot be changed once uploaded. Human error, technological evolution, and new vulnerabilities necessitate upgrades, holding large amounts of money and making them attack targets, with massive past losses and millions trapped in broken contracts. A catalog of proxy patterns is presented; among an analysis of roughly 100,000 verified contracts, about 70% of existing detections were false positives.
• "Not so immutable: Upgradeability of Smart Contracts on Ethereum" (2022, preprint) — DOI: 10.48550/arxiv.2206.00716 — Deployed contracts are expected to be immutable and tamper-proof under reasonable circumstances, which is both a benefit (integrity and transparency) and a drawback (blocking security patches and feature updates). Six upgrade patterns are analyzed. Out of 1.4 million proxies, 8,225 are uniquely upgradeable proxies, with about 50% controlled by a single EOA and about 14% by a multisig wallet, allowing a small minority to change the entire logic.
• "Empirical review of automated analysis tools on 47,587 Ethereum smart contracts" (2020) — DOI: 10.1145/3377811.3380364 — Nine automated analysis tools were applied to 69 annotated vulnerable contracts and 47,518 Etherscan source-public contracts (428,337 total analyses). Across the annotated vulnerability data, all tools combined caught 42%, with Mythril achieving the highest accuracy at 27%. On large data, 97% were flagged as vulnerable, implying significant false positives. Vulnerabilities caught simultaneously by four or more tools were rare and limited to two categories.
• "Smart Contract Vulnerabilities: Vulnerable Does Not Imply Exploited" (2019, arXiv public version v5) — arXiv:1902.06710 — Out of 23,327 vulnerable contracts reported by six academic studies, actual post-deployment exploitation was under 1.98%, accounting for no more than 0.27% of the 3 million ETH at stake. This is explained by funds being concentrated in a small number of contracts that cannot actually be exploited.
• "A Survey of Verification, Validation and Testing Solutions for Smart Contracts" (2021, preprint survey) — arXiv:2112.03426 — Unmodifiable after deployment, changes are possible only by deploying a new version, incurring costs for deploying new contracts and destroying old ones. Pre-deployment testing is thus essential. Solutions are classified into test networks, security analysis tools, emulators, and simulators, weighing their pros and cons.
• "The Sword of Damocles: Upgradeable Smart Contract in Ethereum" (2024) — DOI: 10.1145/3643916.3644426 — Upgrades that change contracts without changing addresses can covertly alter features and cause losses, heightening risk and breeding distrust. Using proxy detection (F1 99.37%), 126,500 upgradeable contracts were found in the first 12 million blocks. 64.3% of upgrades via the metamorphic approach were malicious MEV bots. Upgrade motivations are summarized along with development recommendations.
• "Smart contracts: terminology, technical limitations and real world complexity" (2017, legal) — DOI: 10.1080/17579961.2017.1378468 — Mass media and technical writings depict smart contracts as unbiased, infallible programs replacing banks, lawyers, and courts. Reviewing terminology, technical limitations, and legal constraints, it finds they are hard to view as a semi-mythical technology that liberates parties from the shackles of traditional legal and financial systems.
• "Contracts: Ex Machina" (2021, book chapter/legal) — DOI: 10.5040/9781509937059.ch-001 — Are smart contracts a better solution to problems addressed by contract law? While opening new possibilities, drastically altering commerce, and demanding new legal responses, they cannot replace contract law. The reasons reveal the essential role of contract law as a remedy system, and smart contracts illuminate that role rather than abolishing contract law.
• "Book-Smart, Not Street-Smart: Blockchain-Based Smart Contracts and The Social Workings of Law" (2017, law and society study) — DOI: 10.17351/ests2017.107 — While some features can contribute to social justice and fairness, they rely on a thin understanding of what law does. Three practices are examined: unenforceable clauses, intentionally vague clauses, and the non-enforcement of enforceable clauses. Design rigidity can sever the social utility of law, meaning social and relational contexts must be considered during discussion, development, and deployment.
• "Is code law? Current legal and technical adoption issues and remedies for blockchain-enabled smart contracts" (2020) — DOI: 10.1177/0268396220924669 — Literature review and interviews with 30 IT, legal, and industry experts. While feasibility tests are numerous, large-scale implementations are very few. The main cause of slow adoption is the mismatch between legal requirements and IT capabilities. Smart contracts remain bounded within the general legal system. Twenty problems across three levels and their prescriptions are discussed, noting that managerial and organizational issues may remain stumbling blocks.