What the First Token Hostile Takeover Could Look Like
We are at the earliest stages of reckoning how token-based networks interact with each other. Much like corporations, they will begin to compete, merge, acquire, attack, and partner with one another. The dynamics of these interactions will in some cases closely mirror those in the traditional financial world, and in some cases entirely new paradigms might emerge. Here, we’ll examine one in the former category: a hostile takeover (think: AOL buying Time Warner), and how this might be enacted in a world of tokens.
Token networks are activating en masse with real use cases for the first time as the ICOs of 2017 turn their projects live. There will be more and more incentives for competition to attack them — and it’s worthwhile to anticipate those movements.
I write this not particularly to encourage anyone to do this — but in an effort to raise awareness around how corporate governance and interactions will evolve in this new ecosystem and encourage more thought and discussion around the same.
For ease of demonstration, we’ll consider an imagined ERC-20 token, BandwidthCoin (ticker: OLD), which allows users to share bandwidth and transact using OLD. Our attacker will be FinanceCorp, which wants to replace the OLD network with one of their own that they manage development for and where any tokens owned by the OLD team are instead owned by FinanceCorp, giving them the upside.
Here’s our blueprint for a hostile takeover of a token network. More detail to follow.
- Coordinate with key suppliers
- Raise public awareness
- Execute the fork
- Airdrop to drive users over
- Bonus step: Sell into the market
Step 1: Coordinate with key suppliers
First, FinanceCorp will need miners on their new bandwidth network. This could be accomplished by talking with OLD miners and converting them over (perhaps with direct incentives, perhaps without). Either way, being an early miner on a new, successful network would be more profitable than being a miner on the old, more competitive network (it goes without saying that the success of the new network is far from a sure bet).
Step 2: Raise public awareness
It isn’t strictly necessary this step come before the following two, but I’d argue that it is tactically a good decision.
FinanceCorp should alert the OLD community that a new network will be created shortly and that their balances will be transferred over and there will be additional incentives to use the new network. It’s key here to reach as broadly into the community of active users and convince them that it’s worthwhile to use the new network — even if for no reason other than that they’ll be effectively given free money and access to miners.
Step 3: Execute the fork
FinanceCorp would fork OLD to their new protocol, WifiToken (ticker: NEW). It would have the same codebase and wallet balances as OLD, with two exceptions: there would be an allocation of tokens in an incentive pool, which I’ll explain in a moment, and the OLD team/company/foundation tokens would be transferred to FinanceCorp. The incentive pool tokens might come directly out of the OLD team’s pool, or they might come equally from all holders, or elsewhere — but it is important that this pool exists.
At this point, FinanceCorp would activate the miners from step 1 to begin mining on the new network, and some portion of users would come over to spend their new balances (even if they’re planning on switching back after).
Step 4: Drive users over
Then, FinanceCorp would announce that the incentive pool of new NEW tokens will be distributed — airdropped — to users that burn (i.e. send to provably unspendable addresses) their existing OLD tokens. That is to say, if you were a OLD user, you would have gotten an equivalent balance of NEW at the fork. Then, if you burn your old OLD tokens, you are granted more NEW tokens, which gives you increased buying power on the NEW network.
One tactical move here to encourage fast switching would be for FinanceCorp to say that for the first week after the fork, users that burn will be granted their pro rata share of the incentive pool, but that after that week ends, the remainder in the incentive pool will be dropped to all of those that burn.
For example: if the incentive pool is 10% of the network, users that burn in the first week would get a ~10% boost to their holdings. But once that week is over, if only half the users had burned tokens, the remaining 5% in the incentive pool would be re-distributed, so each “burning” user would end up with a ~20% boost to their holdings.
This has the effect of incentivizing OLD users to crater the float of the network, crippling it. As more and more users move to the new network, there’s an increasing incentive for others to follow.
Bonus step: Sell into the market
For an even more complete attack, FinanceCorp could have accumulated a supply of OLD tokens in advance of the attack, and could then aggressively sell the tokens into the market during the attack, driving the price down at the same time the supply is being burned.
To double up on an incentive, these tokens could have been purchased in bulk from OLD miners in advance. This would have the dual effect of allowing the tokens to be purchased off-exchange, without moving the market up in advance, and disincentivizing the OLD miners from going back to the old network.
Of course, buying into the new NEW market would be helpful as well here to help push the price up. This brings up the question of whether FinanceCorp should have prepared exchanges for the NEW fork or not. On one hand, alerting exchanges would allow them to buy into the market — but on the other, having it be a surprise would prevent the users from immediately selling their forked tokens as there would be no liquidity provider.
The aftermath
The combination of the hard fork and the airdrop would lead users to move over. Eventually, at some sort of critical mass, the NEW network could be considered to have “taken over” the OLD network and the hostile takeover would be successful. Miners and users would have moved to NEW and OLD’s supply would be low (and potentially lower every day as stragglers burn their tokens, if that’s in the model). Now, FinanceCorp would need to continue to develop the NEW network and push the ecosystem forward.
Prevention
This is perhaps a topic for an entirely separate post, but — knowing this is possible — how could a network mitigate such an attack?
Here’s one approach, borrowed (semi-)directly from the traditional financial world: a poison pill. The most common version of this is that when a shareholder reaches a certain percentage ownership, every other shareholder is entitled to buy from a new issuance of shares at a deeply discounted rate. This effectively dilutes the encroaching shareholder at minimal cost to the existing ones.
One way to apply this to this token hostile takeover would be to encode in the token’s original smart contract that if a certain percentage of tokens outstanding are burned within a specific time period, those tokens are re-issued and distributed pro rata to all the remaining holders. This would penalize users for leaving the network and reward those that stay, creating an incentive for the original network’s users to either sell or use their tokens on the new network (or just ignore it) and then return to the first network (without ever having burned the tokens).
An even more aggressive path — potentially with more externalities — would be to generalize this and simply make it such that any tokens burned on a network, ever, would be reissued and distributed to remaining holders.
Now: any approach along these lines will be visible to an attacker — that is, they can simply read the smart contract and understand where their attack could fail. This leads to a bit of a cat and mouse game, although if the pill is strong enough, it ultimately may not matter.
Why this matters
We’re now entering the first stage of maturation of the token industry: new networks going live. Until now, few tokens have been live with real use cases, but over the coming 3–12 months, a huge number that held ICOs in 2017 will begin to activate.
As such, there will be an increasing set of incentives for competitive networks and financial engineers to attack and otherwise interact with these networks — and we need to begin thinking about how that will happen and prepare for these sorts of moments.
A key insight here is that in the same way an ownership change of a traditional company doesn’t necessarily have a direct effect on the customers of that company (i.e. if a PE firm buys my local grocery store, I can still go there and use my credit card to buy the same goods), a network fork doesn’t have a large effect or impose significant switching costs on that network’s users. Sure, they’ll need to update their client and websites they’re using, but they can continue to use them in the same way — and with the same balances.
This low switching cost, combined with the open source nature of these projects, is what enables attacks like this to happen.
This is just one type of “corporate” interaction that could happen. We need to consider others as well: mergers, friendly acquisitions, and more — on top of all the new token-only categories that will emerge (chain-merging partnerships? Coordinated mining cycling?). More to come on this.
One final note: I’ve used the terms “attacks” and “hostile takeovers” throughout this piece, but these are not negative by definition. In many cases, such a takeover could result in dramatically improved management, technology, or growth. Just like in the traditional world, sometimes such an acquisition nets out positive for all the customers. But either way — we need to be prepared.
Questions
Some outstanding questions I haven’t fully addressed here:
- What happens to the original team? Could there be collusion up front so the team comes over to the forked network? Could they be hired by FinanceCorp after the fact? If those don’t happen, what will?
- Are there effective ways to do this cross-chain (i.e. not between two ERC-20 tokens)?
- What other mitigation methods are there?
- What other types of “corporate”/network interactions could we see? What are the building blocks (e.g. hard fork, airdrop, miner swaps) of such interactions?
- Is there a way for FinanceCorp to buy OLD tokens from key users (miners, etc.) pre-fork and contractually commit to giving them those tokens for free on the new NEW network?
- How could this attack be improved?
