Exchange V2

This article goes over the deployed V2 contracts at https://github.com/Ubeswap/ubeswap/tree/master/contracts/uniswapv2, which consists of:

• UniswapV2Factory: internal contract that creates trading pairs

• UniswapV2Router02: router that connects to the frontend to safely make trades

Diffs

Contracts has been forked from SushiSwap codebase. Below are diffs between Sushiswap and Ubeswap:

Diff: https://gist.github.com/macalinao/2ca9a77e221643061465df04a1872507

Deployment process

1. The solidity-create2-deployer was deployed at 0x4a27c059FD7E383854Ea7DE6Be9c390a795f6eE3 using this script.

2. Ubeswap was deployed at commit a88cca4007e57586a19ccfee3a0968dfbab5c736 using the following commands:

   1. yarn build to build the contracts

   2. yarn hardhat deploy --network mainnet --step exchange to deploy the initial exchange

      1. The deployer address was used as the feeToSetter of the factory. This will later be migrated to a smart contract. This is the only centralized part of the protocol.

      2. see https://github.com/Ubeswap/ubeswap/blob/a88cca4007e57586a19ccfee3a0968dfbab5c736/tasks/deploy/001_exchange.ts for full details

   3. yarn hardhat deploy --network mainnet --step liquidity to seed the initial liquidity pool of CELO/cUSD

      1. see https://github.com/Ubeswap/ubeswap/blob/a88cca4007e57586a19ccfee3a0968dfbab5c736/tasks/deploy/002_liquidity.ts for full details

Other details

• There are no proxy contracts used in the entire system. This means that other than being able to set who the fees go to, we have no control over user funds.

• The code is a fork of Sushiswap, which is a fork of Uniswap. No code was added other than a helper view function to be able to get the pair address of a given set of tokens. The full diff and more information on what changed is available here.

• The deployer address is a normal wallet with a seed phrase. It is not stored on a hardware device. If the wallet's private key were to get compromised, the following could occur:

  • The feeToSetter could be set to a malicious party's address. However, they would only be able to obtain 0.05% of each swap. To get rid of the malicious party, the protocol would have to be fully migrated to a different deployment of the UniswapV2Factory. This would be very inconvenient, but no user funds would be at risk.

• The contract implementation cannot be replaced. There is no way to replace the UniswapV2Factory smart contract with a malicious implementation, as there is no self-destruct method and there is no way to overwrite the contract with a proxy.

• When new contracts are deployed, they will not put funds of the Factory and Router at additional risk.

  • Potential exploits in our yield farming and governance contracts will have exploits isolated to those contracts.