not so perfect. But this happens, a lot. sometimes they don't even hide it. The defi degenerates call it 'rugging', eg: rug pull. Often its not even a hack, the contract has an administrative function that allows draining the contract.
That's an interesting point. I suppose we will find that any DeFi platform that survives for a decade or two will have some of the highest quality software in the world. It's survival of the fittest code.
That's how the coins themselves seem to be viewed to some extent as well.
Price of Bitcoin will continue to rise as each year people figure out that, if someone can hack wallets, they're not doing it widespread enough for it to be a concern to the average bear, pun intended.
I think the underlying protocols of the big name crypto like BTC, ETH, etc... are relatively robust - I don't think anyone is doubting those. I think the thing in doubt is the complex applications running in the application space of currencies that support such functionality. These applications can often be nearly as as the underlying protocol with much looser requirements around testing!
It really is a whole new class of software I think - trustless software that is also "open source" and holds billions of dollars of value is the sort of thing where formal proofiness starts to look reasonable.
When people think their support of crypto platforms will lead to them becoming rich off the crypto speculation, I'm sure they're getting more support than you'd expect.
The risk of events like this one is fundamental to DeFi right? How can people still think that it's the future? Or even remotely better than the banking system we currently have?
The ones that kill people or cause loss of value are, criminal and civil respectively. You go to court for them, and either go to jail or compensate the victim for their loss (or sometimes both, depending on the bug and the intent and actions around it).
It's just like how Younique is the future of beauty products. Those who profit the most from more people believing it do a very good job of convincing more people to believe it.
Do they "truly" believe it themselves, or are they just rational actors well aware that they lose a lot of money if people stop listening to them? No way to know.
We know from today's transactions that at least one individual had 4 billion dollars loaned out to a competing DeFi Project. That's very much putting your money where hype is.
I suggest the concept that the risk is fundamental to all systems of trade, fiat/government included. All suffer from theft by insiders as well as theft by outside attackers/exploiters.
Maybe that's vaguely true in the abstract but let's talk specifics.
If I have a balance on a DeFi platform, it's vulnerable to attacks like the one in the original article. If I have a balance in a bank, this isn't the case. The risks aren't the same at all. Not the same type of risk, not the same magnitude of risk.
DeFi allows for a lot of unique and flexible things...and people are re-discovering that writing bullet proof code in such an environment is really really hard. i.e. No training wheels and lots of footguns available
>How can people still think that it's the future?
I'd view these events more as growing pains of a complex technology rather than an indication that it has no future.
People are learning though. See Cardano and their choice of Haskell and emphasis on formal verification.
Quite. But what if you don't have access to trustworthy institutions? Or what if you need to coordinate between trustworthy institutions that either don't work together or don't share mutual trust? What if you distrust the very currency the institution does business with?
Your point is correct. If you trust the institutions all the way down, trustless is complicated and unnecessary. If you don't trust the institutions, what are your other options?
Did every dollar of the $130m come from people who had genuinely evaluated the code, or had most of it come from people who trusted the authors not to screw it up this time?
It sounds like people trusted CREAM with their money, and shouldn't have. Not as trustless as you might hope.
I agree with you. My comment is not advocating for any platform in particular, least of all Cream, i'm replying only to the notion that trustless is unnecessary.
The point of the zero trust model is that while you as a normal person may trust someone, everyone has the means to verify without having to trust it.
If the devs have written formal models for the system and verified that with a proof solver, you have a reasonable assurance the code matches the spec and that the spec is at least consistent with itself.
If the devs have Property Based Testing suites and fuzzing tools to automatically search for vulnerabilities in the code/spec or introduced via changes, you have reasonable assurances that the development process is thorough and likely won't haphazardly introduce a vulnerability in a change (and actively squash potential vulns that are discovered).
If open source security auditors (who's reputation is core to their business) regularly and publicly auditing the platform, you have reasonable assurances that on top of the code being reasonably secure, the spec itself doesn't have any glaring flaws in it.
If bug bounties have red teams regularly trying to discover exploits, you have additional assurance that if a bug exists, it'll likely be discovered, ethically reported, and resolved before being exploited.
Point being, zero trust isn't about not having trust, it's about not having blind trust. These should be the expectation for all high value software. We should be able to trust in the engineering of software systems like we trust in the engineering behind buildings and bridges.
---
Now with regard to this specific hack, CreamFi failed to do 2 out of the 4 of those things mentioned above and their security auditor only provided a very cursory/high level audit. Their report was not confidence inspiring and should have been a red flag to users to not use the service.
Now compare this with the org they forked their code off of. Compound Finance maintains a formal spec, uses formal methods, has a bug bounty, and receives regular, in depth security audits. CreamFi chose to make changes to a codebase after abandoning the security tooling (formal spec was no longer maintained) and protections that were in place with Compound Finance's code.
Any moderately competent technical user should have been able to tell that CreamFi was (like many other knock-off DeFi platforms) a ticking time bomb. We as a software engineering community however still have a long way to go in making these qualities/flags accessible to normal users.
I guess I'm just not sure how that's different from trusting banks on the basis that they have auditing and reporting requirements, governance regimes, and legal oversight.
I understand the practical argument (code is easier to audit and more reliable), I'm just not sure how the sum total of the ecosystem is better when, as a practical matter, crappy smart contracts keep losing depositors' money, and depositors keep trusting the wrong contracts.
For developed nations, we'll see Central Bank Digital Currencies slowly replace the existing financial network. You can still get your flexible monetary policy, regulatory compliance, and reversible transactions with a CBDC. The additional benefit is that now instead of having a bunch of centralised, discontiguous, and opaque services for transferring funds, now you have a decentralised, unified, and transparent network for doing this. Additionally, smart contract or smart validator functionality allows you to move some of the traditionally centralised financial logic up into this transparent & decentralised space while still maintaining all the legal protections you'd have otherwise.
Side note: I say decentralised here because ideally CBDCs will use some Proof of Authority system with the various states/provinces/counties/parishes/districts/etc each running validators. The idea here being that you still retain full control by the nation however it now becomes exceedingly difficult for any one person to manipulate the network without the consent/awareness of many other officials.
Now how about developing nations? Many of these nations lack a stable or trusted financial sector. Their people don't trust the officials, the offices, or the policies. These people are the main users of the truly decentralised networks. Of course the risk of crappy smart contracts losing your money is a risk (and assurance/accreditation programs are working to improve the visibility of well designed & operated contracts). The question however is whether that risk is greater or lesser than the risks or costs of using traditional financial institutions in these regions (if the people can even get access to them).
That said I just don't see a lot of the value in a lot of "DeFi" at the moment. A lot of it exists solely as vehicles to allow people to move more money around at a time so that they can take bigger leveraged risks on the market. Now there are useful applications in the space however many are still small and finding their footing.
The majority of supply chain/production traceability solutions and identity solutions in the space are really just two sides of the same coin and serve the purpose of providing a decentralised (or at minimum federated) source of reputation for people and businesses where the local government fails to. Identity solutions provide a means for people in these nations to "prove" their credentials/reputation to gain access to low-to-reasonable interest rate loans or prove their credentials to potential employers. Likewise they provide a means for businesses to provide a history for their products which helps them sell their products at closer to the international market rate (compared to being forced to sell to the big corporation in their region that turns around and resells to the rest of the world).
Lending and Micro-lending platforms provide a means for people in these regions to get access to loans (denominated in their local currency) at rates they would otherwise not be able to get access to. People or organisations in higher QoL/CoL nations/regions can provide liquidity to these services and users in these developing regions can slowly get access to larger & lower interest loans over time by building up their "credit history"/reputation tied to their identity. In developed nations we have systems for this already but many developing nations lack such a service that is accessible to many of their people (and that is trusted). These services still have a long way to go but as the previously mentioned digital identity solutions become more available, this space should start to see some significant improvements in usability & trust.
I'll stop at that because I've already gone way past what I intended to write up (I was also considering going into detail about decentralised good & services marketplaces) but my poin...
Yep however I don't think I'd consider it to quite the same extreme. No doubt it was bad however proportionally to the size of the platform Cream's exploit was far more damaging. Like the rekt.news post mentions, it was more of a banking/spec error than an outright vulnerability. Your spec can't protect you if the loss is due to intended behaviour. There are ways to mitigate this however. The main way is by making your spec concise and clearly representable as a series of state transitions & operations or as a series of transformations.
The Compound Finance paper spec essentially just lists "this subsystem does these things" and then each function/operation is a list of preconditions, what actions are taken in what conditions, and the expected result. This isn't bad per se but it's not great either. Instead the paper spec really should be showing what transformation is being applied to the state, why we want that transformation applied, what properties must hold throughout the transformation, and then demonstrating that those properties hold.
The first just describes the system and then asserts preconditions hold which works well enough for verifying that the code matches the spec but the other actually verify that the spec is doing what the user & developer expect it to by formalising the system and analysing the properties of that system.
Compound's project wouldn't have been vulnerable to any of the attacks executed on CreamFi however they are vulnerable to the class of spec errors. Uniswap and Djed on the other hand would be protected from the majority of that class of issue that Compound experienced. This isn't to say that they are invulnerable but I'd be willing to say that they are approaching "cryptography-grade" security where you can trust these protocols just like you can trust AES, RSA, and ECC encryption & signing.
---
This of course isn't to say that what Compound does is bad but as that incident shows, there is still room for their improvement in the security space. Cryptocurrency and "Decentralised Finance" are finally starting to grow up into proper subsets of the cryptocurrency and game theory communities. Now this might be a bit of general commentary on the SW space but hopefully long term this trend causes some of this security minded design to bleed over into the greater software engineering community.
Formal Verification absolutely would have helped in this case. CreamFi abandoned the formal spec that Compound Finance used when they forked their code base. Had they maintained the spec and paid attention to the constraints that this spec imposes, the devs would have been aware that some of the tokens added to the platform would open them up to this attack. Had they maintained the standard, they would have been aware of this and could have notified the listing committee about this prior to the listing of these tokens. Doubly so because both currently and in the previous governance epoch the committee had members of the CreamFi team on it.
Well the limitation of a spec ultimately is that they are only correct provided you follow the constraints the spec itself puts on the system. In that sense a formal spec is three parts.
1. A definition of the constraints of the system. These constraints are "outside" the system and if they are violated, the properties of the system will not hold. This part boils down to clear and dis-ambiguous documentation on the constraints of the system as well as some tooling to help verify the constraints are held (not always possible).
2. A definition of the system itself. This defines the rules and operations within the system as well as formal methods to prove the correctness of this system. Provided this definition is shown to be consistent, as long as the constraints (part 1) are held true, the system is secure.
3. The code itself. Projects have to choose between either writing the code and using formal methods to verify functional equivalence between the code and the system (faster but harder) or using a code generator to produce a runtime directly generated from the system definition.
---
The code (part 3) is only secure if there's a full one to one map between it and the system definition(part 2). The system definition (part 2) is only secure if all the constraints (part 1) are upheld. You can verify parts 2 and 3 automatically but in many cases you won't be able to verify all of part 1 automatically.
This attack relied on the fact that one of the tokens was atomically volatile (allowing the attacker to manipulate funds in a single atomic step increasing the price up to whatever price and risking nothing if they are unsuccessful). The previous exploit was due to the listing of another liquidity pool token that allowed reentrancy. This allowed the two pools to repeatedly interact with each other inside of each other's code bypassing various state checks.
CreamFi failed in two places. One the devs stopped maintaining the spec after forking the protocol off the original Compound Finance protocol so even if they had held the constraints, they had added features that haven't been considered with regard to the formal security of the system. Two (and more importantly) the listing committee (responsible for introducing new tokens) wasn't aware of the constraints of the system.
Things formal verification will not do: fix Poorly conceived business rules, prevent confusing UI, quickly modify code to adapt to rapidly changing circumstances, etc…
One could formally verify that if the account number is set in the wash account (plus like six other places) then the loan won’t be repaid due to programming errors. But formal verification doesn’t tell one that the UI is garbage and hard to know that the account number needs entered in six places to get the correct formally verified action to occur instead of the other formally verified action that repays the loan in full.
Plenty of asset classes exist with fundamental risks.
The risk of investing in stocks is always that the underlying companies could have their business ruined overnight for any reason. The risk of swaps is always that the counterparty could go bust and be unable to pay you even if your bet pays off (see Lehman Brothers). The risk of leveraged futures positions is you can get liquidated on fat finger trades or flash crashes. The risk of structured credit products like CLOs or mortgage backed securities is that the pool is fraudulent. The risk of many quant strategies is that the correlations go to one and your capital gets wiped out as your hedges fail to protect you.
Do any of these risks mean those asset classes are doomed? No, all of the above asset classes are bigger than ever. Markets can and do live with disastrous risk looming over their heads all the time. Unless your name is Nassim Taleb, the reality is that you mitigate the risks you can, model out the risks that you cannot, then price the asset accordingly. The foundation of modern finance is “we don’t have to live in mortal fear of risk if we’re smart about it”
If inherent risk was an insurmountable barrier to the existence of a financial product, then I guarantee you the financial system would just be the old-timely community bankers like in It’s a Wonderful Life.
No banking system has the type of risks DeFi has. Saying that they have some other risks is just a long way to change the topic and it doesn't answer any of the questions around DeFi.
Many quant funds have similar “gap to zero” risks like DeFi. Many swaps desks at bulge bracket banks have “gap to zero” risk. Many derivatives strategies actually have “gap beyond zero” risk, as in you can lose more than 100% of your investment.
All of these systems are complex black boxes, for which the full risk profile can never be fully known let alone eliminated. Yet all of these asset classes continue to reach record size. For the foreseeable future, risk is not a meaningful constraint on financial activity or the growth of any otherwise profitable sector.
Global capital is insanely hungry for yield. It’s willing to accept very large, outsized risks as long as returns are attractive. DeFi continues to grow because it offers significantly higher top-line returns than traditional products. As long as that continues to be true, investors will stomach, and in many cases outright ignore, the risks.
Not a hack, in the sense of breaking/bypassing security. Each step in the chain of transactions appears to have been a legitimate transaction. It seems more like market manipulation.
I'm not sure if that makes it better (no security was broken) or worse (these markets are highly susceptible to manipulation)
This is not a cyberattack hack. It is just someone cleverly exploiting loopholes. The same happened to Ethereum at launch where they had to renege on their "promise" of (not-so-)smart contracts and create a fork.
From the article:
C.R.E.A.M. was targeted by what is known as a flash loan attack. Flash loans are uncollateralized cryptocurrency loans structured so that they must be paid back instantly using smart contracts, making them attractive for things like arbitrage across exchanges. If the loan isn’t paid back, then it never happens, because both occur in the same transaction.
Analysts on social media who pored over the details of the attack suggested that the hacker exploited C.R.E.A.M. in an incredibly complex transaction for a flash loan that ultimately allowed the hacker to drain C.R.E.A.M.’s Ethereum-based lending pools, leading to a gain of around $130 million in different tokens. The attack cost the hacker roughly 9 ETH in network fees, or around $36,000.
Sure sounds like fraud to me, but even if technically not, I’m happy to have more public examples on display for regulators to demonstrate their need for tighter regulatory authority (and legislation) around crypto.
Pretty big deal at the time, there's a lot of write-ups, just google "DAO hack" [1]
[edit] tl;dr: it's the reason there's now an Ethereum Classic, and we learned that Code is Law and trustlessness only applies to grandma's savings, not Vitaliks.
Yep. Legal jargon IRL is about as close as you get IRL to "code", with roughly 1,000 years of legal development underlying common law and modern legal systems to inform a style of language that is practically its own dialect.
Quite a bit of it has developed over the centuries in an effort to eliminate potential ambiguities in things like contracts so there would be no question about how the legal instrument should be executed.
This is why, to the butt of many jokes & frustrations, legalese is so extremely verbose & dense. Eliminating ambiguities or unintentional side effects or loopholes is extremely difficult.
Code appears to be little different in this respect: Implementing code that effectively says "don't manipulate the market in a way that makes us lose $millions" is not a straightforward task.
> This is not a cyberattack hack. It is just someone cleverly exploiting loopholes.
Could you not use the same exact description of anyone exploiting bugs in software to gain access to a system?
I believe there is actually a case making its way through the courts as we speak where someone is making the case that "code is law" is binding and should be able to keep the proceeds of his "loophole exploitation." Personally I'm with him haha. Sow -> Reap. [1]
> Could you not use the same exact description of anyone exploiting bugs in software to gain access to a system?
In this case, the trade didn’t even violate the intended behavior of systems involved. It’s not like a bug which results in a system operating differently than intended. The system operated exactly as intended, but their intended system design was obviously flawed.
An analogy to traditional finance might be something like a short squeeze, where a sufficiently capitalized counterparty can blow up the trade and extract money from someone else if (and only if) they can pump enough capital into the system.
The difference with smart contracts is that an attacker doesn’t need to have the capital to execute the trade. They can secure a “flash loan” that is conditional on the trade working out, otherwise the loan never happens. That’s why the attacker was able to pump $500 million into the play without ever taking ownership of the $500 million or even putting it at risk. The flash loan only occurred in the context of the trade, but it was open and closed as part of the complex contract. The attacker only had to pay transaction fees to push the contract through.
You can say about every bug (unless it is literally a bug flying inside the computer where the word comes from) "the system operated exactly as intended, but their intended system design was obviously flawed"
They clearly did NOT intended to give the coins away. Or if you argue they do any OS had any remote code execution attack also intended.
> They clearly did NOT intended to give the coins away.
They designed a cryptocurrency with a floating value that went up or down according to certain rules. Someone read these rules carefully and then borrowed billions of dollars of capital to play the game, according to the rules, in a way that moved the value in their favor.
This isn't like a remote code execution attack because OS designers aren't planning features that allow unauthorized remote code execution.
This is more like an options trade that didn't work out because someone with more money used their capital to blow up the trade. You can't make a bad trade in the stock market and then argue that your loss was a "bug" because you intended to make money, not lose money.
I like your line of reasoning, however, apparently the mechanism the attacker used was patched. According to your logic, this is the fundamental design of the system, and should be impossible to patch. That makes me more inclined toward the belief that this was a bug in their code.
The patch changed the design of the system. They obviously didn't forsee the flaw in their system but it's not like someone found a buffer overflow - they only used the levers and buttons that the system provided them to perform this 'attack'.
If u take money from an open bank door, u aint gonna be waved off with a laugh and good day. Just because u picked the lock using the mechanisms provided, doesnt mean u didnt steal the bounty.
Incorrect. A buff we overrun injects new code into the system that gets executed that was never part of the original system.
This is more like setting your screensaver or debugger to cmd.exe on windows NT and waiting for an admin process to crash or the screensaver to start. (I forget exactly how it worked)
I’d compare this “exploit” to playing a coin pusher type gaming kiosk with an especially large bankroll and statistical analysis to determine optimal play strategy.
If someone chose to play such a game intending to win and with appropriate planning to ensure wins through optimal play, I wouldn’t call that an exploit at all. It’s beating the game, and the owner may ban you from playing it, but no laws were broken by you playing it in such a manner with larger than average capital. But your winnings are yours, fair and square.
The subjective element to legal interpretation is why our legal system is not purely algorithmic.
If it was, people will argue malicious compliance like you are, but intent has to be considered, both the intent of the developer and the intent of the exploiter (or loaner, is maybe a less loaded term for them)
“Someone read the rules carefully, then borrowed capital to move the rules in their favor”, you could say the same thing about an integer overflow, both are attacks of excess, with intent for massive personal gain, outside the intended use case of the system
> This is more like an options trade that didn't work out because someone with more money used their capital to blow up the trade. You can't make a bad trade in the stock market and then argue that your loss was a "bug" because you intended to make money, not lose money.
100% Agree you can also look up trading patterns on option expiration Fridays to see people making sure that their trades 'work out'
I'm not so sure. Contract law is complex and even if the software is considered a legal contract, the law doesn't always side with pure technicality. For example if a contract indicated that John Doe must pay me $100 for services rendered and then the time to pay up arrives and Jon claims he doesn't have to pay because the contract says John must pay. But he's not John, he's actually Jon. That isn't going to fly because the intent that Jon pay is clear.
> They clearly did NOT intended to give the coins away.
I frequently make decisions that don’t turn out as I intended. You need a distinction between whether the outcome is what you intended and whether the process is what you intended. It isn’t a clear line.
> their intended system design was obviously flawed
No, the design was so complex that its flaws were well hidden, and therefore not intended.
Quoting C. A. R. Hoare:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
> No, the design was so complex that its flaws were well hidden, and therefore not intended.
That’s no less true for a Chrome sandbox escape.
In fact, this Ethereum loan platform’s behavior is encoded in program source codes, just like Chrome. One expects that some exploitable issues in the Chromium code arise not from syntactical but conceptual errors. The code could match a mistaken programmer intent, and this often happens.
Even if this is true, what in the world is the point of crypto platforms if courts need to step in and decide intent whenever someone doesn't like the outcome of a transaction?
It is the wet dream that some 100 line script will eventually become the only and unbiased arbiter and judge of anything in the world of finance.
You are probably reading this comment and thinking "yeah, hah, naive fools". About as naive as the fools, that believe in a 100 line program, that gives you a puzzle that nothing will realistically ever be able to solve, yet the program could tell immediately if the solution is wrong or right.
The difference, I think, is that builders of other systems usually don't say "We don't need law enforcement to tell our users what they can and cannot do, because what is allowed is clearly written in code, and the code triumphs everything else. That's the major selling point of our system."
No, you can't say that about every bug. Many bugs occur in the implementation of systems, not in the design. That was not the case here. The system was implemented as designed.
No, intent is not law. You can’t make a stock trade, lose money, and then sue the counter party because your intent was to make money. Accidentally killing someone can still be a crime even if you didn't intend to kill them. Intent plays a role in deciding outcomes and can influence the judgment, but intent doesn't overrule or negate law.
And that’s basically what happened here: Someone read the fine print of the trading platform and realized they could use a flash loan to push the system into a space where the trade would default and the attacker would profit. So they pressed the button and the system worked as designed.
So the way to fix this is to do what banks and stock exchanges do. Operate under a regulatory framework that has defined legal precedence to avoid someone take advantage of an unintended loophole. But at that point you are defeating the whole point of crypto being decentralized and permissionless.
Isn't the entire $GME thing an example where someone took advantage of a situation where counterparties got way out over their skis and buyers of $GME profited well in excess of any reasonable estimation of Gamestop's promise of business results via what amounts to an unintended loophole?
There is no bounded 'reasonable' estimation or expectations of how much money you can gain/lose by trading options. They are a force multiplier that can explode very spectacularly, in many different ways, and everyone involved in finance understands that.
If you want your gains/losses to be reasonably bound, you have to limit yourself to buying and selling stocks directly. Unfortunately, there's not enough money in that to make a living day-trading.
The bug that allowed that to happen has essentially been patched. (Risk analysis that didn’t take into account Robinhood giving immediate margin to any rando that signs up). Robinhood very nearly melted down, Lehman Brothers style.
No one ever entered into any agreement where they were expected to buy stocks at reasonable prices.
It is like when Kim Kardashian gets paid 50M for a 30 second add on Instagram. I may think that is unreasonable, but I don't have any contract with anyone implying that she be paid a standard actor's wage.
Doesn't your worldview make smart contracts pointless to begin with?
If your plan is to rely on the court system, then just rely on the court system. You can write your contract on paper; smart contracts serve no purpose whatsoever then.
Smart contracts are the executor, for example, imagine a smart will. It would hand out an estate in eth automatically upon death.
But just as in real life, an executor can make mistakes.
Traditionally, a judge may return or redistribute assets in such a case. Or claim the will was not interpreted correctly. In such cases, determining the intent of the contract is the goal of the court.
Like it or not, smart contracts are not immune to contract law, civil law, courts.
The first court cases, which will undoubtedly happen, will be very interesting.
And moreso, different legal jurisdictions will interpret things differently. If I was writing smart contracts, I'd want some sort of boilerplate, insisting upon legal jurisdiction, maybe like an open source license, but for smart contracts.
After all, once your identity is known, normal courts can compel you to do things...
Intent is literally the heart of criminal law. You have to have intended a crime for it to be a criminal act. In this context, this means that you had to intend to do things that would legally constitute a crime, even if you did not know that the actions/result would be a crime. For some crimes, specific intent is not required for all of the factors (for example, for statutory rape, you do not need to have intended or even known that the other person was underage; for many manslaughter charges you do not have to have intended to kill someone so long as you intended to do things that could reasonably have been expected to cause someone's death).
Intent is also a fundamental factor in tort law, where intentional acts can literally quadruple the amount of damages the plaintiff may receive.
And in contract law, intent is a basic foundational element of a contract. And indeed, a number of contractual disputes arise over one party intending to make money, not actually making money, and suing their counter-party as a result. And many times, the plaintiff wins...
This situation is probably governed by contract law. Since those disputes turn entirely on the specific facts proving or disproving mutual intent, it's hard to say who would win in this dispute since only a small subset of the relevant facts are publicly known.
it is literally not. Though it is a requirement of some crimes.
> You have to have intended a crime for it to be a criminal act.
No, you don't, in general. You have to have intended a particular outcome if the particular crime requires that, but plenty of crimes do not have such requirements (or specifically do not apply if intent is present). E.g., “depraved heart” murder, involuntary manslaughter, and any strict liability crime or crime of negligence or recklessness.
Even if intent isn’t written into a specific law, the whole system is built to specifically allow intent to be considered in so many stages. Sometimes they don’t even decide to prosecute.
Laws exists specifically to create a functioning society. Laws do not exist for the sake of having laws. Any sane person enforcing any kind of rule understands this.
This take is like programmers getting angry when businesses don’t care about the quality the the code or something, forgetting that the whole reason people hire programmers is to solve business problems, not to write text on a computer. Total miss of the point of the exercise.
> Even if intent isn’t written into a specific law, the whole system is built to specifically allow intent to be considered in so many stages.
Mental state (which is much broader than intent, though intent is an aspect of it) is an important consideration for criminal law and most offenses have a required mental state (strict liability offenses are a small minority). And mental state is, yes, considered broadly beyond the formal requirements, too.
But to say that “intent is literally the heart of criminal law” is both literally false and substantively misleading.
> Accidentally killing someone can still be a crime even if you didn't intend to kill them.
Maybe, but the crime wouldn't be first degree murder.
Try googling "mens rea"; e.g.:
"A mens rea refers to the state of mind statutorily required in order to convict a particular defendant of a particular crime. See, e.g. Staples v. United States, 511 US 600 (1994). Establishing the mens rea of an offender is usually necessary to prove guilt in a criminal trial. The prosecution typically must prove beyond reasonable doubt that the defendant committed the offense with a culpable state of mind." [0]
> "The felony murder rule is an exception to the normal rules of homicide."
Whether or not one accepts that use of “normal”, it remains a rule and the claim that murder without specific intent is categorically not first degree, even in broad general terms is false (even before looking into all the variations in specific statutory schemes in the US, which really frustrate this kind of generalization, which takes common law rules and overgeneralizes the way things that are not part of the common law are mapped on to it.)
I was trying to respond to the claim that "intent is not law." Your point is valid but irrelevant. Even if intent to kill is not required in all cases to get a conviction for first degree murder, under the felony murder rule it is still necessary to prove intent to commit the original crime.
I think what you mean to say is that interpretation is law. Without interpretation by some (vested) third party with power, a law can never truly be enforced.
1. Someone locking themselves in a dark (usually smoky) room with someone in a button down shirt (with rolled up sleeves) standing over their shoulder.
Even better with an animation of bills flying from one account to the other in the background and/or a laughing skull on the computer of the person being hacked
I submitted We're In as a trope to TVTropes with Theo clickity-clicking in Die Hard as the example. But it got dinged because of the hard rule against the trope namer quoting script. So I resubmitted it as I Wasn't Before But I Sure As Hell Am Now and still no go.
Also needs someone with a stopwatch shouting “60 seconds…50 seconds…”. Ideally a blonde with large shoulder pads, but could be the second character in item 1.
This could be very interesting. The argument that "you put your money behind a pickable lock so you gave permission to anyone with lock-picking skills to take it" is a classic immature and self-serving understanding of the law, but in this case the system was built with the declared intention of creating a space where that logic applies.
How do you appeal to the courts after doing business under an explicit shared understanding that the courts are unnecessary and irrelevant? It will be difficult to prove that you had any expectation of the other party obeying any norms other than doing everything within its technical power to benefit from the transactions.
For my part, you can't declare "we're building this outside of the bounds of the legal system, but we're going to lean on that self-same legal system when it fails".
You have to pick between outside and inside the law.
But you seem to be picking whatever is your least favorite defense of blockchain tech from Twitter and declaring that it's the only "purpose" of the whole category of technologies. This is just as preposterous as saying "locks are built with the declared intention of protecting private property without any government protection of property, therefore if someone breaks your lock and steals your stuff you can't just go to the police and expect them to help."
Which country’s court do you appeal to? Does the transaction take place where either or both parties are? Or where the server is? What if the server DB is in one country, the outward-facing API is in another, and the actual transaction API in another? Yikes.
my recollection is that illegal contracts are invalid and do not override the rule of law. you and I can sign a paper which says 'we agree not to be held accountable to US law'; but because that contract is illegal (you cannot just declare yourself to be immune to law), our subsequent actions are still accountable to US law. you could mug me the second after I sign that paper, and that would still be illegal.
Could you not make an argument that you're merely taking people up on their offer to the letter, making the earnings essentially an expensive bug bounty?
>"code is law" is binding and should be able to keep the proceeds of his "loophole exploitation." Personally I'm with him haha. Sow -> Reap.
i feel that there is a case of false advertising somewhere here. The classic finance system doesn't advertise "code is law" as a feature, and thus easily claws back accidentally transferred into your account $1B. The Ethereum based crypto and the likes are heavily promoting the "code is law" feature, and thus their readiness and attempts to back off from it anytime the things not going their way suggests false advertising and intentional, at this point giving the history, misleading of the users/customers.
Wrt. the original post - it is pretty surreal, users just borrow and mint $500M-2B in a transaction. The crypto proponents tear at Fed for printing money. Yet even the Fed and WallStreet rarely do $2B flash transaction, and not on a whim by some passer-by Shmoe user. The crypto is really democratizing/distributing and multiplying the financial madness that previously was limited to the exclusive club of big money. I have hard time to see how that is any good, and the wolves of crypto look to me much worse than the wolves of the WallStreet.
The wolves of wall street know they're doing something bad and at minimum try to avoid getting caught, the wolves of crypto will tell you its fabulous medicine that'll save you from the big bad fed while simultaneously screwing you from all sides.
The promise of smart contracts is "programmable money". Humans use money to interact with each other. When money becomes software, then you can create new and unique methods of transacting/interacting.
This word to describe software settling monetary transactions is actually a bad choice and oversells what Ethereum actually can provide. A better term would be a financial vending machine.
On chain EVM transactions are essentially just stupid scripts that act according to the same simple, deterministic roles every time you put money into it. The end result is always either you gaining or losing money (but return some other form of “value” like a chocolate bar from a vending machine) by means of a transaction between two people that do not need to know i.e. “trust” each other.
While it certainly does not redefine civil law, a vending machine — if well designed — can enforce compliance with the law without requiring a middle man like a bank or a lawyer.
As every programmer can testify, however, even simple programs can exhibit fairly complex behavior and that’s often impossible to fully predict by static analysis alone.
Still „virtual financial vending machines“ (it’s not as catchy as “smart contracts”) have a huge potential to disrupt the banking and financial services sector.
One definition of "hack", close to the earliest sense of the word, is "to use something in a way it was not intended when it was made". This was definitely not the way the creators of the platform intended it to be used.
Whether it qualifies underall all common senses of "hack" is debatable, but it at least qualifies under a common sense of the word.
"Ugly and imaginative solutions have something in common: they both break the rules. And there is a gradual continuum between rule breaking that's merely ugly (using duct tape to attach something to your bike) and rule breaking that is brilliantly imaginative (discarding Euclidean space)."
> This was definitely not the way the creators of the platform intended it to be used.
This question might be getting way too philosophical or abstract, but would the following statement be fair:
"If something is designed, its design is intentional."
That isn't to say, a thing that is designed can't have flaws, but, if it was created to process things in a predetermined series of events, isn't that how it's supposed to work? If someone is able to exploit the layout of that design - a flaw of logic, not of security - it seems weird to think that the act of someone using it would be considered unintended, you know? I feel like a lack of planning or thought by the designer doesn't necessarily put any responsibility on the user.
Again, might be more of a debate around the concept of design...it's just a weird thing to consider something like, "Yes, the platform was built to do that, but you weren't expected to use the platform to do that!"
For the Ethereum attack that's similar to the CREAM attack, are you referring to the DAO attack, or something else? Can you please share some links on that incident?
> This is not a cyberattack hack. It is just someone cleverly exploiting loopholes.
Well, while the attacker did not exploit a bug inside the lending protocol code per se that person surely relied on a design flaw. Basically, what successful flash loan attacks do is to manipulate the price of an asset inside a „liquidity pool“ of a single „distributed exchange“ (DEX) temporarily to a much lower value and then buy off this asset cheaply and sell it on another DEX for profit.
To protect itself from a flash loan attack, a DEX protocol should use an external „oracle“ to determine the price of an asset instead of relying on the „in-house price“ (in lieu of a better word). C.R.E.A.M. does not seem to do this. This is clearly a flaw in its pricing model.
As someone paying a six figure invoice to have their project audited right now, it's really not that simple.
Do audited projects get hacked? Yes, absolutely. Is a clean audit report mean a project is bullet proof. Definitely not, especially if it's not from a top-tier firm. But an audit will definitely catch any of the common exploits that are easy to make, like this protocol doesn't check to make sure that the caller is not currently inside another transaction in the contract.
All in all, an unaudited protocol has at least an order of magnitude higher risk than one audited by a reputable firm. Ignoring audits altogether would be like refusing to lock your doors, because you heard about a house that still get robbed when the front door was locked.
Can you explain how it is not more simple than running open source tooling and copy pasting the results? I am yet to see an 'audit report' that is more than just this. Its checkbox compliance. Are you paying six figures for this?
I agree that unaudited is worse. But what are you actually paying for with these clowns?
There are plenty of audit companies that do a in-depth review of the code, a review of the protocol itself, etc., and come up with questions trying to understand the various execution flows. This goes beyond what current tools can do, it acts as a second pair of eyes to read through and understand all of the smart contracts.
We've also paid for an audit from a leading company recently. You paying for a team of smart people to spend a couple weeks trying to break your system. It's not going to find everything, but everything that is found is a way that can't be attacked anymore.
There's the Swiss cheese theory of accidents. Each layer may have holes in it, but by having enough layers and aggressively trying to shrink the number and size of holes in each layer, you can get much more secure.
External audits by good teams are a good layer, but neither they, nor any other individual layer is a silver bullet. Good audits do provide a lot of value.
This would have likely been caught in a standard audit. Flashloan attacks are incredibly well known and any auditor worth their salt will examine those scenarios
Yeah, just like the thousand other times. These kinds of attacks rely on contract state and unbalance of tokens. They are quite difficult to detect statically.
You are correct that flash loans are a part of the standard attack toolbox.
This was not a standard attack though. It was a genuinely new attack vector that's not been seen before. Flash loan was just one hammer in the attacks toolbox.
Remember anything a flashloan can do, a whale can do too.
There are some brilliant people out there. I have no doubt solidity experts can spot vulns by inspection. My point is that auditing is necessary but not sufficient.
Its a greater issue in security where audits and testing can lead one into a false sense of security, 'because it is audited'.
The original post was saying all the hacked contracts were 'unaudited'. While this is true, I am arguing that in nearly every case, the audit would just be a copy paste of the same data the solidity developer would see when they ran the open source tooling.
"I am arguing that in nearly every case, the audit would just be a copy paste of the same data the solidity developer would see when they ran the open source tooling."
That's not been my experience with good audits. Automated tooling only gets you so far. We use open source automated security tooling, unit tests, and and some formal proving, and audits have found things these didn't.
Thank you for sharing! I agree that OZ and ToB are the best in this space. They write the open source tooling, and I am sure they have some really good inhouse tools too.
Their findings are very valuable, could potentially have saved million of user AUM/TVL. Sincerely, Best of luck with Origin!
Interestingly the project was audited but the audit was very surface level and basically concluded with "the code is derived from another project and doesn't have any glaring flaws however the project itself lacks decentralisation in its oracle setup and lacks a formal spec which limits further auditability".
It's not "incredibly complex". Someone just laundered the magic beans through a series of intermediate cryptocurrencies until they got to one they could just conjure out of thin air. You know, like Tether.
It's a bit more complicated than that, at least if I'm understanding the write-up correctly. The underlying trick is that they reduced the amount of yUSDVault shares by redeeming most of them, then doubled the value of each by gifting more of the underlying yUSD to the contract. This in itself didn't conjure anything from nothing - each yUSDVault share was genuinely worth double the yUSD as before. The trouble is that due to some fundamental design flaws in C.R.E.A.M., this meant that a much larger Cream USD holding in one account and an offsetting debt in a second were now instantly worth double what they were before. The debt was then worth more than the collateral and could just be walked away from, whilst the other account had a profit which could be liquidated to wipe out C.R.E.A.M's reserves. Actually exploiting this in practice seems to have involved a whole bunch of additional fiddly details and transactions.
I think any process which takes 23 steps to describe could reasonably be described as "complex", but if you're jealous that you didn't think of it first its kinder to simply say so rather than talk down on the skill of the person involved in the attack.
Rather than reading the bird app thread, the same author's technical breakdown of the 29-step attack is a way better read: https://mudit.blog/cream-hack-analysis/
> This was one of the most sophisticated and cleanly executed DeFi attacks. The summary of the attack is that the attacker borrowed $1.5b of Yearn’s yUSD vault shares against $2b worth of collateral. They then doubled the value of the shares atomically by donating yUSD to the yearn vault. This meant that their debt on Cream became $3b against a $2b collateral. They can now default and take home a sweet $1b profit. Cream only had $130m assets available for lending, so the attacker was limited to $130m profits.
> 25. Since yUSDVault is now worth double, Cream now thinks that the account A cryUSD is now worth $3b instead of the original $1.5b. Technically, this is true. The vault of yUSDVault shares really did double. There’s no price or oracle manipulation here and don’t let chainlink god tell you otherwise :).
> 26. The problem is that account B’s debt suddenly increased to $3b against collateral of just $2b. Account B can now default on the loan and “pocket the $1b profit”. All is not good anymore. In normal circumstances where price of assets changes slowly, the system would’ve liquidated the account B before its debt became more than the collateral. Liquidation isn’t possible here because the price jump happened atomically. Using a TWAP or other time delayed oracle wouldn’t have helped either because you still wouldn’t have been able to liquidate the user. To liquidate a user, you need to buy out their debt position using their collateral. Nobody would have sold $3b worth of yUSDVault to Cream for $2b of ETH. Delaying your oracle input doesn’t mean someone will magically accept your trade at delayed prices.
This smells vaguely like a check-kiting scheme, only via collateralized debts instead of taking advantage of latency in check account reconciliation between institutions.
Famously, a guy managed to build a whole legitimate company atop one of those schemes, which went fine until he missed a step and the whole system crashed.
Actually, if you were familiar with how these things work, the attack was pretty carefully worked out. That said, since all this code was copycat crap by folks who didn't really understand it - not surprised. In other words, the code really was fine - the folks running the pool were just clueless in terms of what they let trade (ie, not suited to code).
Flash loans are a software exploit, rather a vulnerability within the "economic" system of the platform. Flash loans are simply fascinating, but if this is the third time this happened to this platform, they deserve what they got.
Also, that method man song is awesome, I can't believe I haven't heard of that until now. Crypto rules everything around me! Cream!
Smart contract dev is a lot more like hardware development then software development. You kind of have to get it right out the door the first time. Our tooling here is perhaps inadequate.
Makes me wonder if these smart contracts ought to be formally verified before implementation, using tools such as TLA+. I'm curious as to what experts in formal verification (of which I am most certainly not!) think.
This actually isn't quite correct. The original protocol actually had a formal spec that accompanied it. CreamFi chose to not maintain this spec. The spec constrained under what conditions the protocol could operate securely and (ignoring that their changes broke away from the spec) some of the tokens used in this and previous exploits to CreamFi did not meet those constraints.
Had the team actually maintained the formal spec, they could have notified the listing committee (which every iteration of has had at least one team member on it). This was absolutely a human error however it likely would have been caught prior to entering production if the team had maintained the formal spec.
From the POV of software engineering, smart contracts are really interesting in the following sense: there has pretty much never been any software stack where the cost of a bug/design flaw is so severe and so immediately punishing (except, maybe, space shuttle control type software).
As exemplified by - historically - the infamous DAO, and since then a very long string of buggy smart contracts leading to large loss of monies (this one being the latest), smart contracts are really good at curing SWE hubris that they are actually capable of writing bug-free code without machine assistance.
For all the bad things people say about blockchains and related tech., I suspect they will bring about a new era in formal software verification methods.
The August attack (1) seems to be a real hack, exploiting bugs in the code.
This current attack sounds more like market manipulation, but all bundled up in a single transaction. I can't find the details, but in the real financial world, there's a reliance on multiple competing arbitrageurs who make it hard to move the market much in big securities. In an automated system, that can all happen instantly.
My prior is that Proof of Work is a solid basis for an (inefficient and tautological) form of digital scarcity, or even a public random number generator, but nearly every crypto application outside of that seems to range from trivial, to mania, to downright fraud.
Assuming I do want to understand the DeFi landscape (and willing to suspend my disbelief some amount to do so), where is a good place to begin?
Likewise, I'm doing web stack consulting for several defi projects right now and the vast majority of what comes out of HN is straight up uneducated FUD.
This forum is pretentious on its good days, and when it comes to crypto it is just willfully ignorant.
It would be more helpful for the community if you pointed out the flaws.
Even without much DeFi experience I can see some comments are simple dismissals without understanding the enormity of technical details, which is a fatal mistake in the field. Not many explanations of why those dismissals are wrong though.
Interestingly, Justin Sun has apparently withdrawn more than a billion in USDC from the Aave liquidity pool in apparent response to that.
(It’s 2 AM in Tokyo and so I can’t elaborate for HNers who think that sentence is Greek. Short version: it’s going to be a very long day for some DeFi war rooms.)
Although a flashloan was used in this exploit, that's just a tool to leverage a fundamental flaw in the protocol. Flash loans clearly do more harm than good, so it's completely irresponsible for major DeFi platforms to still have this feature at this point.
The actual flaw is in Cream's oracle design for certain exotic long-tail assets. Basically, smart contracts need to get the price of an asset, and Cream was using the most naive way of simply calling the equivalent of asset.getPrice().
The reason this approach is critically unsafe is highlighted by this incident. A flashloan can alter price, borrow assets based on the new price, then return the price to normal before the transaction is finished.
This is not merely a coding bug but a basic design flaw that should have been caught by anyone with even a basic understanding of oracle design. It really reflects poorly on the competence of the entire DeFi space, considering CREAM is a pretty major protocol.
I’m a total cryptocurrency noob. Could you elaborate a bit further on what an oracle is in this context? I’m familiar with the term oracle in crypto for things such as a padding oracle, but I feel that what you’re referring to is a different kind of oracle.
An Oracle is a way to tell the blockchain about external data like the price of something in the general markets. As I understand, a flash loan is a loan that is both created and paid in the same blockchain transaction (thus if it can't be paid it won't be included in the transaction), and that the exploit here was to both modify the price given by the oracle twice (up and down) and have a flash loan in the middle, all in the same transaction.
I hope I'm not adding to the confusion because I am not an expert.
does the oracle in this specific case use external data? and combine that with internal / blockchain inputs? how does one sanitize all those inputs?
are oracles transactional, ie if you manage to alter the state of an oracle within a contract’s transaction, other transactions don’t get any “dirty reads” from the oracle, etc?
An oracle is just a provider of some kind of off-chain data. For example if I wanted to incorporate the stock price of AAPL in my smart contract I would need to "trust" some off-chain (and possibly centralized) provider of data to deliver that information to my smart contract.
The obvious problem is that if that data is manipulated somehow, the smart contract can potentially execute with malicious information.
Others have answered, but there is a tool that helps with trusting oracle data, called Chainlink ($LINK)
Chainlink uses a proof a stake (POS) concept where it calls out to a number of LINK nodes that have staked assets for liability in order to win rewards. With all of the Oracles data it goes through an algorithm, for simplicity, let's say the average of all the prices it received, gives the nodes a reputation score, on top of that it uses the reputation of the nodes to choose who ultimately fulfills the request, the number of tokens staked will also take into account. If reputation starts going negative, they could lose the tokens they have staked.
Flash loans are incredibly powerful and allow those without capital to take advantage of arb opportunities. I don't believe it is a given that they do more harm than good at a philosophical level. Not to mention, this exploit still exists without flashloans (however, anyone with $500,000,000 in crypto has likely KYC'd somewhere, so the risk profile is different).
The solution is better coding practices, and plenty of platforms have protections against this.
I think that a lot of the motivation for flash loans is that they democratize capital-intensive arbitrage attacks, making the attacks happen sooner, making all of the insecure contracts fail fast and improving the overall security of the DeFi ecosystem. In other words, it's supposed to make platforms fail and people lose money, because each hack exposes a bad contract and takes it out of the environment.
If flash loans didn't exist, then an entity with sufficient capital can still alter prices and exploit differentials in borrowing costs to profit. This is a common complaint about the mainstream financial system - examples include market corners, short squeezes, George Soros breaking the Bank of England, or the Fed artificially lowering borrowing costs for the U.S. Treasury. But they're limited to people who already have a billion dollars. Flash loans let everybody have a billion dollars, so that if there's an arbitrage opportunity you don't need capital to take advantage of it.
> In other words, it's supposed to make platforms fail and people lose money, because each hack exposes a bad contract and takes it out of the environment.
I can already hear my grandma say "I'm glad I lost all my savings, now the platform gets safer."
Apart from that, it's naive to think that this makes the ecosystem safer. We still have SQL injections and XSS in the wild even though everybody should know how to avoid them after literal decades of exploits.
The issue with SQL injection and XSS is that there is usually no cost to the website with the vulnerability. They can keep on doing business as usual, after a suitable mea culpa, without significant consequences.
When there's a crypto vulnerability, the contract usually gets drained. It goes bankrupt. There is no funds and no viable business there. Therefore, there's not just a significant incentive to guard against security holes, but there's also a selection mechanism.
People underestimate the power of bankruptcy, failure, death, revolution, nonexistence, and other selection mechanisms. Selection bias is the most powerful force in nature, because natural systems without a selection mechanism tend to get selected away. Arguably a lot of the problems with our current economy come about because we fail to let things fail.
> This is not merely a coding bug but a basic design flaw that should have been caught by anyone with even a basic understanding of oracle design. It really reflects poorly on the competence of the entire DeFi space, considering CREAM is a pretty major protocol.
How is CREAM a "pretty major protocol"? It was forked from Compound so no innovation on their own, and their token is not even in the top 100, and their platform is around #30 compared to others in DeFi. There is so much shit things in both DeFi and Cryptocurrency that it's unfair to judge other projects based on how bad they are.
It's like saying a well-written Rust project gets bad rep because some PHP developer once had a SQL injection, and somehow all programmers are the same...
Since Hacker News is the place for pendency, let me point out that the oracle here worked 100% correctly, and correctly reported the actual value of yUSD.
yUSD's value did actually double during the attacker, because the attacker gave yUSD holders millions of dollars as part of the attack.
1. Using account A, Flash Borrow 500m DAI
2. Deposit 500m dai into yDAI
3. Deposit ~500m yDAI into yUSD
4. Deposit ~500m yUSD into yUSDVault
5. Mint ~$500m crYUSD (it used yUSDVault as underlying)
6. Account A now has $500m crYUSD
7. Using account B, flash borrow $2b ETH
8. Mint cETHER
9. Borrow 500m yUSDVault
10. Mint $500m crYUSD
11. Transfer $500m crYUSD to account A
12. Borrow 500m yUSDVault
13. Mint $500m crYUSD
14. Transfer $500m crYUSD to account A
15. Borrow 500m yUSDVault
16. Transfer 500m yUSDVault to account A
17. Account A now has $1.5b crYUSD and $500m yUSDVault
18. Using account A, Redeem $500m yUSDVault
19. Transfer 8m yUSD to yUSDVault to ~double its’ share value
20. Since yUSDVault is now worth double, cream now thinks that the account A’s $1.5b crYUSD is worth $3b
21. Borrow $2b ETH
22. Account A now has $2 ETH, $500m yUSD, and $1b in Cream collateral.
23. The ETH and yUSD can be used to pay back the flash loans while the $1b collateral can be used to drain Cream.
Am I understanding correctly that all of this happens in one single transaction? The flash loan is borrowed, deployed, and repaid in one fell swoop?
I’m trying to think of the most complicated single transaction item I’ve ever seen booked. I wish I wasn’t so rusty because trying to figure out the journal entries for this would be a fun little nerd puzzle.
The attack was executed over multiple transactions due to block gas limits, but the bulk of it happened in this transaction [0].
Edit: These sort of financial engineering, whether one believes it to be an inherent flaw or not, are the exact reason why banks and financial regulation were eventually adopted.
Crypto becomes the wild west, we have these "flaws / glitches / financial engineering" -> many people lose money -> regulation by lawmakers -> the circle repeats itself.
Thanks for the link! Your edit reflects my thoughts exactly. I posted an old Law Review comment[1] describing (at a very high level) the market conditions in the early 1900s that gave rise to federal securities regulation. It’s a bit surprising how many of those mistakes we’re “relearning” with crypto. I wonder whether perhaps the crypto craze might have come about, in part, because of the regulatory inaction following the Great Recession.
Might be a nitpick, but banks predates computers by several centuries, so these kinds of vulnerabilities are not the reason why banks were "eventually adopted".
These are all tokens that wrap other tokens, in this case, USD stablecoins.
1. You take a stablecoin like DAI or USDC and deposit with Yearn, who in turn lend it out and earn interest. You receive yDAI or yUSDC tokens in return which can be redeemed for the original deposit plus accrued interest.
2. You take your yDAI and deposit that into a Curve pool which is a decentralized exchange specializing in stablecoins. There is a pool that allows swapping between yDAI and yUSDC (and two others). If you deposit in this pool, you get a generic yUSD token that represents your claim to the pool’s assets and fees.
3. You look at your yUSD not content with the financial alchemy you’ve performed so far and think “what can I do with this securitized certificate of deposit?” Fear not, Yearn has a “vault” (lending strategy) specifically for yUSD. You praise the degenerate ape overlords and deposit to earn even more interest on your boring dollars. In return you receive yUSDVault tokens.
4. Not content, you begin to wonder why stop with yUSDVault. Are there any other strangers you can lend your rehypothecated certificate of deposit to? Yes! Cream finance will happily issue you their version of yUSD called cryUSD against your yUSDVault collateral…party on Wayne!
5. Now, Cream aren’t your typical boring bank that incinerate their money on synthetic CDOs and the like. These cryUSD tokens that they issue, can also be used as collateral to borrow other things! Hooray! But in order to value cryUSD, Cream needs to figure out how much the underlying yUSDVault tokens are worth. To do this, they need to figure out how much yUSD each yUSDVault token has claim to, and then multiply by the yUSD price.
6. It just so turns out that if you borrow a bunch of yUSDVault in a flash loan, and then redeem it for yUSD, you can get the balance of the yUSDVault very low. Let’s say you did this and left the yUSDVault balance very low (say, $8m). This is not a problem in itself, as these tokens are designed to be redeemed.
7. Well, knowing what we know from step 5, a clever trader realizes that if they do all of the above, and then borrow some yUSD (say $8m) and just donate it to the yUSDVault, when Cream goes to calculate how much cryUSDVault is worth, it will have immediately doubled in value, because some generous donor has just doubled the balance of yUSD owned by yUSDVault (and doubling the borrowing power of cryUSDVault in the process). So if you had flash borrowed a bunch of cryUSDVault (say $1.5b) against flash borrowed collateral (say $2b of ETH), you just now managed to double the value of your loaned assets to $3b but you’ve only posted $2b of collateral.
8. Normally a borrower’s collateral would be liquidated well before being underwater, but in this case everything is happening atomically inside a single transaction.
9. So the smart trader takes her $3b of cryUSDVault, borrows a bunch of other stuff to repay the $2b flash loan, which leaves her with $1b of collateral to borrow a bunch of other stuff (and ultimately default on).
It seems daunting, but I think you can reduce it to an engineering problem by asking "how can I trick the system into overvaluing my portfolio?"
From there you "just" need to figure out a way to stack a chain of asset transformations to bamboozle the flash loan process into giving you too much money. I say "just" because it's obviously not a simple process, and there's no guarantee that you'd ever find a flaw in the system where it makes some incorrect assumption of value, but this person did, and was able to exploit it to great success.
The problem is the system is incredibly complex and adds no value to anything, and opens up tons of risk.
It's one thing for crypto to be a fun thing where people can day trade on made up numbers, arguably harming 'no one', but when major transactions get problematic, then it's a huge source of pain. Civil and legal lawsuits galore.
It demonstrates that net-net crypto is a value destroyer and is just a bad distraction.
The moment we try to regulate it (and we would have to do this if we wanted to normalized it and make it usable in the commons), then 'all the fun' would be drained out of the bubble as it boils down to just regular banking, more or less.
It's like an intellectual 'Chinese Finger Trap' for smart people with a bit of money to burn, that has negative externalizes.
If it's going to be 'money' then regulate it as money, and watch it the Tower collapse under the weight of it's own complexity.
I don't disagree, for the most part. Part of the "fun" of crypto and de-fi is getting to re-invent financial engineering concepts that have been regulated into non-existence by the traditional financial system.
I just don't see a space for everyone to be happy: if we want crypto to be currency 2.0, it needs to be as unfun as possible, and then you get back to regular banking. If we want crypto to be fun, then we're never going to escape this cycle of "hype and fomo sees people chasing the next coin" to "lots of money went poof" and "someone got rich by making someone else poor."
There might be a little bit of a happy place, above where the boring banks hold on to their systematic control of the system, but a little below where crypto is now with some regulation.
But I feel by the time crypto is useful, that will mostly have converged and 'regular fintech' will provide most of the opportunity.
> Well, knowing what we know from step 5, a clever trader realizes that if they do all of the above, and then borrow some yUSD (say $8m) and just donate it to the yUSDVault, when Cream goes to calculate how much cryUSDVault is worth, it will have immediately doubled in value, because some generous donor has just doubled the balance of yUSD owned by yUSDVault (and doubling the borrowing power of cryUSDVault in the process). So if you had flash borrowed a bunch of cryUSDVault (say $1.5b) against flash borrowed collateral (say $2b of ETH), you just now managed to double the value of your loaned assets to $3b but you’ve only posted $2b of collateral.
It's wild that markets can be manipulated inside essentially an uncommitted transaction.
This is the equivocation that is at the heart of smart contracts.
The promise of smart contracts is that "the code is the law". There is no need for trust, courts, or intermediaries. Of course his only works if the contract correctly implements a perfectly defined spec and has no bugs.
If one claims "the code is the law" they cannot claim it is a "hack" or "theft" when their code executes as written rather than as they desire.
This "theft" is an example of things working exactly as designed, and this seems to be an unfixable flaw in the concept behind smart contracts.
249 comments
[ 3.5 ms ] story [ 256 ms ] threadHe will release projects in prod, encourage people to throw money in, take the money and later claim he was just testing. It's bad behavior.
DeFi, in its users, self selects for a lot of...erm...unique personality traits.
* Not my joke. It was a co-worker's.
Price of Bitcoin will continue to rise as each year people figure out that, if someone can hack wallets, they're not doing it widespread enough for it to be a concern to the average bear, pun intended.
That codebase has a name: it's called Bitcoin.
No discernable hackage seen in the wild for the better part of the last 7-ish years.
And the incentive to find one grows exponentially with time.
I do wonder how much support they're getting.
Do they "truly" believe it themselves, or are they just rational actors well aware that they lose a lot of money if people stop listening to them? No way to know.
If I have a balance on a DeFi platform, it's vulnerable to attacks like the one in the original article. If I have a balance in a bank, this isn't the case. The risks aren't the same at all. Not the same type of risk, not the same magnitude of risk.
DeFi allows for a lot of unique and flexible things...and people are re-discovering that writing bullet proof code in such an environment is really really hard. i.e. No training wheels and lots of footguns available
>How can people still think that it's the future?
I'd view these events more as growing pains of a complex technology rather than an indication that it has no future.
People are learning though. See Cardano and their choice of Haskell and emphasis on formal verification.
If someone steals from my credit account, I Trust my financial institution to undo it.
Trustless systems are overrated when you have trustworthy institutions.
Quite. But what if you don't have access to trustworthy institutions? Or what if you need to coordinate between trustworthy institutions that either don't work together or don't share mutual trust? What if you distrust the very currency the institution does business with?
Your point is correct. If you trust the institutions all the way down, trustless is complicated and unnecessary. If you don't trust the institutions, what are your other options?
It sounds like people trusted CREAM with their money, and shouldn't have. Not as trustless as you might hope.
If the devs have written formal models for the system and verified that with a proof solver, you have a reasonable assurance the code matches the spec and that the spec is at least consistent with itself.
If the devs have Property Based Testing suites and fuzzing tools to automatically search for vulnerabilities in the code/spec or introduced via changes, you have reasonable assurances that the development process is thorough and likely won't haphazardly introduce a vulnerability in a change (and actively squash potential vulns that are discovered).
If open source security auditors (who's reputation is core to their business) regularly and publicly auditing the platform, you have reasonable assurances that on top of the code being reasonably secure, the spec itself doesn't have any glaring flaws in it.
If bug bounties have red teams regularly trying to discover exploits, you have additional assurance that if a bug exists, it'll likely be discovered, ethically reported, and resolved before being exploited.
Point being, zero trust isn't about not having trust, it's about not having blind trust. These should be the expectation for all high value software. We should be able to trust in the engineering of software systems like we trust in the engineering behind buildings and bridges.
---
Now with regard to this specific hack, CreamFi failed to do 2 out of the 4 of those things mentioned above and their security auditor only provided a very cursory/high level audit. Their report was not confidence inspiring and should have been a red flag to users to not use the service.
Now compare this with the org they forked their code off of. Compound Finance maintains a formal spec, uses formal methods, has a bug bounty, and receives regular, in depth security audits. CreamFi chose to make changes to a codebase after abandoning the security tooling (formal spec was no longer maintained) and protections that were in place with Compound Finance's code.
Any moderately competent technical user should have been able to tell that CreamFi was (like many other knock-off DeFi platforms) a ticking time bomb. We as a software engineering community however still have a long way to go in making these qualities/flags accessible to normal users.
I understand the practical argument (code is easier to audit and more reliable), I'm just not sure how the sum total of the ecosystem is better when, as a practical matter, crappy smart contracts keep losing depositors' money, and depositors keep trusting the wrong contracts.
For developed nations, we'll see Central Bank Digital Currencies slowly replace the existing financial network. You can still get your flexible monetary policy, regulatory compliance, and reversible transactions with a CBDC. The additional benefit is that now instead of having a bunch of centralised, discontiguous, and opaque services for transferring funds, now you have a decentralised, unified, and transparent network for doing this. Additionally, smart contract or smart validator functionality allows you to move some of the traditionally centralised financial logic up into this transparent & decentralised space while still maintaining all the legal protections you'd have otherwise.
Side note: I say decentralised here because ideally CBDCs will use some Proof of Authority system with the various states/provinces/counties/parishes/districts/etc each running validators. The idea here being that you still retain full control by the nation however it now becomes exceedingly difficult for any one person to manipulate the network without the consent/awareness of many other officials.
Now how about developing nations? Many of these nations lack a stable or trusted financial sector. Their people don't trust the officials, the offices, or the policies. These people are the main users of the truly decentralised networks. Of course the risk of crappy smart contracts losing your money is a risk (and assurance/accreditation programs are working to improve the visibility of well designed & operated contracts). The question however is whether that risk is greater or lesser than the risks or costs of using traditional financial institutions in these regions (if the people can even get access to them).
That said I just don't see a lot of the value in a lot of "DeFi" at the moment. A lot of it exists solely as vehicles to allow people to move more money around at a time so that they can take bigger leveraged risks on the market. Now there are useful applications in the space however many are still small and finding their footing.
The majority of supply chain/production traceability solutions and identity solutions in the space are really just two sides of the same coin and serve the purpose of providing a decentralised (or at minimum federated) source of reputation for people and businesses where the local government fails to. Identity solutions provide a means for people in these nations to "prove" their credentials/reputation to gain access to low-to-reasonable interest rate loans or prove their credentials to potential employers. Likewise they provide a means for businesses to provide a history for their products which helps them sell their products at closer to the international market rate (compared to being forced to sell to the big corporation in their region that turns around and resells to the rest of the world).
Lending and Micro-lending platforms provide a means for people in these regions to get access to loans (denominated in their local currency) at rates they would otherwise not be able to get access to. People or organisations in higher QoL/CoL nations/regions can provide liquidity to these services and users in these developing regions can slowly get access to larger & lower interest loans over time by building up their "credit history"/reputation tied to their identity. In developed nations we have systems for this already but many developing nations lack such a service that is accessible to many of their people (and that is trusted). These services still have a long way to go but as the previously mentioned digital identity solutions become more available, this space should start to see some significant improvements in usability & trust.
I'll stop at that because I've already gone way past what I intended to write up (I was also considering going into detail about decentralised good & services marketplaces) but my poin...
* https://rekt.news/compound-rekt/
* HN discussion: https://news.ycombinator.com/item?id=28716979
The Compound Finance paper spec essentially just lists "this subsystem does these things" and then each function/operation is a list of preconditions, what actions are taken in what conditions, and the expected result. This isn't bad per se but it's not great either. Instead the paper spec really should be showing what transformation is being applied to the state, why we want that transformation applied, what properties must hold throughout the transformation, and then demonstrating that those properties hold.
Compare this (Compound):
https://github.com/compound-finance/compound-protocol/blob/m... https://github.com/compound-finance/compound-protocol/tree/m...
to this (Uniswap):
https://github.com/runtimeverification/verified-smart-contra... https://github.com/runtimeverification/verified-smart-contra...
or this (Djed):
https://eprint.iacr.org/2021/1069.pdf
The first just describes the system and then asserts preconditions hold which works well enough for verifying that the code matches the spec but the other actually verify that the spec is doing what the user & developer expect it to by formalising the system and analysing the properties of that system.
Compound's project wouldn't have been vulnerable to any of the attacks executed on CreamFi however they are vulnerable to the class of spec errors. Uniswap and Djed on the other hand would be protected from the majority of that class of issue that Compound experienced. This isn't to say that they are invulnerable but I'd be willing to say that they are approaching "cryptography-grade" security where you can trust these protocols just like you can trust AES, RSA, and ECC encryption & signing.
---
This of course isn't to say that what Compound does is bad but as that incident shows, there is still room for their improvement in the security space. Cryptocurrency and "Decentralised Finance" are finally starting to grow up into proper subsets of the cryptocurrency and game theory communities. Now this might be a bit of general commentary on the SW space but hopefully long term this trend causes some of this security minded design to bleed over into the greater software engineering community.
Formal verification absolutely would not have helped in this case.
https://mudit.blog/cream-hack-analysis/.
1. A definition of the constraints of the system. These constraints are "outside" the system and if they are violated, the properties of the system will not hold. This part boils down to clear and dis-ambiguous documentation on the constraints of the system as well as some tooling to help verify the constraints are held (not always possible).
2. A definition of the system itself. This defines the rules and operations within the system as well as formal methods to prove the correctness of this system. Provided this definition is shown to be consistent, as long as the constraints (part 1) are held true, the system is secure.
3. The code itself. Projects have to choose between either writing the code and using formal methods to verify functional equivalence between the code and the system (faster but harder) or using a code generator to produce a runtime directly generated from the system definition.
---
The code (part 3) is only secure if there's a full one to one map between it and the system definition(part 2). The system definition (part 2) is only secure if all the constraints (part 1) are upheld. You can verify parts 2 and 3 automatically but in many cases you won't be able to verify all of part 1 automatically.
This attack relied on the fact that one of the tokens was atomically volatile (allowing the attacker to manipulate funds in a single atomic step increasing the price up to whatever price and risking nothing if they are unsuccessful). The previous exploit was due to the listing of another liquidity pool token that allowed reentrancy. This allowed the two pools to repeatedly interact with each other inside of each other's code bypassing various state checks.
CreamFi failed in two places. One the devs stopped maintaining the spec after forking the protocol off the original Compound Finance protocol so even if they had held the constraints, they had added features that haven't been considered with regard to the formal security of the system. Two (and more importantly) the listing committee (responsible for introducing new tokens) wasn't aware of the constraints of the system.
One could formally verify that if the account number is set in the wash account (plus like six other places) then the loan won’t be repaid due to programming errors. But formal verification doesn’t tell one that the UI is garbage and hard to know that the account number needs entered in six places to get the correct formally verified action to occur instead of the other formally verified action that repays the loan in full.
The risk of investing in stocks is always that the underlying companies could have their business ruined overnight for any reason. The risk of swaps is always that the counterparty could go bust and be unable to pay you even if your bet pays off (see Lehman Brothers). The risk of leveraged futures positions is you can get liquidated on fat finger trades or flash crashes. The risk of structured credit products like CLOs or mortgage backed securities is that the pool is fraudulent. The risk of many quant strategies is that the correlations go to one and your capital gets wiped out as your hedges fail to protect you.
Do any of these risks mean those asset classes are doomed? No, all of the above asset classes are bigger than ever. Markets can and do live with disastrous risk looming over their heads all the time. Unless your name is Nassim Taleb, the reality is that you mitigate the risks you can, model out the risks that you cannot, then price the asset accordingly. The foundation of modern finance is “we don’t have to live in mortal fear of risk if we’re smart about it”
If inherent risk was an insurmountable barrier to the existence of a financial product, then I guarantee you the financial system would just be the old-timely community bankers like in It’s a Wonderful Life.
All of these systems are complex black boxes, for which the full risk profile can never be fully known let alone eliminated. Yet all of these asset classes continue to reach record size. For the foreseeable future, risk is not a meaningful constraint on financial activity or the growth of any otherwise profitable sector.
Global capital is insanely hungry for yield. It’s willing to accept very large, outsized risks as long as returns are attractive. DeFi continues to grow because it offers significantly higher top-line returns than traditional products. As long as that continues to be true, investors will stomach, and in many cases outright ignore, the risks.
I'm not sure if that makes it better (no security was broken) or worse (these markets are highly susceptible to manipulation)
From the article:
C.R.E.A.M. was targeted by what is known as a flash loan attack. Flash loans are uncollateralized cryptocurrency loans structured so that they must be paid back instantly using smart contracts, making them attractive for things like arbitrage across exchanges. If the loan isn’t paid back, then it never happens, because both occur in the same transaction.
Analysts on social media who pored over the details of the attack suggested that the hacker exploited C.R.E.A.M. in an incredibly complex transaction for a flash loan that ultimately allowed the hacker to drain C.R.E.A.M.’s Ethereum-based lending pools, leading to a gain of around $130 million in different tokens. The attack cost the hacker roughly 9 ETH in network fees, or around $36,000.
[edit] tl;dr: it's the reason there's now an Ethereum Classic, and we learned that Code is Law and trustlessness only applies to grandma's savings, not Vitaliks.
[1] https://www.coindesk.com/learn/2016/06/25/understanding-the-...
Yep. Legal jargon IRL is about as close as you get IRL to "code", with roughly 1,000 years of legal development underlying common law and modern legal systems to inform a style of language that is practically its own dialect.
Quite a bit of it has developed over the centuries in an effort to eliminate potential ambiguities in things like contracts so there would be no question about how the legal instrument should be executed.
This is why, to the butt of many jokes & frustrations, legalese is so extremely verbose & dense. Eliminating ambiguities or unintentional side effects or loopholes is extremely difficult.
Code appears to be little different in this respect: Implementing code that effectively says "don't manipulate the market in a way that makes us lose $millions" is not a straightforward task.
This is the lesson a lot of people fail to learn from watching. They seem to have to experience it.
Let to an ETH hard fork into -> (ETH Classic - still traded, and ETH)
Could you not use the same exact description of anyone exploiting bugs in software to gain access to a system?
I believe there is actually a case making its way through the courts as we speak where someone is making the case that "code is law" is binding and should be able to keep the proceeds of his "loophole exploitation." Personally I'm with him haha. Sow -> Reap. [1]
[1] https://www.coindesk.com/tech/2021/10/22/after-stealing-16m-...
Those are bypassing security restrictions. Whereas each step in this process was a legitimate & allowable crypto transaction.
Both are exploits. But they are not the same type of exploit.
In this case, the trade didn’t even violate the intended behavior of systems involved. It’s not like a bug which results in a system operating differently than intended. The system operated exactly as intended, but their intended system design was obviously flawed.
An analogy to traditional finance might be something like a short squeeze, where a sufficiently capitalized counterparty can blow up the trade and extract money from someone else if (and only if) they can pump enough capital into the system.
The difference with smart contracts is that an attacker doesn’t need to have the capital to execute the trade. They can secure a “flash loan” that is conditional on the trade working out, otherwise the loan never happens. That’s why the attacker was able to pump $500 million into the play without ever taking ownership of the $500 million or even putting it at risk. The flash loan only occurred in the context of the trade, but it was open and closed as part of the complex contract. The attacker only had to pay transaction fees to push the contract through.
They clearly did NOT intended to give the coins away. Or if you argue they do any OS had any remote code execution attack also intended.
They designed a cryptocurrency with a floating value that went up or down according to certain rules. Someone read these rules carefully and then borrowed billions of dollars of capital to play the game, according to the rules, in a way that moved the value in their favor.
This isn't like a remote code execution attack because OS designers aren't planning features that allow unauthorized remote code execution.
This is more like an options trade that didn't work out because someone with more money used their capital to blow up the trade. You can't make a bad trade in the stock market and then argue that your loss was a "bug" because you intended to make money, not lose money.
Code is law will only lead to SkyNet.
This is more like setting your screensaver or debugger to cmd.exe on windows NT and waiting for an admin process to crash or the screensaver to start. (I forget exactly how it worked)
If someone chose to play such a game intending to win and with appropriate planning to ensure wins through optimal play, I wouldn’t call that an exploit at all. It’s beating the game, and the owner may ban you from playing it, but no laws were broken by you playing it in such a manner with larger than average capital. But your winnings are yours, fair and square.
If it was, people will argue malicious compliance like you are, but intent has to be considered, both the intent of the developer and the intent of the exploiter (or loaner, is maybe a less loaded term for them)
“Someone read the rules carefully, then borrowed capital to move the rules in their favor”, you could say the same thing about an integer overflow, both are attacks of excess, with intent for massive personal gain, outside the intended use case of the system
100% Agree you can also look up trading patterns on option expiration Fridays to see people making sure that their trades 'work out'
I frequently make decisions that don’t turn out as I intended. You need a distinction between whether the outcome is what you intended and whether the process is what you intended. It isn’t a clear line.
No, the design was so complex that its flaws were well hidden, and therefore not intended.
Quoting C. A. R. Hoare:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
That’s no less true for a Chrome sandbox escape.
In fact, this Ethereum loan platform’s behavior is encoded in program source codes, just like Chrome. One expects that some exploitable issues in the Chromium code arise not from syntactical but conceptual errors. The code could match a mistaken programmer intent, and this often happens.
Excellent question, one that crypto dudes could ask themselves a little more often.
You are probably reading this comment and thinking "yeah, hah, naive fools". About as naive as the fools, that believe in a 100 line program, that gives you a puzzle that nothing will realistically ever be able to solve, yet the program could tell immediately if the solution is wrong or right.
This is clearly a false statement. The people who set up the system did NOT intend to allow others to take $130 million for nothing.
The point was that their code did not express their intentions 100% correctly, and that's because that is quite hard to do.
And that’s basically what happened here: Someone read the fine print of the trading platform and realized they could use a flash loan to push the system into a space where the trade would default and the attacker would profit. So they pressed the button and the system worked as designed.
If you want your gains/losses to be reasonably bound, you have to limit yourself to buying and selling stocks directly. Unfortunately, there's not enough money in that to make a living day-trading.
It is like when Kim Kardashian gets paid 50M for a 30 second add on Instagram. I may think that is unreasonable, but I don't have any contract with anyone implying that she be paid a standard actor's wage.
Intent is certainly a big part of law.
When examining classic contracts, a judge will try to also deem intent.
Contracts have been thrown out, interpreted by intent of parties.
An example, are the comments in the source code for this smart contract? Did everyone have opportunity to see them?
It could affect a court battle...
If your plan is to rely on the court system, then just rely on the court system. You can write your contract on paper; smart contracts serve no purpose whatsoever then.
But just as in real life, an executor can make mistakes.
Traditionally, a judge may return or redistribute assets in such a case. Or claim the will was not interpreted correctly. In such cases, determining the intent of the contract is the goal of the court.
Like it or not, smart contracts are not immune to contract law, civil law, courts.
The first court cases, which will undoubtedly happen, will be very interesting.
And moreso, different legal jurisdictions will interpret things differently. If I was writing smart contracts, I'd want some sort of boilerplate, insisting upon legal jurisdiction, maybe like an open source license, but for smart contracts.
After all, once your identity is known, normal courts can compel you to do things...
The intent (in legal sense) was to make a specific stock trade, not to make money.
If the execution price was obviously incorrect, the trade will be voided for example.
Intent is literally the heart of criminal law. You have to have intended a crime for it to be a criminal act. In this context, this means that you had to intend to do things that would legally constitute a crime, even if you did not know that the actions/result would be a crime. For some crimes, specific intent is not required for all of the factors (for example, for statutory rape, you do not need to have intended or even known that the other person was underage; for many manslaughter charges you do not have to have intended to kill someone so long as you intended to do things that could reasonably have been expected to cause someone's death).
Intent is also a fundamental factor in tort law, where intentional acts can literally quadruple the amount of damages the plaintiff may receive.
And in contract law, intent is a basic foundational element of a contract. And indeed, a number of contractual disputes arise over one party intending to make money, not actually making money, and suing their counter-party as a result. And many times, the plaintiff wins...
This situation is probably governed by contract law. Since those disputes turn entirely on the specific facts proving or disproving mutual intent, it's hard to say who would win in this dispute since only a small subset of the relevant facts are publicly known.
it is literally not. Though it is a requirement of some crimes.
> You have to have intended a crime for it to be a criminal act.
No, you don't, in general. You have to have intended a particular outcome if the particular crime requires that, but plenty of crimes do not have such requirements (or specifically do not apply if intent is present). E.g., “depraved heart” murder, involuntary manslaughter, and any strict liability crime or crime of negligence or recklessness.
Even if intent isn’t written into a specific law, the whole system is built to specifically allow intent to be considered in so many stages. Sometimes they don’t even decide to prosecute.
Laws exists specifically to create a functioning society. Laws do not exist for the sake of having laws. Any sane person enforcing any kind of rule understands this.
This take is like programmers getting angry when businesses don’t care about the quality the the code or something, forgetting that the whole reason people hire programmers is to solve business problems, not to write text on a computer. Total miss of the point of the exercise.
Mental state (which is much broader than intent, though intent is an aspect of it) is an important consideration for criminal law and most offenses have a required mental state (strict liability offenses are a small minority). And mental state is, yes, considered broadly beyond the formal requirements, too.
But to say that “intent is literally the heart of criminal law” is both literally false and substantively misleading.
Maybe, but the crime wouldn't be first degree murder.
Try googling "mens rea"; e.g.:
"A mens rea refers to the state of mind statutorily required in order to convict a particular defendant of a particular crime. See, e.g. Staples v. United States, 511 US 600 (1994). Establishing the mens rea of an offender is usually necessary to prove guilt in a criminal trial. The prosecution typically must prove beyond reasonable doubt that the defendant committed the offense with a culpable state of mind." [0]
[0] https://www.law.cornell.edu/wex/mens_rea
> Maybe, but the crime wouldn't be first degree murder.
The felony murder rule disagrees.
https://www.justia.com/criminal/offenses/homicide/felony-mur...
Whether or not one accepts that use of “normal”, it remains a rule and the claim that murder without specific intent is categorically not first degree, even in broad general terms is false (even before looking into all the variations in specific statutory schemes in the US, which really frustrate this kind of generalization, which takes common law rules and overgeneralizes the way things that are not part of the common law are mapped on to it.)
That's too macro. Multiple steps.
The intent of a stock trade is to exchange currency for share(s). That intent was fulfilled.
Your _desire_ was to make money, but that's not an inherent function of the stock trade.
What is a 'smart contract' in that universe and how is it different than a 'contract'?
1. Someone locking themselves in a dark (usually smoky) room with someone in a button down shirt (with rolled up sleeves) standing over their shoulder.
2. Green text on a black background
3. The words "I'm in" yelled at some point.
Doesn't sound like any of that happened here.
How do you appeal to the courts after doing business under an explicit shared understanding that the courts are unnecessary and irrelevant? It will be difficult to prove that you had any expectation of the other party obeying any norms other than doing everything within its technical power to benefit from the transactions.
Why do you suppose this is the case? Surely that’s not in any way true.
You have to pick between outside and inside the law.
i feel that there is a case of false advertising somewhere here. The classic finance system doesn't advertise "code is law" as a feature, and thus easily claws back accidentally transferred into your account $1B. The Ethereum based crypto and the likes are heavily promoting the "code is law" feature, and thus their readiness and attempts to back off from it anytime the things not going their way suggests false advertising and intentional, at this point giving the history, misleading of the users/customers.
Wrt. the original post - it is pretty surreal, users just borrow and mint $500M-2B in a transaction. The crypto proponents tear at Fed for printing money. Yet even the Fed and WallStreet rarely do $2B flash transaction, and not on a whim by some passer-by Shmoe user. The crypto is really democratizing/distributing and multiplying the financial madness that previously was limited to the exclusive club of big money. I have hard time to see how that is any good, and the wolves of crypto look to me much worse than the wolves of the WallStreet.
I actually think Smart Contracts have loads of potential beyond all this "number go up" stuff
Here just a few : https://intercoin.org/applications
This word to describe software settling monetary transactions is actually a bad choice and oversells what Ethereum actually can provide. A better term would be a financial vending machine.
On chain EVM transactions are essentially just stupid scripts that act according to the same simple, deterministic roles every time you put money into it. The end result is always either you gaining or losing money (but return some other form of “value” like a chocolate bar from a vending machine) by means of a transaction between two people that do not need to know i.e. “trust” each other.
While it certainly does not redefine civil law, a vending machine — if well designed — can enforce compliance with the law without requiring a middle man like a bank or a lawyer.
As every programmer can testify, however, even simple programs can exhibit fairly complex behavior and that’s often impossible to fully predict by static analysis alone.
Still „virtual financial vending machines“ (it’s not as catchy as “smart contracts”) have a huge potential to disrupt the banking and financial services sector.
Good article that covers the topic: https://www.ft.com/content/4169ea4b-d6d7-4a2e-bc91-480550c2f...
Whether it qualifies underall all common senses of "hack" is debatable, but it at least qualifies under a common sense of the word.
"Ugly and imaginative solutions have something in common: they both break the rules. And there is a gradual continuum between rule breaking that's merely ugly (using duct tape to attach something to your bike) and rule breaking that is brilliantly imaginative (discarding Euclidean space)."
This question might be getting way too philosophical or abstract, but would the following statement be fair:
"If something is designed, its design is intentional."
That isn't to say, a thing that is designed can't have flaws, but, if it was created to process things in a predetermined series of events, isn't that how it's supposed to work? If someone is able to exploit the layout of that design - a flaw of logic, not of security - it seems weird to think that the act of someone using it would be considered unintended, you know? I feel like a lack of planning or thought by the designer doesn't necessarily put any responsibility on the user.
Again, might be more of a debate around the concept of design...it's just a weird thing to consider something like, "Yes, the platform was built to do that, but you weren't expected to use the platform to do that!"
¯\_(ツ)_/¯
That's what a cyberattack hack is.
Well, while the attacker did not exploit a bug inside the lending protocol code per se that person surely relied on a design flaw. Basically, what successful flash loan attacks do is to manipulate the price of an asset inside a „liquidity pool“ of a single „distributed exchange“ (DEX) temporarily to a much lower value and then buy off this asset cheaply and sell it on another DEX for profit.
To protect itself from a flash loan attack, a DEX protocol should use an external „oracle“ to determine the price of an asset instead of relying on the „in-house price“ (in lieu of a better word). C.R.E.A.M. does not seem to do this. This is clearly a flaw in its pricing model.
unaudited
unaudited
unaudited
unaudited
unaudited
well, well, well
If it isn't the consequences of my own actions.
Auditing really doesn't mean much. A lot of audited platforms get hacked. A lot of unaudited platforms get hacked. Nobody is ever accountable.
Do audited projects get hacked? Yes, absolutely. Is a clean audit report mean a project is bullet proof. Definitely not, especially if it's not from a top-tier firm. But an audit will definitely catch any of the common exploits that are easy to make, like this protocol doesn't check to make sure that the caller is not currently inside another transaction in the contract.
All in all, an unaudited protocol has at least an order of magnitude higher risk than one audited by a reputable firm. Ignoring audits altogether would be like refusing to lock your doors, because you heard about a house that still get robbed when the front door was locked.
I agree that unaudited is worse. But what are you actually paying for with these clowns?
External audits by good teams are a good layer, but neither they, nor any other individual layer is a silver bullet. Good audits do provide a lot of value.
This was not a standard attack though. It was a genuinely new attack vector that's not been seen before. Flash loan was just one hammer in the attacks toolbox.
Remember anything a flashloan can do, a whale can do too.
Auditing isn't perfect, but it is better than not doing it at all.
Its a greater issue in security where audits and testing can lead one into a false sense of security, 'because it is audited'. The original post was saying all the hacked contracts were 'unaudited'. While this is true, I am arguing that in nearly every case, the audit would just be a copy paste of the same data the solidity developer would see when they ran the open source tooling.
That's not been my experience with good audits. Automated tooling only gets you so far. We use open source automated security tooling, unit tests, and and some formal proving, and audits have found things these didn't.
Here's the audit that just finished:
https://github.com/OriginProtocol/security/blob/master/audit...
Their findings are very valuable, could potentially have saved million of user AUM/TVL. Sincerely, Best of luck with Origin!
It's not "incredibly complex". Someone just laundered the magic beans through a series of intermediate cryptocurrencies until they got to one they could just conjure out of thin air. You know, like Tether.
Don't worry though, this is good for Bitcoin.
lol...have you ever given any thought whatsoever to performing a similar exploit? If you have, you wouldn't be brushing this off so nonchalantly
> This was one of the most sophisticated and cleanly executed DeFi attacks. The summary of the attack is that the attacker borrowed $1.5b of Yearn’s yUSD vault shares against $2b worth of collateral. They then doubled the value of the shares atomically by donating yUSD to the yearn vault. This meant that their debt on Cream became $3b against a $2b collateral. They can now default and take home a sweet $1b profit. Cream only had $130m assets available for lending, so the attacker was limited to $130m profits.
> 25. Since yUSDVault is now worth double, Cream now thinks that the account A cryUSD is now worth $3b instead of the original $1.5b. Technically, this is true. The vault of yUSDVault shares really did double. There’s no price or oracle manipulation here and don’t let chainlink god tell you otherwise :).
> 26. The problem is that account B’s debt suddenly increased to $3b against collateral of just $2b. Account B can now default on the loan and “pocket the $1b profit”. All is not good anymore. In normal circumstances where price of assets changes slowly, the system would’ve liquidated the account B before its debt became more than the collateral. Liquidation isn’t possible here because the price jump happened atomically. Using a TWAP or other time delayed oracle wouldn’t have helped either because you still wouldn’t have been able to liquidate the user. To liquidate a user, you need to buy out their debt position using their collateral. Nobody would have sold $3b worth of yUSDVault to Cream for $2b of ETH. Delaying your oracle input doesn’t mean someone will magically accept your trade at delayed prices.
Famously, a guy managed to build a whole legitimate company atop one of those schemes, which went fine until he missed a step and the whole system crashed.
https://krebsonsecurity.com/2019/09/mypayrollhr-ceo-arrested...
Also, that method man song is awesome, I can't believe I haven't heard of that until now. Crypto rules everything around me! Cream!
In fact, this is a great illustration of why formal verification is not nearly sufficient to guarantee a properly functioning trading system.
I understand how the first can be arguable (or obvious, depending on what you mean), but are you really saying the second isn't true?
Had the team actually maintained the formal spec, they could have notified the listing committee (which every iteration of has had at least one team member on it). This was absolutely a human error however it likely would have been caught prior to entering production if the team had maintained the formal spec.
As exemplified by - historically - the infamous DAO, and since then a very long string of buggy smart contracts leading to large loss of monies (this one being the latest), smart contracts are really good at curing SWE hubris that they are actually capable of writing bug-free code without machine assistance.
For all the bad things people say about blockchains and related tech., I suspect they will bring about a new era in formal software verification methods.
This current attack sounds more like market manipulation, but all bundled up in a single transaction. I can't find the details, but in the real financial world, there's a reliance on multiple competing arbitrageurs who make it hard to move the market much in big securities. In an automated system, that can all happen instantly.
1. https://halborn.com/explained-the-cream-finance-hack-august-...
Assuming I do want to understand the DeFi landscape (and willing to suspend my disbelief some amount to do so), where is a good place to begin?
There are thousands of people there more than happy to show you the ropes.
This forum is pretentious on its good days, and when it comes to crypto it is just willfully ignorant.
Even without much DeFi experience I can see some comments are simple dismissals without understanding the enormity of technical details, which is a fatal mistake in the field. Not many explanations of why those dismissals are wrong though.
(It’s 2 AM in Tokyo and so I can’t elaborate for HNers who think that sentence is Greek. Short version: it’s going to be a very long day for some DeFi war rooms.)
The actual flaw is in Cream's oracle design for certain exotic long-tail assets. Basically, smart contracts need to get the price of an asset, and Cream was using the most naive way of simply calling the equivalent of asset.getPrice().
The reason this approach is critically unsafe is highlighted by this incident. A flashloan can alter price, borrow assets based on the new price, then return the price to normal before the transaction is finished.
This is not merely a coding bug but a basic design flaw that should have been caught by anyone with even a basic understanding of oracle design. It really reflects poorly on the competence of the entire DeFi space, considering CREAM is a pretty major protocol.
I hope I'm not adding to the confusion because I am not an expert.
does the oracle in this specific case use external data? and combine that with internal / blockchain inputs? how does one sanitize all those inputs?
are oracles transactional, ie if you manage to alter the state of an oracle within a contract’s transaction, other transactions don’t get any “dirty reads” from the oracle, etc?
The obvious problem is that if that data is manipulated somehow, the smart contract can potentially execute with malicious information.
Chainlink uses a proof a stake (POS) concept where it calls out to a number of LINK nodes that have staked assets for liability in order to win rewards. With all of the Oracles data it goes through an algorithm, for simplicity, let's say the average of all the prices it received, gives the nodes a reputation score, on top of that it uses the reputation of the nodes to choose who ultimately fulfills the request, the number of tokens staked will also take into account. If reputation starts going negative, they could lose the tokens they have staked.
So in this case someone wrote a smart contract/stored procedure that:
- loan $a_lot_of_money from $defi_a
- do something with $a_lot_of_money to confuse an oracle (e.g. a price feed)
- exploit $defi_b who relies on above oracle data
- return $a_lot_of_money to $defi_a
This all happens in a single "db transaction" so as long as $defi_a receives its money back the tx is going to pass.
If $defi_b relies on an oracle that takes it's data from on-chain, and thus is manipulatable with $a_lot_of_money, it is suspectible to those attacks.
To counteract this, $defi_b could only rely on oracles that are secure against manipulation from $a_lot_of_money, but they don't always exist.
This mechanism can be used for good (riskless arbitrage across decentralized exchange) or for bad exploits.
The solution is better coding practices, and plenty of platforms have protections against this.
If flash loans didn't exist, then an entity with sufficient capital can still alter prices and exploit differentials in borrowing costs to profit. This is a common complaint about the mainstream financial system - examples include market corners, short squeezes, George Soros breaking the Bank of England, or the Fed artificially lowering borrowing costs for the U.S. Treasury. But they're limited to people who already have a billion dollars. Flash loans let everybody have a billion dollars, so that if there's an arbitrage opportunity you don't need capital to take advantage of it.
I can already hear my grandma say "I'm glad I lost all my savings, now the platform gets safer."
Apart from that, it's naive to think that this makes the ecosystem safer. We still have SQL injections and XSS in the wild even though everybody should know how to avoid them after literal decades of exploits.
When there's a crypto vulnerability, the contract usually gets drained. It goes bankrupt. There is no funds and no viable business there. Therefore, there's not just a significant incentive to guard against security holes, but there's also a selection mechanism.
People underestimate the power of bankruptcy, failure, death, revolution, nonexistence, and other selection mechanisms. Selection bias is the most powerful force in nature, because natural systems without a selection mechanism tend to get selected away. Arguably a lot of the problems with our current economy come about because we fail to let things fail.
How is CREAM a "pretty major protocol"? It was forked from Compound so no innovation on their own, and their token is not even in the top 100, and their platform is around #30 compared to others in DeFi. There is so much shit things in both DeFi and Cryptocurrency that it's unfair to judge other projects based on how bad they are.
It's like saying a well-written Rust project gets bad rep because some PHP developer once had a SQL injection, and somehow all programmers are the same...
yUSD's value did actually double during the attacker, because the attacker gave yUSD holders millions of dollars as part of the attack.
I’m trying to think of the most complicated single transaction item I’ve ever seen booked. I wish I wasn’t so rusty because trying to figure out the journal entries for this would be a fun little nerd puzzle.
Edit: These sort of financial engineering, whether one believes it to be an inherent flaw or not, are the exact reason why banks and financial regulation were eventually adopted.
Crypto becomes the wild west, we have these "flaws / glitches / financial engineering" -> many people lose money -> regulation by lawmakers -> the circle repeats itself.
[0] https://etherscan.io/tx/0x0fe2542079644e107cbf13690eb9c2c659...
[1]https://news.ycombinator.com/item?id=29041167
1. You take a stablecoin like DAI or USDC and deposit with Yearn, who in turn lend it out and earn interest. You receive yDAI or yUSDC tokens in return which can be redeemed for the original deposit plus accrued interest.
2. You take your yDAI and deposit that into a Curve pool which is a decentralized exchange specializing in stablecoins. There is a pool that allows swapping between yDAI and yUSDC (and two others). If you deposit in this pool, you get a generic yUSD token that represents your claim to the pool’s assets and fees.
3. You look at your yUSD not content with the financial alchemy you’ve performed so far and think “what can I do with this securitized certificate of deposit?” Fear not, Yearn has a “vault” (lending strategy) specifically for yUSD. You praise the degenerate ape overlords and deposit to earn even more interest on your boring dollars. In return you receive yUSDVault tokens.
4. Not content, you begin to wonder why stop with yUSDVault. Are there any other strangers you can lend your rehypothecated certificate of deposit to? Yes! Cream finance will happily issue you their version of yUSD called cryUSD against your yUSDVault collateral…party on Wayne!
5. Now, Cream aren’t your typical boring bank that incinerate their money on synthetic CDOs and the like. These cryUSD tokens that they issue, can also be used as collateral to borrow other things! Hooray! But in order to value cryUSD, Cream needs to figure out how much the underlying yUSDVault tokens are worth. To do this, they need to figure out how much yUSD each yUSDVault token has claim to, and then multiply by the yUSD price.
6. It just so turns out that if you borrow a bunch of yUSDVault in a flash loan, and then redeem it for yUSD, you can get the balance of the yUSDVault very low. Let’s say you did this and left the yUSDVault balance very low (say, $8m). This is not a problem in itself, as these tokens are designed to be redeemed.
7. Well, knowing what we know from step 5, a clever trader realizes that if they do all of the above, and then borrow some yUSD (say $8m) and just donate it to the yUSDVault, when Cream goes to calculate how much cryUSDVault is worth, it will have immediately doubled in value, because some generous donor has just doubled the balance of yUSD owned by yUSDVault (and doubling the borrowing power of cryUSDVault in the process). So if you had flash borrowed a bunch of cryUSDVault (say $1.5b) against flash borrowed collateral (say $2b of ETH), you just now managed to double the value of your loaned assets to $3b but you’ve only posted $2b of collateral.
8. Normally a borrower’s collateral would be liquidated well before being underwater, but in this case everything is happening atomically inside a single transaction.
9. So the smart trader takes her $3b of cryUSDVault, borrows a bunch of other stuff to repay the $2b flash loan, which leaves her with $1b of collateral to borrow a bunch of other stuff (and ultimately default on).
Thanks for the write up, but it seems rather daunting that someone should have to have so much knowledge about such systems.
From there you "just" need to figure out a way to stack a chain of asset transformations to bamboozle the flash loan process into giving you too much money. I say "just" because it's obviously not a simple process, and there's no guarantee that you'd ever find a flaw in the system where it makes some incorrect assumption of value, but this person did, and was able to exploit it to great success.
It's one thing for crypto to be a fun thing where people can day trade on made up numbers, arguably harming 'no one', but when major transactions get problematic, then it's a huge source of pain. Civil and legal lawsuits galore.
It demonstrates that net-net crypto is a value destroyer and is just a bad distraction.
The moment we try to regulate it (and we would have to do this if we wanted to normalized it and make it usable in the commons), then 'all the fun' would be drained out of the bubble as it boils down to just regular banking, more or less.
It's like an intellectual 'Chinese Finger Trap' for smart people with a bit of money to burn, that has negative externalizes.
If it's going to be 'money' then regulate it as money, and watch it the Tower collapse under the weight of it's own complexity.
I just don't see a space for everyone to be happy: if we want crypto to be currency 2.0, it needs to be as unfun as possible, and then you get back to regular banking. If we want crypto to be fun, then we're never going to escape this cycle of "hype and fomo sees people chasing the next coin" to "lots of money went poof" and "someone got rich by making someone else poor."
There might be a little bit of a happy place, above where the boring banks hold on to their systematic control of the system, but a little below where crypto is now with some regulation.
But I feel by the time crypto is useful, that will mostly have converged and 'regular fintech' will provide most of the opportunity.
It's wild that markets can be manipulated inside essentially an uncommitted transaction.
This is the equivocation that is at the heart of smart contracts.
The promise of smart contracts is that "the code is the law". There is no need for trust, courts, or intermediaries. Of course his only works if the contract correctly implements a perfectly defined spec and has no bugs.
If one claims "the code is the law" they cannot claim it is a "hack" or "theft" when their code executes as written rather than as they desire.
This "theft" is an example of things working exactly as designed, and this seems to be an unfixable flaw in the concept behind smart contracts.