Swapr Deployer Proposal Post-mortem

DXdao is pushing the boundaries and defining how DAOs deploy and own products. See this post for an in-depth description of the proposal process, its potential evolution, and how DXdao is leading the way.

With the release of Swapr (formerly DXswap) core contracts, the DXdao developer community was aiming to evolve the deployment process such that DXdao would authorize the smart contract deployment in its own step instead of doing it all at once with the dapp deployment via ENS proposal (see linked post above for detail).

DXdao developers built a deployer contract that could only be authorized via the DXdao sending the deployer ETH. Only after receiving ETH from the DXdao avatar would it be able to deploy the Swapr core contracts. The deployer was developed and a community member deployed it and made this proposal to fund it:

The proposal passed with 25.88% in favor and 0% opposed. Unfortunately, due to an unanticipated issue, the attempted execution of this funding proposal fails, reverting due to an “out of gas” error. This is happening because the ContributionReward scheme in DXdao uses an old method to send ETH and this comes with a fixed allocation for gas costs for the recipient contract. The deployer contract has a payable fallback function with the logic that only allows the DXdao to authorize it, and it is this logic which requires more gas to execute. Because the deployer as currently implemented only accepts ETH from DXdao and because the DXdao funding proposal cannot successfully send its ETH to the deployer, the deployer can’t do its job.

Next Steps

One approach would be to update the deployer to address the above issue, which is relatively straightforward and to repeat the above process. However, this would change the bytecode identified in this DAOtalk post and would perhaps take a little time to re-test. In addition, a funding proposal takes usually at least 8 days to pass. In total this might delay deployment of the dapp to swapr.eth by about 10 days.

Another approach would be for the community to fallback on the previously used method described here and rely only on the ENS proposal. This would result in no slippage in the Swapr roadmap schedule. As the dapp’s alpha release was just finalized, this would be the most expedient approach.


Why was this issue not caught before the proposal was made and then passed? The Swapr core contracts were audited, tested by several people on Rinkeby using an organized test plan, and the DXdao community also simulates proposals. So how was this missed? The audit covered the deployer but how that deployer was going to be called was not in scope and the auditor could not be expected to anticipate the issue that would arise from using the ContributionReward scheme. The testing on Rinkeby simulated the DXdao by using a multi-sig, so the issue with the ConrtibutionReward was not exposed. And finally, the community has typically not simulated funding proposals, thinking that sending ETH or tokens somewhere is not something that would need simulation. This last assumption was wrong.

The lessons here are, first of all, to simulate every proposal. And second of all to test with a fully simulated environment; in this case that would have meant a deployment of DXdao contracts on Rinkeby. The development community has discussed these points and plans to incorporate these lessons into future efforts.