I'm not very technical, but I have a question.

Supposing that a Smart Contract is being upgraded to a new one, would it be possible in the new contract to not send new tokens to certain wallets?

So for example, if wallet XXXXX was a known storer of hacked funds, could wallet XXXXX not be sent tokens from the new contract?

  • If you're the one writing the new contract, then you can do whatever you like in it. – goodvibration Jan 22 '20 at 12:33

Yes. You can implement a simple logic in your contract for that:

For example:

 mapping(address => bool) public hacker;   
     function doSomething() public {

Supposing that a Smart Contract is being upgraded

Let's break that down. First, I think it depends on what you mean by "upgraded."

Explicit Administrative Privileges

A contract can be written such that it blacklists accounts. So, it would just input from a special user who decides who to blacklist, and everyone would see the procedure to blacklist someone and either decide to participate or not. There are good arguments for both scenarios depending on what you want to prove.

function blacklistUser(address badguy) public onlyAdmin {
  badguys[badguy] = true;

Elsewhere, make sure it's not a bad guy:

require(!badguys[msg.sender], "You are a badguy. Go away.");

That is admittedly oversimplified to just illustrate the concept.

In this case, the contract itself doesn't need an upgrade because it spells out, clearly, a special privilege an admin has in the context of the current contract.

Changeable Logic

Several patterns exist for enabling a change to the contract logic itself. That is to say, a way to make the old rules no longer apply and starting now, new rules.

Developers will call those Upgradeable Contracts. Upgradeability is obvious when it exists, in large part because it isn't trivial to achieve. The code to make it happen really stands out. I can't imagine a way to hide it from code reviewers because there's all this extra stuff.

I won't do an example because it's a big topic, except to say that the idea is to delegate logic to interchangeable parts, from the outset, and implement a way of swapping components later. Those methods of delegation and swapping of logic are very obvious.

In most cases, upgradeable contracts defeat the assurances of immutable software. Anything is possible because we can't be sure what the thing will do in the future.

A contract that is not upgradeable cannot be transformed into one that is. That is to say, if the signs of upgradeability are not there, then you can be assured that the rules will not be changed.

If you are interested in this topic, you might take a look at this overview with links to more information: https://medium.com/hackernoon/trustless-upgrades-in-solidity-bf0bd4047d28

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.