DXdao's Arbitrum Launch Plan

[KeenanL]

For some months DXdao has been strategically preparing for the launch of Arbitrum One, a decentralized “layer 2” scaling solution built on the Ethereum network. Swapr has aspirations to be THE native AMM on the Arbitrum network, but this won’t come easy. Deploying to a new chain comes with many complications, especially considering the additional variables DXdao has to account for as an Ethereum native DAO. This post outlines the required steps to be undertaken by both DXdao and the community to facilitate a smooth deployment of DXvote, the Swapr dApp and the SWPR token on the Arbitrum One network.

Swapr dApp and Token Community Steps

The Arbitrum Base (DXvote on Arbitrum One), the Swapr Contracts on Arbitrum One, and the SWPR token will need to be deployed by a community member or members. It is suggested here that deployment costs will be reimbursed by DXdao in addition to a .25 ETH reward for deployment of The Arbitrum Base and a .25 ETH reward for deployment of the SWPR token and Swapr smart contracts on Arbitrum One. These reimbursements and rewards can be claimed via a proposal by the deployer address. A step-by-step follows; if anything has been left unclear the prospective deployer is urged to reach out through community social channels, such as the DXdao Discord.

1. Deployment of aDXdao, DXdao Arbitrum One Base (using DXvote) and mainnet signal proposal.

   A. Deploy DXvote to Arbitrum One using the parameters in the DXvote Deployment Details section below. The REP should mirror mainnet REP at time of deployment, with the exception of REP held by smart contract addresses. Since smart contract addresses are not the same on Arbitrum One as they are on mainnet, only the addresses mapped during the xDai base deployment are included. See https://daotalk.org/t/dxdao-signaling-contract-reputation-mapping/2087

   B. Make a proposal to mainnet indicating the address of the avatar, the controller, the reputation contract, and of the schemes, including the Swapr Wallet Scheme.

2. SWPR Token deployment and mainnet signal proposal

   A. Deploy SWPR token contract on Ethereum mainnet. The token contract automatically mints 100M SWPR to an address passed in on deployment. The deployer must pass in his own address as the sole receiver of the 100m SWPR, and after minting the whole supply will be in the hands of the deployer.

   B. Send 85,616,000 SWPR tokens to the DXdao treasury, retaining 14,384,000 SWPR which are needed for the airdrop and initial liquidity mining operations on Arbitrum.

   C. Make a mainnet signal proposal using the included formatted text. (Ensure you fill in the SWPR token mainnet address under the “Token Information” section). This will use the same address which will be used to deploy Swapr contracts on Arbitrum.

   D. When Swapr Dev team sees the mainnet signal proposal it will inform the Arbitrum One team to whitelist the proposing address.

3. Swapr contracts deployment to Arbitrum One and swapr.eth update proposal on mainnet.

   A. Bridge the retained SWPR tokens to Arbitrum One and get the SWPR L2 address (you should be able to see it in the official Arbitrum bridge UI after the first bridging operation has completed successfully). The Arbitrum One SWPR token address is needed for setting the L2_SWPR_ADDRESS environment variable when deploying the claimer contract.

   B. Generate the Merkle root for the claimer contract. In order to do so, start by cloning the SWPR token contract repository (https://github.com/luzzif/swapr-token-contracts). Install the required dependencies through Yarn by executing yarn install or simply yarn. After the dependencies are installed, run yarn create-whitelist to start the whitelist creation process, which will take a while. Once the process is done executing, a few things will be printed out on screen. What we’re interested in is the string that is printed alongside the marketing and unlocked dxd holders airdrop eoa root log. That’s going to be our airdrop whitelist Merkle root, which will be used in setting the MERKLE_ROOT environment variable when deploying the claimer contract.

   C. Pin the airdrop whitelist on IPFS. Among other things, the whitelist creation process also writes various JSON files containing various kinds of whitelists under /whitelist-creation/cache. What we’re interested in is the marketing-and-unlocked-dxd-holders-airdrop-eoa-leaves.json one. Make sure to pin this file on IPFS and note down the resulting CID, it will be needed later in order to release the frontend.

   D. Deploy SWPR claimer contract to Arbitrum One. In order to do it, stay in the previously cloned SWPR token contract repository. At this point you will need to create a .env file at the root of your local folder, with the following contents:

PRIVATE_KEY=your-account-private-key

your-account-private-key needs to be replaced by an actual private key. The private key needs to give access to an account that holds funds on Arbitrum One, enough to perform the deployment.

Once this step is taken care of, you can trigger the claimer’s deployment by using a command formatted in the following way:

yarn deploy-claimer:arbitrum-one --swpr-address $L2_SWPR_ADDRESS --claim-time-limit 1640995200 --merkle-root $MERKLE_ROOT

Where:

• L2_SWPR_ADDRESS is the address determined at step a

• MERKLE_ROOT is the string extracted from the whitelist creation script at step b

Once the script is executed, it will print out the claimer contract’s deployment address on Arbitrum One, which is needed for later stages.

      E. Send 7M SWPR to claimer contract on Arbitrum One. Send 1M SWPR to the Arbitrum One Base avatar. Send 6,384,000 SWPR to Swapr Wallet Scheme on Arbitrum One.

      F. Deploy Swapr contracts to Arbitrum One.

In order to deploy the core and periphery contracts, simply clone this repository (https://github.com/luzzif/swapr-contracts-deployer) and install dependencies through yarn install. In order to continue, a private key must also be added to a .env file as done for step d. This private key will need to give access to a properly funded account through which the contracts will be deployed.

After having added the private key, a single task can trigger the whole contract suite deployment, which will take care of the pairs factory, router, fee setter and fee receiver, and it’s the deploy task. In order to trigger it, just type yarn deploy in the terminal, passing in the following required parameters:

• --network: specifies the network on which you want to perform the deployment. In our case it should be set to arbitrumMainnet.

• --native-asset-wrapper-address: the address of the contract that wraps the native asset in the target chain. On Arbitrum, the canonical WETH instance is deployed at 0x82aF49447D8a07e3bd95BD0d56f35241523fBab1, so the parameter should be set to this value.

• --owner-address: An address that will become the owner of the contracts after deployment. This address will also get all accrued fees (both denominated in native asset, and exotic currencies). This should be set to DXvote’s address on Arbitrum One (which should be known after step 1).

After the command has finished running, make sure to take note of the printed out addresses, which will be needed on later stages.

We can now deploy the liquidity mining campaigns factory contract.

In order to do that, simply clone this repository (https://github.com/luzzif/dxdao-staking-rewards-distribution-contracts).

As previously done, install the dependencies through yarn install and add a .env file at the root of the project setting a private key useful for contracts deployment (ideally, the same one used to deploy the core and periphery).

The command to execute this time is yarn deploy:arbitrum-one:no-validators. The only required parameter is --owner-address, which must be set to DXvote, in order to give ownership of the farming contracts to the DAO.

At the end of this step, we should have addresses for all these contracts deployed to Arbitrum One:

• Pairs factory

• Router

• Fee Receiver

• Fee Setter

• Staking Rewards Factory

  G. Build latest release of Swapr and propose update to swapr.eth

In order to build the latest release of Swapr, clone the Swapr Dapp repo https://github.com/levelkdev/dxswap-dapp and check out the tag of the latest release. Using node v12.20.0, install dependencies by running yarn install --force

Once dependencies are installed, create a .env file at the root of the project with the following variables filled out:

• REACT_APP_FACTORY_ADDRESS_ARBITRUM_ONE: self explanatory. The value should come from step 3.f.

• REACT_APP_ROUTER_ADDRESS_ARBITRUM_ONE:: self explanatory. The value should come from step 3.f.

• REACT_APP_STAKING_REWARDS_FACTORY_ADDRESS_ARBITRUM_ONE: self explanatory. The value should come from step f.

• REACT_APP_SWPR_ADDRESS_ARBITRUM_ONE: self explanatory. The value should come from step 2.

• REACT_APP_SWPR_CLAIMER_ADDRESS_ARBITRUM_ONE: self explanatory. The value should come from step 3.d

• REACT_APP_SWPR_AIRDROP_WHITELIST_IPFS_HASH: self explanatory. The value should come from step 3.c.

Once the .env file is created and updated, run yarn ipfs-build to bundle the application in a format compatible with IPFS.

To generate the IPFS hash, you can run ipfs add -rn ./build

After building the dapp, upload and pin the dapp to IPFS.

Finally, make a proposal to DXdao to update the content hash of swapr.eth A recent example of such a proposal can be found here and a multicodec version of the IPFS hash can be encoded using https://content-hash.surge.sh/.

DXvote Deployment Details

The plan is to deploy four schemes, the same three schemes we have been using in Rinkeby and Arbitrum Testnet DXvote dapp plus a special scheme that will communicate only with the SWPR protocol and the avatar, this scheme will act as a quick action relayer between dxdao and the SWPR protocol.

Initially the SWPR scheme will be able to call any contract, this permission will be removed and replaced with only calls to SWPR protocol and DXdao avatar in Arbitrum once SWPR is deployed.

• Registrar Wallet Scheme

  • Calls to Controller: Yes.

  • Max Seconds for calls to be executed after approval (maxSeconsForExecution): 1 Day

  • Maximum Reputation to be changed in a proposal execution (maxRepPercentageChange): 5 %

  • controllerPermissions: Everything

  • Required % vote to execute Queued Proposals (queuedVoteRequiredPercentage): 50 %

  • Required % vote to execute Boosted Proposals (boostedVoteRequiredPercentage): 5 %

  • Time limit for Queued Proposals (queuedVotePeriodLimit): 14 Days

  • Time limit for Boosted Proposals (boostedVotePeriodLimit): 5 Days

  • Time limit for PreBoosted Proposals (preBoostedVotePeriodLimit): 2 Days

  • Threshold Limit Increase to boost proposals (thresholdConst): x2

  • Minimum time for final answer to dont change before execution (quietEndingPeriod): 1 Day

  • REP staked on Queued and PreBoosted Proposals (votersReputationLossRatio): 50%

  • Minimum downstake set by for new proposals (minimumDaoBounty): 5 DXD.

• Master Wallet Scheme

  • callToController: Yes.

  • maxSecondsForExecution: 1 Day

  • maxRepPercentageChange: 5 %

  • controllerPermissions: Only Generic Calls

  • queuedVoteRequiredPercentage: 50 %

  • boostedVoteRequiredPercentage: 1 %

  • queuedVotePeriodLimit: 14 Days

  • boostedVotePeriodLimit: 5 Days

  • preBoostedVotePeriodLimit: 2 Days

  • thresholdConst: x1.5

  • quietEndingPeriod: 1 Day

  • votersReputationLossRatio: 25%

  • minimumDaoBounty: 1 DXD.

• Quick Wallet Scheme

  • callToController: No

  • maxSecondsForExecution: 1 Day

  • maxRepPercentageChange: 0 %

  • controllerPermissions: None

  • queuedVoteRequiredPercentage: 50 %

  • boostedVoteRequiredPercentage: 0.1 %

  • queuedVotePeriodLimit: 7 Days

  • boostedVotePeriodLimit: 3 Days

  • preBoostedVotePeriodLimit: 1 Days

  • thresholdConst: x1.1

  • quietEndingPeriod: 12 Hours

  • votersReputationLossRatio: 10%

  • minimumDaoBounty: 0.1 DXD

• Swapr Wallet Scheme

  • callToController: No

  • maxSecondsForExecution: 1 Day

  • maxRepPercentageChange: 0 %

  • controllerPermissions: None

  • queuedVoteRequiredPercentage: 50 %

  • boostedVoteRequiredPercentage: 7 %

  • queuedVotePeriodLimit: 7 Days

  • boostedVotePeriodLimit: 1 Day

  • preBoostedVotePeriodLimit: 12 hours

  • thresholdConst: x1.3

  • quietEndingPeriod: 12 Hours

  • votersReputationLossRatio: 10%

  • minimumDaoBounty: 1 DXD

SWPR Liquidity Mining

The initial liquidity mining pairs and rewards will follow that which has been outlined in the “SWPR Token and Swapr Guild” DAOtalk thread, updated on 2021/08/16. To accomplish this, proposals will be made on aDXdao releasing SWPR tokens to the described pairs through the Swapr DIY farming contracts. The Swapr Wallet Scheme should allow the DXdao community to operate quickly when deploying new SWPR farming campaigns.

aDXdao funding

A signal proposal passed on both xDai and Mainnet authorizing a $2.25m commitment of DXdao capital to be bridged over to Arbitrum One. This will be used for liquidity provisioning on Swapr ($2m) and working capital for aDXdao ($250k).

[nylon]

big big awesome claps to anyone and everyone involved in this, so many boundaries on so many fronts have been pushed on this! exciting!

[luzzifoss]

Guys I have an update. There have been talks about moving the DXD holders airdrop date as late as possible. Hence why I’ve updated the SWPR token repo to generate whitelists with snapshot dates of today at midnight UTC (plus a change related to the Snapshot GraphQL API changing endpoint and making the script fail). This is why ANY DEPLOYMENT OF THE CLAIMER CONTRACT DONE BY THE COMMUNITY WITH THE OLD WHITELIST SHOULD BE CONSIDERED INVALID.

Please for anyone reading this and wanting to deploy the contracts, pull the latest changes on the swapr-token-contracts repo before generating the whitelist and the Merkle root.

[luzzifoss]

I have a further update. I’ve found another minor issue on the whitelist creation script, that made it impossible to have equal results between people having the PC set in a timezone with UTC- and UTC+. This is why, again, ANY DEPLOYMENT OF THE CLAIMER CONTRACT DONE BY THE COMMUNITY WITH THE OLD WHITELIST SHOULD BE CONSIDERED INVALID .

Anyone can pull the latest changes from the repo and run the script now.

[adamazad]

Are there any ongoing efforts to automate this? A simple CLI tool that can do all this in segments? If not, I will start a repo over the weekend and see how far I can get.

[Iam_kmkm]

Fantastic job!
I am not sure if SWAPR will become THE native AMM on Arbitrium, but what is sure is that DXdao positioned itself well, with a timely and well-planned launch!

Fingers crossed!

thank you all.

[AugustoL]

For DXvote Smart Contracts on Arbitrum verification:

The latest code with the smart contracts compiled is in GitHub - AugustoL/dxdao-contracts at augustol-develop.

The Arbitrum block explorer expose only the bytecode of the contract.

Contracts file: dxdao-contracts/.contracts.json at augustol-develop · AugustoL/dxdao-contracts · GitHub

Steps to check the deployed code:

1. Enter the smart contract link in the Arbitrum explorer and look for the “view deployed code” link.
   
   
2. Copy the deployed code.
   
   
3. Go to the compiled contract .json file and look for the deployed code.
   
   

This means that the deployed code of the smart contracts you are seeing in github are the same to the ones deployed on chain.

Avatar .json file: dxdao-contracts/DxAvatar.json at augustol-develop · AugustoL/dxdao-contracts · GitHub
Avatar on Arbitrum Explorer: Arbitrum Explorer

Reputation .json file: dxdao-contracts/DxReputation.json at augustol-develop · AugustoL/dxdao-contracts · GitHub
Reputation on Arbitrum Explorer: Arbitrum Explorer

Controller .json file: dxdao-contracts/DxController.json at augustol-develop · AugustoL/dxdao-contracts · GitHub
Controller on Arbitrum Explorer: Arbitrum Explorer

PermissionRegistry .json file: dxdao-contracts/PermissionRegistry.json at augustol-develop · AugustoL/dxdao-contracts · GitHub
PermissionRegistry on Arbitrum Explorer: Arbitrum Explorer

DXDVotingMachine .json file: dxdao-contracts/DXDVotingMachine.json at augustol-develop · AugustoL/dxdao-contracts · GitHub
DXDVotingMachine on Arbitrum Explorer: Arbitrum Explorer

WalletScheme .json file (this can be used for any Wallet Scheme): dxdao-contracts/WalletScheme.json at augustol-develop · AugustoL/dxdao-contracts · GitHub

If you want to go even further in the verification and you have the technical knowledge and a bit more time you can pull the changes from github, delete the artifacts folder, install dependencies with yarn and run yarn hardhat compile to compile the contracts locally and check the bytecode deployed against your local build instead of the one published in github.

[luzzifoss]

Update: Swapr beta 4 release has just been published on GitHub. You can see it here. I’ve optimistically added SWPR’s mainnet address from this proposal right here. In case something goes wrong and the proposal’s submitter doesn’t follow the plan from now on, we’ll just start over waiting for a new community member to help us. Nothing will be ratified if the DAO doesn’t approve it anyway.

This frontend version however is the one that the above proposal’s submitter needs to keep an eye on and deploy in order for the plan to be executed correctly. Good luck to whoever is trying to help us by deploying Swapr to Arbitrum, your anonymous services are much appreciated!

[luzzifoss]

Another update. The Arbitrum team just communicated to us that the address of the SWPR signal proposal submitter has been whitelisted, along with the SWPR instance they specified in the proposal itself.

[JohnKelleher]

Noticed a proposal has been made by the deployer to update swapr.eth to the beta 4 release of Swapr. I haven’t had a chance to verify the details yet, but “optimistically” upstaked the proposal to help shorten the timeline. Rep holders and other community members should make an effort to verify this proposal in the next day or two and vote on it accordingly. I will take a closer look tomorrow.

Alchemy | DAOstack

[luzzifoss]

About the frontend release proposal, I’m actually writing a script that will let anyone verify all the details in a pretty easy way. Will let you know when it’s ready

[luzzifoss]

Just added a verification task to the swapr-token-contracts repo. To use it you’ll need to run the following command:

yarn verify-deployment 
--swpr-l1-address 0xe54942077Df7b8EEf8D4e6bCe2f7B58B0082b0cd 
--swpr-l2-address 0x955b9fe60a5b5093df9Dc4B1B18ec8e934e77162 
--dao-l1-address 0x519b70055af55a007110b4ff99b0ea33071c720a 
--dao-l2-address 0xe086305858d49f65a5d20adaccd31c523d32694f 
--claimer-address 0xe54942077Df7b8EEf8D4e6bCe2f7B58B0082b0cd 
--factory-address 0xBF9173b60a30B9ff8c37cac787B6EE87D5e47916 
--router-address 0xf20D10E306e34F9d830715eeEF577AC16B5Ea72e 
--farming-campaigns-factory-address 0x85B94253ACd8C06525B509d94F9a9c5aF78a012f 
--deployer-address 0x2c1f8f72ed9bd1f59b140c5e6bceacc8a4753695 
--swapr-scheme-address 0xB7F6F30178d9598D158BFA046456cf27ACEdcECB

I invite you to also double check the addresses above, which were taken from the DXvote Arbitrum One base proposal, the SWPR signal proposal and the beta 4 frontend release.

This script will print out information through which everyone will be able to verify what has been done by the deployer, by simply rereading the process and confirming everything was done in the right way.

Edit
To be more precise, to run the script clone this repo or, if you’ve already done it, just pull the latest changes. You can then install the required dependencies through yarn install. After having done this, you can simply run the command above and be able to see results.

[JohnKelleher]

I noticed that the swapr L1 address is the same as the claimer address. . why is this?

[luzzifoss]

I noticed that the swapr L1 address is the same as the claimer address. . why is this?

The address of deployed contracts gets calculated based on the address of the deployer and its tx nonce. If both are the same on 2 different chains, and the next transaction on both chains will be a contract deployment, those 2 deployed contracts will have the exact same address, even though they could potentially be entirely different in code.

In our case, looking at Etherscan, the deployer started from a fresh account, and the first thing he did was to deploy the SWPR contract, through a tx that will then inevitably have nonce 0 (the nonce can be seen on Etherscan here, by clicking on show more data).

If we then switch over to the Arbitrum explorer, we then see that the deployer’s first voluntary action on Arb1 was to send this transaction (here I say voluntary because technically speaking the first transaction the deployer triggered was the SWPR L2 gateway contract creation when bridging the token, but as we can see here, there’s no nonce linked to this tx since it’s not voluntarily broadcast by the deployer).

We can see that that transaction is indeed the claimer contract creation. Being it broadcast with nonce 0, the resulting deployed contract address was determined to be the same as the SWPR token on L1.

So I’d say everything here looks right.