Hacker News new | past | comments | ask | show | jobs | submit login
Binance Smart Chain DeFi Project Hacked for $31M (cryptobriefing.com)
141 points by capableweb 40 days ago | hide | past | favorite | 111 comments



I found it strange that the title and beginning of the article reffered to this as a "hack" instead of what the test of the article suggests - a rug pull by the developers themselves.

Since everything has been scrubbed the only suggested that they've been hacked comes from a cropped screenshot of their telegram channel which I found in this article: https://obelisk.medium.com/meerkat-finance-and-the-0-that-wa...

The article also clearly shows in the smart contact that this was premeditated.

Edit: It's also important for context to note that 31 Million TVL (Total Value Locked) isn't low but isn't high for a DeFi project.

You can get a sense of the TVLs by looking at other projects on Ethereum ($39B total https://defipulse.com/) and the Binance Smart Chain ($9B total https://www.defistation.io/)


In short the backdoor is the following:

  bytes32 internal constant ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103; 
  
  // this is the getter
  function _admin() internal view returns (address adm) {
    bytes32 slot = ADMIN_SLOT;
    assembly {
      // return the memory at slot
      adm := sload(slot)
    }
  }

  // notice the 0 and the different, off by 1 hash
  bytes32 internal constant ADMIN_SL0T = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6102;
   
  // this is the setter, this doesn't set the same value as the getter, in effect the admin cannot be changed 
  function _setAdmin(address newAdmin) internal {
    bytes32 slot = ADMIN_SL0T; 

    assembly {
      // set the memory at slot to the value of newAdmin
      sstore(slot, newAdmin)
    }
  }
https://bscscan.com/address/0x7e0c621ea9f7afd5b86a50b0942eae...

Then when you (indirectly) call _setAdmin you can pretend that you no longer have powers to upgrade the contract.


I was ready to make fun of this, but damn, that's fairly clever. (Readers, be sure to read the actual code: https://bscscan.com/address/0x7e0c621ea9f7afd5b86a50b0942eae...)

A casual glance through the code won't show anything amiss. The ADMIN_SLOT and ADMIN_SL0T are defined in very different places.

SL0T is also the closet fake character you could use, except maybe ADM1N_SLOT.

Then when you (indirectly) call _setAdmin you can pretend that you no longer have powers to upgrade the contract.

I know nothing about smart contracts, though, so, question: why is that a backdoor? What does it mean?


To understand why this is a backdoor we need to look at more code:

  modifier ifAdmin() {
    if (msg.sender == _admin()) { 
      _; // run the rest of the function being modified 
    } else {
      // for our case this essentially does nothing 
      _fallback();
    }
  }

  // imagine the code inside the function in place of the _ in ifAdmin
  function upgradeTo(address newImplementation) external ifAdmin {
    // actually upgrades the contract in place
    _upgradeTo(newImplementation);
  }
So this smart contract has the ability to upgrade itself in place if it is called by the administrator. This is widely accepted and normally a useful feature. As a gesture of goodwill a developer will relinquish control of the contract for a set amount of time via a timelock. During this time users can use the smart contract without worry that the developer will maliciously upgrade and steal their funds.

This can be seen here: https://bscscan.com/tx/0xecd169b3a299d28495cbc9bd22b5690e263...

So here it looks like the administrator was changed but as we know it actually didn't. Now users begin to use the platform and deposit funds.

Since the admin hasn't changed the developer calls upgradeTo and deploys a malicious change, seen here: https://bscscan.com/tx/0xf19fa4bcff4adaebeddd28c851458ba0f01...

This contract (https://bscscan.com/address/0xb2603fc47331e3500eaf053bd7a971...) is compiled so we can't easily see the source. This doesn't matter as we can easily see the resulting transactions (https://bscscan.com/tx/0x1332fadcc5378b1cc90159e603b99e0b73a... and https://bscscan.com/tx/0xd8145dfe255a671428b9c082a006a145fe5...).

Whats especially clever about this rug pull scam is that it is self contained. Instead of selling your tokens at an exchange which risks low liquidity and front running, the developer is in control the whole time and could have done this whenever he thought the deposits were enough.


Is there some way to contact you? I just wanted to say privately that I recognized how much thought and effort went into this, and I’m grateful you took your time to share it. But mostly, I was feeling kind of down today and wondering what your life was like, and how you ended up getting into smart contracts. No reason really, just saying hello.

You can DM me on Twitter if you’re on.


Glad you found it useful! Smart contacts are intersting stuff.

Your best bet is probably a reddit pm (not their new chat feature), my username is the same. I should get twitter but it's one of those things I never really got into.


This was a masterclass. Thank you so much.


So I take it that no independent 3rd party audited this smart contract? Because defining a constant twice is already big enough of a code smell to warrant spending more than 10s on them (enough to distinguish a 0 from a O). They didn't even try that hard, e.g. "SLΟT" is way closer to "SLOT" than "SL0T". This speaks volume about how much you can get away with in this ecosystem.

That's also a vulnerability which should have been exposed by tests (again, run by an independent 3rd party).


That's correct. Even any of the off the shelf tools would have spotted it so it's safe to conclude this was intentional.

Audits aren't the be all end all either, a determined scammers could have added the backdoor after the audit.


> The article also clearly shows in the smart contact that this was premeditated.

It's almost as if having a readable contract that the signers can all understand and a judge who can rule on reasonable interpretations of the contract is a feature, not a bug.

Whatever component of the "smart contract" that allowed them to do this would have been negotiated out, but since it's a decentralized "the contract enforces itself" cryptosystem, people just trust that the contract does what it says on the tin.

What should be the procedure before using these? Pay a security researcher for an independent review, like you would have a lawyer go over a contract? If you have to do that, why not just use a regular contract and lawyers where you have recourse when something goes wrong?


The use of the term "contract" in computational blockchains like ethereum and binance smart chain is a bit of a misnomer. They aren't actual contracts in the sense that they are agreements between 2 or more parties. They are simply small scripts/programs that execute on the blockchain.

Gotta say though, the choice of the term "smart contracts" was great marketing.


Calling them simply scripts/programs is also a bit of a misnomer.

It's easier to think of them as the rules to a game, like chess. The smart contact defines the pieces and valid moves. The EVM enforces the rules.


A smart contract is literally code. It compiles to a bytecode that is executed on a turing-complete virtual machine (EVM) within a restricted environment (the blockchain).


Yes, but that doesn't capture the nature of the EVM, specifically addresses.


It's pretty analogous, particularly with other colloquial uses of "contract" like "contract of an API" and "design by contract". A smart contract is simply a guarantee that "if you do this, the outcome on the blockchain will be that", where "this" is defined by the method signature and "that" is defined by the smart contract's code.

A contract between two people is fundamentally an agreement that "If you do this, then I will do that", enforceable by law. It exists to allow trust: if you have no way of knowing what the other person is going to do in response, why would you ever do something like give them money or perform services for them? With smart contracts the legal system is replaced by a worldwide network of computers, and the actions that you can guarantee are restricted to quantities or properties represented on the blockchain. But the basic motivation and principal are the same: you want to provide guarantees about the future so that people can take mutually beneficial actions with them in mind.


But they had a readable contract and it wasn't a bug but a backdoor.

If we took this take into your analogy this would be a scam artist solicitating funds and having a contact cause that has a loophole. Investors signed without reading and loose their money.

A judge could only rule after the fact and if the scammers left the country with the money the ruling wouldn't bring the investor's money back.


How can there be a backdoor in a smart contract? Aren't they necessarily readable in full (even if the behavior is obscure)?

If I understand correctly, there can't be any actual secrets; you have to read carefully, then caveat emptor.


Backdoor with a loose tarp blending it into the wall.


> Pay a security researcher for an independent review

Yes, that is the normal practice, and any bigger project worth their salt pays for an external security auditor.


Do we know that this project wasn't audited?


What is generally audited is the source code. You can then verify is that the audited source code matches the deployed source code. That ability is lost to some degree (or not as transparent) if you use upgradable proxy contracts (which Meerkat did). Given the young age I don't see any indication that anyone audited the proxy contracts and their usage.

As explained in the blog post of the top comment here (https://obelisk.medium.com/meerkat-finance-and-the-0-that-wa...), this was clearly an exit scam by the Meerkat developers, which is exactly why users shouldn't put any significant amount of money into contracts that haven't been audited by a reputable external auditor.


According to media reports, the Meerkat Finance team made a brief note about the hack in Telegram but have since disappeared from all social media platforms. Their website and Twitter accounts are disabled, and the Telegram group is now deleted too.

Distressed users have reached out to Binance CEO Chanpeng Zhao, hoping that the CEO can track down the money. CZ has not replied to any comment on Twitter.

Know that feeling. Welcome to Mt. Gox in 201x.

Go stare at a lake and make peace that your money is gone.

(Then post loss porn so that you can get a few internet points out of it.)

By the way, as a registered member of Mt Gox, I was able to view every single claim posted by every other Mt Gox user, which was very surprising. It's essentially a giant table of confirmed claims, with 2,000 pages. You can hardly scroll more than a page before finding someone with a confirmed claim of ~1,200 BTC or so.

So, take comfort that there are always bigger losses. :)


The different is that Mt Gox was run by a wildly incompetent guy. This one was just a plain scam. Especially back in 2013/2014 I have personally managed many exchanges "disappear". The excuse was usually that they were hacked, but it was clear they were just scams where the founder ran off with the money. It highlights the importance of regulation.


* It highlights the importance of trustless systems

Not your keys not your coins!


I don't have the keys to my bank...


Your bank is regulated and insured.


Which still does not prevent it to block you from your money in the event of a very sharp recession or depression to "avoid bank runs". It has happened every time in every country where the government actions have fucked the economy. The people are the ones that pay.


And if the government decides to outlaw bitcoin, not only will it become a lot harder to access it from services or trade it for goods, but the value of the coin will plummet rapidly.


Just off the top of my head, didn't Binance do exactly that in like the last 10 days or something (with ETH, iirc)?

I don't think it's an argument against some kind of regulation/consumer protection. Pretty much everyone I know (in the UK) has banked safely for most of their life. Pretty much everyone I know that's touched crypto (me included!) has a story about losing something.


That's fine. Your bank doesn't pretend to be decentralized. Cryptocurrencies do. And in doing so, shift the responsibility of safeguarding the keys to the user.


I wasn't making a point about centralised or decentralised currency/money/finance?

It was regarding the 'regulation' thing. Cryptocurrency is only ever going to work for John Everyman if the industry starts to mature a bit. Blaming the user when another exchange gets ripped off doesn't exactly scream 'legit', does it?


Coinbase also doesn't pretend to be decentralized and the bank analogy holds pretty well for them.

I'm not sure it's meaningful to say cryptocurrencies are decentralized. Decentralization is more of a social phenomenon than technical, e.g. cash is decentralized but socially we've found advantages to centralize.


Cash is most certainly not decentralised, unless you are using some uncommon definition of 'cash'


How is cash not decentralized? I can pay anyone anywhere for anything and I don’t need any centralized infrastructure.


The issuance of gold is decentralized. The issuance of cash is centralized, unless you believe in counterfeiting. However, the transacting and storage of both cash and gold are decentralized.


The centralized issuing authority can decide overnight to make the cash worthless. This happened fairly recently in India, for example.


Makes you think


Don't we already have laws against fraud? Unless by regulation you mean preempting any chance of someone running a scam?


This is BSC we're talking about here. All Binance needs to do is blacklist those funds, after-all, they control the consensus of their network.


What's the point of difi when it's running on a centralized ledger?


Changpeng Zhao himself called it "CeDeFi", "Centralized Decentralized Finance" while talking about it on Clubhouse.

As to the point of it, it's mostly about recycling the existing Ethereum ecosystem of dApps and allowing less wealthy people to play with it, even if the original motivation for it is lost. Kind of like a testnet network, except people put real money on it, and influencers mislead people about its real nature.


Exactly


Can they blacklist addresses/funds directly on the blockchain itself with smart contracts?


Since it is assumed that Binance owns the validator they could simply blacklist the address from ever making transactions.


I assume that before they can do that these funds will go through a bunch of other smart contracts, be swapped for monero, mixed a bunch of times and eventually cashed out.


You seem to mix-up "smart contracts" and the platform on which they run. On BSC, Binance effectively controls all smart contracts, since they control the chain itself. And given that all bridges with the outside world are also centralized in a way, the only way for the scammers to cash out would have been to swap before anyone notices.


If you're interested you can follow the funds yourself: https://bscscan.com/address/0x9542966f1114eaa5859201aa8d3435...

As far as I know BSC doesn't have any mixers, nor aomtic swaps exchanges.


Sooo what’s to stop them from doing this anytime they want for any reason. I’m out.


Financial incentives, lost of trust?

Ethereum once rolled back their blockchain for the DAO hack. The price dropped 25% and ethereum was forked into ETC.


If it's indeed a scam, people that lost their money should pool some money, hire a law firm, and sue.


I lost quite a bit on btc-e, but in that case our government stole it.


Binance website states : What are the advantages of DeFi Staking? 1.Easy to use: You don't need to manage private keys, acquire resources, make trades, or perform other complicated tasks to participate in DeFi Staking. Binance's one-stop service allows users to obtain generous online rewards without having to keep an on-chain wallet. 2. Funds are safe: Binance selects only the best DeFi projects in the industry and monitors the DeFi system in real-time while it's running in order to reduce the risks associated with such projects.

Then go on to say : Does Binance bear the losses if an on-chain contract is attacked during DeFi Staking? No. Binance only acts as a platform to showcase projects and provide users with related services, such as accessing funds on behalf of the user and distributing earnings, etc. Binance does not bear any liability for losses incurred as a result of on-chain contract security.

--- So if you don't have the keys, and there aren't liable, that's a bit messed up.


That's a different service than "Binance Smart Chain" which is the subject of the article. On "DeFi Staking" users lend tokens to Binance that they then stake on actual decentralized chains like Ethereum for instance, so if they or the smart contracts they stake through fail, Binance really can't do anything for their users.


> Binance really can't do anything for their users

BSC is controlled by an oligopoly of validators that Binance decides on. I'm sure if things really got bad on their network they could do something similar to the Ethereum Classic fork during the DAO incident.

EDIT: My bad, I skipped a few words in parent.


Liability is a legal umbrella- I'm fairly confident they will at the very least freeze these funds (which isn't much for rug-pulled users but it's something). It's a federated network so well within their ability.


“Funds are safe” seems like a pretty good basis for a lawsuit.


Since the OP didn't include a link I'm assuming "Binance one-stop platform" is a vetted subset of all Binance Smart Chain platforms. In the case of this article I'm pretty sure Binance has not endorsed the "hacked" platform. I think the BSC is an open network and anyone can create their own smartcontracts in there. A popular new platform on BSC goosedefi has been forked hundreds of times, and most of them have failed within days with either developers or early users dumping the price. It's a big risk putting your money on any of these platforms, most of them are basically elaborate ponzi schemes promising big APR but leaves people bagholding a worthless token. A very few lucky platforms with good developers go on and become stable established defi platforms like sushiswap.


Fascinating that using a 0 (zero) instead of an O let them backdoor this.

function _setAdmin(address newAdmin) internal { bytes32 slot = ADMIN_SL0T;

    assembly {
      sstore(slot, newAdmin)
    }
  }
https://obelisk.medium.com/meerkat-finance-and-the-0-that-wa...


So basically an homograph attack, in this case to dodge code reviews?

This reminds me of Bruce Schneier's article "Unicode is too complex to ever be secure", except in this case ASCII too apparently ; )

Which makes me wonder: for such sensitive programming languages, shouldn't the specs be much more restrictive and for example only allow 'A' to 'Z' in variable names, no digits, no lowercases, etc.?


Or shouldn't there be a linter as part of the standard tooling which warns if there are two variables or functions with similar looking names? It could also check for similar looking hex strings, which would have caught the off-by-one hashes.


I bet there is likely more people working on stealing from these defi projects than people creating them. Probably more capital efficient too.


> I bet there is likely more people working on stealing from these defi projects than people creating them.

Not really considering it's usually the same people.

Who better knows the weird edge cases of the code than the devs themselves :) And after all, it's not theft because code is law :)

/s


I expect you are right. But the hostile environment does eventually promote better security and safety practices.


Only insofar as Darwinism comes into play and vulnerabilities kill unsecure projects. It doesn't look like new projects are safer than older ones.


This was a rug-pull, not a hack. The actual hacks you'll see today are significantly different from those of last summer so there's been some measurable progress.


> This was a rug-pull, not a hack.

Who the attacker is does not matter. This comment seems to describe the vulnerability (intentionally implemented, but again, it doesn't matter) as a homoglyph attack: https://news.ycombinator.com/item?id=26358767

Homoglyph attacks are not new. Even for Solidity, they are at least 4 years old: https://github.com/Arachnid/uscc/tree/master/submissions-201...

> // The e in the 'refunds' string is the unicode char U+0435, also known as Cyrillic small ie

> uint weiAmount = balances['rеfunds'][msg.sender];

(from the README)

> The actual hacks you'll see today are significantly different from those of last summer so there's been some measurable progress.

They might or might not be different, the fact remains that they have gained little in sophistication, which would be a more relevant measure of progress. As I mentioned in another comment, this is not the kind of flaw that would have passed a diligent 3rd party audit, and yet the thieves got $31M from it.


"Hey if you give me $100 I'll invest it for you"

"OK, here"

"Oh oops someone stole it, that's too bad for you, oh well bye!"


Usually it works better if you are looking for someone to invest in. You have to find the projects that need your money because only scammers and sales people are good at reaching you otherwise.


I still think smart contracts are pretty stupid for your everyday person that wants their government to make them whole when they get fleeced.

The whole idea of contract in a legal sense is a human construct.

The age old bitcoin joke is that loans are gifts. I’ve used bitcoin for a decade and never touched binance. Mt. Gox creditor never bothered filing a claim either.

I could tell you stories about 10 other domains and sites that were trusted that did the same thing. Not your keys, not your coins; not in funny internet money land.


Smart contacts doesn't prevent people from investing in ponzi schemes. What smart contracts do provide is a stricter framework to express guarantees.

A good example of a real, everyday use case for smart contracts is NBA Top Shot. Unlike regular collectable the smart contact guarantees the company cannot decide to manufacture more of a rare item, it allows verification of the supply and traded value.

A lending contract like Aave simply formalises the economic contracts behind lending. By doing so it can provide stricter guarantees about enforcement. It's not so much of a contract but a strict set of bindings that the EVM will enforce.

If you've stayed away from binance perhaps you've used or hear of atomic swaps? They're especially smart contacts that aren't tied to any chain. A strict set of rules and moves to guarentee that the contract of swapping is withheld by both parties.


Doesn't diminish your point in itself, but NBA Top Shot is a bad example since it runs on a centralized chain (Flow) and even recently had drama about a user being locked from withdrawing their funds [1].

There are tons of ways trust assumptions about smart contracts can be misunderstood. The current general education level about crypto seems similar to when snake oil sellers where sprinkling "artifical intelligence" in their products to make them "smarter". A drip of "blockchain" and suddenly your product is "trustless".

[1]: https://defited.medium.com/my-centralized-experience-dapper-...


I did not know this, thank you for brining it up! From the story it looks like this is the classic issue of bridging blockchain with the real world.

Am I right in understanding he's trying to withdraw USDC from Flow to Ethereum (https://support.meetdapper.com/hc/en-us/articles/36005912467...) and requires KYC and the process is actually centralised?

I'd have imagined that Cricle would have build a decentralised flowUSDC-ethUSDC bridge but perhaps there's a regulation reason which also explains the KYC requirements.

If this is the case, hopefully someone else can pick up the slack and create a Flow-Eth bridge/atomic swap.


Is there anything preventing them from creating multiple instances of the same "moment" in Top Shot? If not I don't see why the rareness of items in Top Shot is just an illusion.


What would you think of a smart contract that acts trustlessly 99% of the time, but has an escape hatch governed by a set of more or less decentralized/authoritative entities in a multisig?

We already have an escape hatch for generalized catastrophic events in the form of hard forks, but I expect in the future more fine-grained schemes to manually resolve local issues will become the norm.


Shameless plug, I have a pet project that rates assets by their risk of getting rug pulled: https://rugpullindex.com

It's only working for a small set of pools right now.


Highly recommend https://www.rekt.news/ for reports on crypto hacks and rugs.


It looks like it's an "upgradable contact" that means the admin can do whatever they want with funds you send there. No exploit or hack needed to lose your funds.

Really I'd say that project just isn't DeFI, but an on chain hedge fund. DeFI is usually non custodial meaning that the creator doesn't have the ability to touch your funds.


The exploit is pretending to time lock your admin powers whilst still retaining them.


The article makes it sound like a smart contract was hacked. Which is not possible under a "code is law" perspective.

Will be interesting to see what really happened.


It was an intentional backdoor in the contract.

https://bscscan.com/address/0x7e0c621ea9f7afd5b86a50b0942eae...

Note line 304 the O is a 0:

bytes32 slot = ADMIN_SL0T;


Holy crap you're right.

This is like in Java, where you mean to override a method in a superclass but mis-spell the name of the method and therefore instead end up simply adding a new method with the mis-spelled name.

I guess either Solidity doesn't have something like Java 1.5+'s @Override, or else it just wasn't used.

In any case it's hard to believe this was accidental. Of all the places you could make this mistake, most of the others wouldn't result in a massive exploit like this.


I don't think anyone would consider an accident possible after they stole the funds.


Well there have been other accidental bugs (reentrancy, for one) that got exploited by thieves who turned out not to be the devs.

But I agree, that's not what happened here.


Can you elaborate on this? How does swapping out O for a 0 introduce a backdoor?


You can find the details in this article (not written by me): https://obelisk.medium.com/meerkat-finance-and-the-0-that-wa...

In short:

* the smart contact is made in a way that allows upgrades by an administrator * the developers transfer their administrator privileges to another user as a show of good faith * the code to transfer the privileges actually doesn't do anything * the developers upgrade the contract giving themselves permission to take the funds


Looks to me like the 0 breaks the functionality for setting a new admin. It dosn't directly break any permissions stuff, and in fact I don't think it leads to a backdoor itself.

Then elsewhere on line 50, anybody who creates a Proxy object will automatically be made the admin with zero auth.


This is definitely the funniest thing I've read this week.


Given that all forms of communication with the team are dead, it sounds like a standard exit scam to me.


You are correct, here is their smart contact code which has been verified: https://bscscan.com/address/0x7e0c621ea9f7afd5b86a50b0942eae...

Note line 304 the O is a 0:

bytes32 slot = ADMIN_SL0T;


What does this obfuscation accomplish? Is ADMIN_SLOT some sort of standard constant?


No, but it’s one they set in the code:

comment: @dev Storage slot with the admin of the contract. This is the keccak-256 hash of "eip1967.proxy.admin" subtracted by 1, and is validated in the constructor.

     bytes32 internal constant ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103;


So by using ADMIN_SL0T instead was it just set to null or something?


Perhaps it will be clear if I move all of the code together and add comments:

  bytes32 internal constant ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103; 
  
  // this is the getter
  function _admin() internal view returns (address adm) {
    bytes32 slot = ADMIN_SLOT;
    assembly {
      // return the memory at slot
      adm := sload(slot)
    }
  }

  // this is the setter, notice the 0 and the different hash
  bytes32 internal constant ADMIN_SL0T = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6102;
   
  // this doesn't set the same value as the getter, in effect the admin cannot be changed 
  function _setAdmin(address newAdmin) internal {
    bytes32 slot = ADMIN_SL0T; 

    assembly {
      // set the memory at slot to the value of newAdmin
      sstore(slot, newAdmin)
    }
  }
https://bscscan.com/address/0x7e0c621ea9f7afd5b86a50b0942eae...


Strange to me that the constant was defined in two places. I guess it would take a careful code review to notice that.


I have no idea how the language or VM works, I guess the important part was that it wasn’t the right constant ;)


That's right, they've tried to obfuscate that their setter doesn't actually set. https://news.ycombinator.com/item?id=26358876


You mean they put a backdoor into their smart contract? Or did they hold the money off chain?


It wasn't a back door. They modified the smart contract and drained the crypto.

> The hackers implemented a change in the ownership of the smart contract address.


This is incorrect, unless you can argue that they were so incompitent they wrote '0' instead of 'O' on line 304:

bytes32 slot = ADMIN_SL0T;

https://bscscan.com/address/0x7e0c621ea9f7afd5b86a50b0942eae...

These kind of rug pulls are more uncommon but not rare, they give the developers some level of plausible deniability. Even so their actions after speak volumes.


Smart contracts are immutable. How do you mean they "changed" it? What is "ownership" of a smart contract?


You can write smart contracts which are upgradable (by moving the assets/tokens to a new address with new code). The upgrade to a different contract can either be triggered by votes or by the author depending on the setup.


It's possible in the sense that the code might not reflect the intentions of its creators due to an oversight.

What's interesting is to see how it will be dealt with. Most "DeFi" and cryptocurrency aficionados are quick to claim that "code is law", so we'll see whether they change their minds when their own money is at stake.


    code might not reflect
    the intentions
So now we need human judges to judge what the intention of a smart contract is?


> So now we need human judges to judge what the intention of a smart contract is?

Well, wouldn't it already be quite a win if for 99.9% of the smart contract out there no human judge was needed?

It's an honest question: ain't it unthinkable that most could be fully automated and yet real courts could be used in rare cases and that that'd be already be quite an improvement? Or is the system only working if 100% of the time no human ruling is needed?

I have no idea...


Smart contact development is mostly out of the wild west that you're describing. Development tools and standards means that these cases where funds are directly syphoned are now quite rare. In this case this was a intentional backdoor left by the developer.

Most modern DeFi exploits take advantage of unintended interactions between multiple smart contracts.


Code is law + Extreme Ownership is all you need


Assuming you mean something from that bestseller, could you sum up what's "Extreme Ownership" in this context?


I’m not sure this applies to Binance Smart Chain. It is a centralized service providing cheaper, centralized DeFi. Centralized services don’t need to follow “code is law” since they have actual laws they have to follow.


yet another Bernie Madoff coin, as in they made off with my money


I have no knowledge of the attack nor am I familiar with how it happened, but it sounds like the founders could possibly be involved in this.


> provide services allowing for users to leverage their position while staking

yes, this totally sounds not made up




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: