Lately there has been a lot of talk about the "stalker attack." It’s a very high-risk attack for the person conducting it to the point that it makes no sense financially. Perhaps if someone has too much money and wants to annoy someone they can attempt it. But still they have nothing to gain and a lot to lose as this post describes.


The "attack" is as follows. A malicious DAO Token Holder will spend countless hours making bots that will vote in split proposals where the amount of tokens at stake is less than the amount of tokens the malicious DAO Token Holder is comfortable losing.

Splitting is a multi-step process. First the "victim" must create a proposal for a new Curator and vote for it. In most cases, the victim will set themselves as the new Curator. After the debate period ends the victim can see who voted yes on their proposal, only these DAO Token Holders can burn their DAO Tokens to join the newDAO. If only the "victim" voted for the proposal (as expected) or if the "victim" has a more than 50% of the vote, then the stalker attack cannot occur.

If the victim does not have a majority of the votes and calls `splitDAO()' to create their new DAO anyway, a malicious attacker can also call it and they will both end up in the same child DAO with the victim being the Curator but not having the majority of NewDAO tokens.

From this point on both the victim and the attacker are locked in a stalemate. The attacker will need the victim to add them to the whitelist so they can get ETH out of the DAO, and the victim will need the attacker to fail to vote on their proposal so they can get their ETH out of The DAO (the assumed purpose of splitting in the first place).

The attacker can only get something out of this if he can blackmail their victim by promising them a portion of the original ETH they were supposed to receive while keeping their own funds and a portion of the victim's ETH.

A problem with any such proposal is that the victim has no reason to trust the attacker. The attacker would likely achieve nothing, apart from locking up their own funds along with their victim's funds in the new DAO. Furthermore the attacker must constantly check new proposals and vote them down to ensure the user does not try and get their tokens out. Check out the next 2 sections to see how to prevent the attack from happening and if it happens, how to solve it and rob the attacker.


The prevention of the attack is quite straightforward. Before calling splitDAO() make sure that none else apart from you has voted in this proposal. If someone else did, then don’t callsplitDAO(). The UI that will be offered by us for voting will actually include a warning for that, by checking if you are trying to split and if other people will follow you in the split.


There are two main ways to address this attack. We will detail them here one by one.

Robbing The Attacker

If you do end up in a stalker attack situation in your new split DAO there are 2 ways to counter-attack it and rob the attacker of his money. The first way is quite simple, but can also be repelled by a smart attacker. The second one is a little bit more complicated and leaves no escape for the attacker. We will describe both situations below. If you do end up in such a situation and want to repel the attacker we would advise going with the complex scenario.

The simplified scenario

If both you and the attacker are in the new child DAO then you can repeatedly callhalveMinQuorum() so that you can pass any proposal you want with as little tokens as possible. If the attacker is smart he can also make proposals all the time to reach the minimum Quorum and as such get it back to the original.

After that you need to separate your tokens into 2 different accounts. One with as little tokens as required to pass a proposal (remember you can halveMinQuorum() as much as you want, you are the curator) and the other with the rest of your tokens.

Subsequently you can add yourself to the whitelist, make a proposal to send all money to yourself, with proposal debate period ranging from 35 to 56 days and vote on it with the account holding the least tokens. This proposal is very dangerous for the attacker.

If he does not downvote it he will lose all of his money. So let’s assume he does that. The minute the attacker downvotes the proposal his tokens will be blocked and he won’t be able to execute any subsequent splitDAO().

To end it all then you make a new split proposal with minSplitDebate period of 1 week and vote on it. This would give the attacker 34 days to try and join you in your new split attempt. Unfortunately for him even if he votes for the split proposal, he would not be able to callsplitDAO() in time because he would be blocked by our other proposal to transfer all of the money to yourself.

The final result of this would be: 1. The attacker’s money is stuck alone in a DAO where he is not the curator. All his money is lost. 2. The attacker can no longer get rewards from the parent DAO. 3. The “victim” has most of his/her money out safely in a 3rd DAO from where he/she can forward them wherever he/she wants. 4. The “victim” also has enough tokens back in the 2nd DAO to make the attacker’s life miserable so that he/she can make more proposals and keep trying to steal all of the attacker’s money and since he/she is still the curator of the 2nd DAO can also claim rewards of the original DAO as soon as the attacker is dealt with.

The complex version of the scenario

To counterattack the scenario above the attacker could also start separating his tokens accordingly to keep enough unblocked to be able to still block you. In that case what you as the victim can do to rob the attacker is:

  1. Make 10 accounts and send a tiny amount of DAO tokens to each one.
  2. An 11th account keeps all of the rest of your DAO tokens.
  3. Make 10 different proposals to send all the money to yourself.
  4. In the last possible block you move all your tokens from the 11th account randomly to one of the 10 accounts that made proposals and vote for it.

At this point the attacker is cornered and all of his money is going to be lost. He could have a script, which is scanning the network for all pending transactions and try to "guess" where the victim is going to vote and try to follow him. Due to the fast block times and the way the ethereum protocol works, this is not guaranteed to work. He may manage to do it once, maybe twice but the one time the timing is wrong it's game over for the attacker.

The end result is that the victim robs the attacker. The attacker can also decide to split again to save himself. Then he will lose all rewards from the mother DAO, while the victim will get at least twice the rewards, since he will also have the victim's rewards.

The attacker has no guarantee that he will always get the transaction in the right block. The first time he fails he loses his money. The likelihood is that he will fail. Given that the attacker has to win every time and the victim has infinite attempts. It becomes a certainty that he will escape.

Split at the last minute

One way to make sure that nobody will follow you to the new DAO is to wait until the very last minute to split. Say that both you and the attacker have voted for the split proposal. The attacker’s bot would be waiting until you call splitDAO() so that after that he can call it himself and join you.

There is a period after which you can no longer call this function. That period issplitDebatePeriod + splitExecutionPeriod. With the average block time being 15 seconds that gives you about that much time to make the splitDAO() and make sure it goes in the very last block before the splitExecutionPeriod expires.

The attacker would need to wait for this block to be mined in order to see that you actually calledsplitDAO() and then he will try to do the same to join you. Only he won’t be allowed to do so, since we would be after the period where calling this function would be allowed.

So as a result you would safely be split alone in your own solo DAO.


The stalker attack, though sounds terrifying is a non-issue since it makes zero-sense for the attacker as we have shown above. That point aside, the very conversation around the topic proves that one of the first features a DAO 2.0 should have is a “solo split” option.