Is there a possiblity to unfreeze a frozen account in the EOS protocol (or is it frozen forever once frozen) and if so how many BP need to vote unfreeze to unfreeze an account?

1 Answer 1


All these mechanisms for freezing accounts and enforcing ECAF rulings in general are being worked on and decisions need to still be made on the way that it's going to work in the future, but generally speaking:

  • Yes, it is entirely possible to unfreeze an account after it's been frozen.
  • The general answer for how many BPs need to vote for something to happen is what is referred to as a "supermajority" which is two thirds of the total number of BPs, plus one. Considering 21 total BPs, this would mean 21 * 2/3 + 1 = 15 BPs.
  • This also depends on how the account was frozen in the first place:
    • Accounts can be blacklisted in the nodeos configuration file on a per-node basis, and this makes that specific node reject all transactions related to that account. The issue with this is that it happens off-chain, on each BP's node configuration, so there is no enforcement of consensus over what accounts should be frozen. It has even happen that some BPs block an account while others don't.
    • Accounts can be frozen by temporarily taking ownership of the account itself by setting the owner permission on it to the eosio or eosio.sudo accounts, or any other privileged account that needs the signatures of the supermajority of BPs. This mechanism would be also reversible, more reliable, and more legitimate, since it would require the supermajority of BPs to be executed.

Time will tell how these things will actually play out in day to day governance of the blockchain, so it's an exciting time to also offer your opinion and participate in the debates in the governance telegram channel and other places.

EDIT: In answer to your comments:

First of all, you only get your account frozen if there is a bug in the code of the smart contract that is deployed there or if there is an ECAF ruling against you because of breaching the terms of your ricardian contract or generally some bad behavior that needs to be stopped.

Secondly, this doesn't work like in Ethereum or other blockchains: - Your transactions aren't "mined". They are included in blocks that get produced. - The elected block producers agree on a kind of "block production plan" or schedule for the next set of blocks, so they decide which of them is going to produce which blocks at which time.

If your account is blacklisted by 20 BPs and just one forgot to blacklist it, then you would need to hope that your transaction is relayed through the network pretty much directly to that specific BP so that it won't get rejected by anybody else who did blacklist your account.

I'm not sure what you mean by blacklisting off-chain being more "trustless", since clearly in this way everyone in the network would need to trust that all the BPs are doing their job correctly and blacklisting what should be blacklisted. Doing it on-chain gives you a trustless guarantee that a blocked account won't be able to continue to do harm.

Currently there are various on and off-chain implementations for blocking or freezing accounts or broken/buggy smart contracts, what I meant before is simply that there is no community consensus yet about what the standard procedure should be for different cases that might need this.


In response to your new comment explaining that in the on-chain supermajority based method you as an individual would need to trust that the BPs don't arbitrarily freeze your account, I can say the following:

In the design of EOSIO and specifically DPoS (Delegated Proof of Stake) consensus, the token holders control their own votes, and they can (and should) vote out of power the BPs that are doing things that go against the constitution. The constitution and the Block Producer Agreement specify what exactly are the rules for BPs and when they are allowed to freeze an account. They can't simply freeze and account or block a transaction out of personal preference, even if they form a supermajority with that preference, since they would be breaking their BP agreement and would be voted out and most likely severely penalized for that behavior.

You can count on the voters voting them out because same as you, they don't want to be censored and frozen arbitrarily and they don't want BPs doing whatever they please against the constitution.

The issue with the off-chain blacklist is that it is arbitrary, since each BP can choose to put whatever they want in their own blacklist. It also doesn't fully work unless all of the BPs sync their blacklists. If they are not all blocking the same accounts, it would just make it more annoying for those accounts to operate, but they could still operate, so it's not a good solution for when you really need to block an account.

  • When it's in the consensus and you need a supermajority to unfreeze that is by far less trustless then off-chain. Imagine you get frozen by BP set A then you need a change of at least 1/3 of the BP set to get your tx through. In contraty with the off-chain approach you just need 1 BP to mine your tx.
    – Ini
    Commented Jul 26, 2018 at 14:35
  • I assume in the consensus approach you would need a supermajority to unfreeze right?
    – Ini
    Commented Jul 26, 2018 at 14:36
  • Currently there is nothing in the consensus in regards to this right and just 1 BP need to mine the tx that other consider to be from a frozen account (off-chain)?
    – Ini
    Commented Jul 26, 2018 at 14:38
  • 1
    @Invader I updated the answer in response to your comments. If you find that this answers the question you created, please mark the answer as accepted so that others can benefit from it too. Thanks! Commented Jul 26, 2018 at 14:57
  • I mean trustless in the sense that it's more unlikely that your account gets frozen. Note that I'm not worried currently about my account getting frozen, I just want to analyze the properties of the current protocol.
    – Ini
    Commented Jul 26, 2018 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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