The Great DApp Takeover

Figure: Taking DApps and their users from other chains

Can’t build the killer DApp? Why not just port/fork one from another chain? Onchain data is publicly viewable and manipulable by all¹ (parity bug anyone?). Here we will be discussing how to mount a successful hostile DApp takeover of Axiom Zen’s CryptoKitties.

With more and more chains reaching mainnet, the only way to attract real users rather than speculators is to have killer DApps. First we will note how public blockchains are wall-less gardens where anyone can access state and built on top of existing DApps. Then we will explain how controlling the DApp interface equates to commanding users’ attention, before delving into the mechanics of mounting a successful DApp takeover.

It is possible to fork:

• Contracts (smart contracts) — ex: solidity files, EVM bytecode
• Chains (blockchains at a certain point of time or the codebase itself) — ex: Bitcoin Cash, Zclassic, MoneroV
• State (data stored within a smart contract) — ex: Balances of an ERC20 contract

Wall-less Garden

In a public chain, anyone can built on top of existing smart contracts as they are permissionless. Their functions can be called by anyone. This openness is most telling as addresses can neither prevent the sending of Ether to them nor the assignment of assets (ERC20 / 721).

Figure: Hats anyone?

In the case of CryptoKitties, the KittyHat team created a new set of assets that are associated with the kitty Non Fungible Tokens (NFTs). There are accessories such as hats, glasses, clothes, wallpaper, etc. that can be bought, sold and traded by the owner of the kitty. The surprising revelation is that Axiom Zen is powerless to stop this. Kitties now have top hats that are owned by the kitty, not the owner. When kitties are traded, the accessories follow it. The KittyHat team created a whole new asset class that is able to generate value for themselves and potentially more value for the entire CryptoKitty ecosystem. This new model of multi-level ownership is part of a new standard called ERC-998 and it allows this class of assets to own other ERC-998s, ERC-721s and ERC-20s².

Figure: KittyRace, race your cryptokitty against others. Contract Address here.

KittyHat is not the only instance of teams building on top of an open protocol. KittyRace allows for owners of kitties to race them against each other. The unique DNA of each kitty and some randomness are used to determine the speed of each racer. Why build on top of CryptoKitties? It’s hard to say, but perhaps one reason is to access the user base of the underlying DApp which will hopefully drive users to KittyRace. A less obvious reason is to give racers a form of identity and personality beyond addresses.

Axiom Zen could capture the entire value of these add-ons by forking them. However, doing so could alienate the developer and user community, stymieing growth. But in this lawless and wall-less garden, developers can choose to do whatever they desire, for example, building on top of other DApps, creating KittyClassic or any other accessories that they want to.

Controlling the Interface

The most common way to interact with a blockchain is through a web interface. DApp developers have to routinely create UIs that bring their applications to life, as few users want to use the command line or a block explorer to understand what functions they can call and determine which hats their kitties own.

Figure: User Interface for CryptoKitties. Note in the KittyHat screenshot several images above, kitten #587783 has a bow tie, however in the canonical or Axiom Zen UI the bow tie is missing.

Axiom Zen created a web UI for CryptoKitties that allows users to easily interact with the on-chain logic and ERC721 assets, such as buying and selling. This establishes the canonical UI as the original interface for buying, selling, gifting and breeding kitties. Users must go here to buy the gen 0 kitties that Axiom Zen created because there is nowhere else in the world one can go to buy that particular set.

But if one wants to do something besides buying new gen 0 kitties, one is not locked. There are generalized interfaces for trading NFTs and other crypto assets: 0x, RareBits, OpenSea, etc. They cater to a large number of different assets, but they don’t dive deeply into individual asset classes.

Every project that builds on top of the base game needs to build out their own interfaces. This is because the odds of Axiom Zen integrating them is rather low, at least in the beginning when they haven’t proven that they have significant track record. At first these specialized interfaces are narrow in function. The KittyHat interface only allows the purchasing of accessories. The KittyRace interface is only for racing. But over time they will find more ways to become full service to attract more user attention.

Since game logic is on-chain, the interface acts as an information gateway where anyone can build their own version, or even interact with the smart contracts directly using JSON RPC through the command line. Therefore it is quite foreseeable that a team builds a superior UI to Axiom Zen’s, which ends up attracting more users than the original UI. Sustaining user’s attention is where all the value capture lies.

Potentially Killer Interface

• Integration of side projects more quickly (KittyHat native to a canonical UI)
• Better UI / UX
• Additional features that users may desire: chat / community, whitelisting / blacklisting, improved governance models, reduced fees, etc.

Figure: CyptoKittiesAuctionContract, notice the `ownerCut` currently set at 375 basis points (3.75%), why pay rent when you don’t have to?

With a plethora of interfaces on the market, users need to exercise caution when interacting with them. They might interact with unscrupulous contracts and end up with a fake kitty rather than an official one if they failed to check the contract address or the previous history. Such scenario has happened in the past to a user of EtherDelta, who accidentally bought counterfeit Wanchain tokens. In addition to fake contracts, DNS Hijacking has also occurred. Caveat emptor.

Projects and interfaces should use Ethereum Name Service (ENS) or a whitelisting system to keep track of legitimate contracts. They should leverage public infrastructures to validate and verify addresses to ensure that users always interact with the correct contracts. There have been too many cases of users sending ether to the wrong contracts.

The greatest control in a blockchain is controlling the interface. If Metamask got hacked, the hacker could change the recipient address to receive all the funds :0. By controlling the top interface, you control the protocol which makes a hostile takeover easier.

DApp Migration Scenerios

Some of the reasons why a team might want to move a DApp from one chain to another:

1. Axiom Zen wants to migrate to a more performant chain
2. A new chain wants to attract more users and migrates an attractive dApp over (potentially hostile)
3. A game built on top of CryptoKitties wants to have more control of the underlying game (perhaps they have more MAUs than the base game)
4. Consortium of users / developers dislike the direction the Axiom Zen team is taking the project or there’s a disagreement in governance models, etc.

Why should a DApp built on CryptoKitties rely on the base game if they generate more value to the ecosystem than anyone else? Why should they pay a rent to the creators when their DApp generates more transaction volume?

Steps for a DApp Migration:

Forks fall into two broad categories: fork at a particular block height that maintains ledger history and a snapshot that only retains history at a particular point in time. When it comes to a DApp, there are two similar groupings: replaying all transactions that have occurred over its history and snapshotting which reflects a state at a particular block height.

1. Copy code of the CryptoKitties smart contracts and make any changes if necessary
2. Deploy smart contracts onto another chain / same chain
3. Replay all transactions that ever occurred (Replay)OR create a function that deploys all NFTs and their state (Snapshot).
4. Deploy address migration smart contract where:
5. Users submit a signed message to the migration contract specifying the new address they want to have.
6. Contract verifies signature and previous ownership in the old chain
7. Contract transfers ownership from old address to the new address

Forcing Migration

If the migration is initiated by the Axiom Zen team, they can announce the change and freeze the old smart contracts and have the UI point to the new contracts/chain. However, for a hostile takeover, there are different steps to take as they have to compete with the incumbent.

For a hostile takeover

1. Plenty of marketing around the block height of the snapshot and the benefits of the new chain and contract changes, etc
2. Perform transfer
3. All UIs own / bribed by the hostile actor will point to the new chain
4. Add incentives for users to migrate to the new chain quickly (free kitties or tokens, the earlier they move over the more they get)
5. Force users to burn their kitties on the old chain before they can claim rewards (if only it was possible to short the NFT market :/)

How to make this hostile takeover successful:

• Have a very successful user interface that has a large number of users or have the capital to bribe large interfaces
• An extremely malicious actor who controls an interface can have users sign messages that effectively burn their kitties without their knowledge. This has to be done carefully or else it might alienate the community
• Introduce fake kitties on the old chain to reduce trust
• Be malicious on the old chain: spam attacks, etc

Figure: How high of a wall can developers and blockchains build to capture all of the value that exists within them?

Defenses?

What can Axiom Zen do? Copyright laws could be leveraged to prevent the new actor from taking over the system. But what if there is no company behind this change, and the content is hosted on a decentralized CDN that uses a blockchain DNS that can’t be taken down?

Token Curate Registries (TCRs) of whitelists might be a community-driven way to verify which addresses are correct, along with system such as ENS. But these systems are useless if a user does not check the addresses of contracts they’re interacting with or if an interface is censoring information.

Perhaps interoperability between chains will make this type of pivot/fork difficult, as users will be able to transfer their NFTs to a better performing chain and play with them there. But it’s hard to say what interoperability will do to the blockchain world beyond making whitelists/blacklists more important.

Or a more simple solution, the more DApps that integrate CryptoKitties natively into their system will increase the state space that must be migrated over. An attacker would have to determine which set or subset of DApps they would want to migrate over, make it marginally technically more challenging. But more importantly there will be more shareholders that must be persuaded to migrate, increasing the friction. Perhaps inertia is the deepest moat?

Maybe it’s necessary to develop economic moats: Economies of Scale, Intangible Assets, Efficient Scale, Switching Costs, Network Effects…

Et tu?

What defenses will DApps and chains start to implement to defend against hostile takeovers? Which chains will begin these attacks?

Foot Notes

1. There exists particular blockchains and protocols that have privacy preserving properties that prevents the leakage of smart contract state or even code.
2. As a side note, the ERC-998 standard did not exist before KittyHat. Their implementation operates as an ERC20 contract with a token associated with each kitten NFT address. Each kitten accessory is its own ERC20 contract.

Floor Notes

1. Inspired by — https://medium.com/@andy_bromberg/what-the-first-token-hostile-takeover-could-look-like-c40be3ccb6b5

Special thanks to Lorenz Breidenbach, Matt Huang, Joyce Yang, Alok Vasudev, James Prestwich and countless other for providing feedback.