The DAOhaus to xDai dapp Migration

Published in

DAOhaus.club

4 min readAug 24, 2020

Purpose

When we launched DAOhaus last year at EthBerlin, summoning a DAO was around $2.50 in gas. Today it can be anywhere from $50–150 to summon a DAO. At this level, gas prices are an existential threat to coordination.

Eliminating coordination cost is the main purpose of a DAO, so we’ve begun migrating to xDAI. Mainnet Ethereum will always be available, but the xDai side chain will be another option.

This article hopefully will show how easy the process was for us to spin up DAOhaus on the xDai chain.

Why xDAI?

Ready now (we need to coordinate now and are not interested in testing)
Aligned with Eth 2.0 roadmap
Availability of dev tooling/infra (theGraph/blockscout)
Dai and multi-token bridges
Trusted network of professional validators (Eth community)
2 years running, great core team.

Steps to Migrate:

Deploy contracts to xDai

The first thing we did was experiment with deploying some contracts to the xDai chain. To do this we just used Remix and connected metamask to the xDai rpc. We had already bridged a little dai over for our testing. Pleasantly surprised that the Moloch V1/V2 contracts deployed without any problems. And really pleasantly surprised that it cost only about .1 xdai to deploy a MolochV2, in comparison on mainnet with 100+ gas prices the deploy would cost over $100.00

Many of our DAOs use weth as an internal token because the erc20 functionality is required. On xDai we have the same issue, so what to do to let people use the native token in daos? Well we just updated the naming and deployed a copy of the weth contract on xdai. Again through remix, totally seamless. Yay, now we have wxDai. See the verified contract here

https://blockscout.com/poa/xdai/address/0xe91D153E0b41518A2Ce8Dd3D7944Fa863463a97d/contracts

Last we had a few factories to deploy for the DAOhaus dapp. Again, straight copy. No problemo.

Verify on blockscout

So next we wanted to verify all these contract. If you are familiar with the process on etherscan it is pretty much the same on blockscout. Just search for your contract on blockscout and there will be a big button to verify. I did have a problem getting one contract verified but that was because i put in the wrong pragma. Seems I do that every time on etherscan too though. Once i got that right everything was smooth.

Deploy the subgraph

Just had to update a few contract address and in the manifest

network: xdai

Yup, that’s it.

3box

3box just works, because EOAs are the same on both networks, no changes needed.

Frontend web3

We use web3Modal, which usually just works, and it does here to, we were able to update a couple .env variables and everything went pretty smooth. The .env variables we updated was a chain id (100) and the infura end point and key. Not using infura on xdai so we ended up just updating to https://xdai.poanetwork.dev both eth_sendTransaction and eth_call worked.

At first we tried using nodesmith but got some errors but when we switch to the rpc above, all good.

The last thing we did was update some .env variables that point to our factory contracts, with the new adders from our deployments above.

The last thing we did was update another project to support xdai https://wrapeth.com/ so that our users could easily wrap/unwrap their xdai.

Change links to blockscout from etherscan.

Because xdai uses a different block explorer we had to have some logic that would change any links to see transaction status to blockscout instead of etherscan.

TODO: Update help content

Last thing to do is update some of our help content and documentation. We can add a few notes about the process of bridging and getting wrapped xdai

But if you want watch a little tutorial on using the xdai bridges and summoning a DAO you can check this out https://youtu.be/n2pFfiJhbSk

Other things

When multi token bridge is ready and people are bridging all their erc20s for dao use. Getting price feeds on bridged tokens may be harder, might have to check the bridge mediator for the bridged token address and get any meta from that address on mainnet.