This article goes over the deployed contracts at, which consists of:

  • UniswapV2Factory: internal contract that creates trading pairs

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


Below are diffs between Sushiswap and Ubeswap:


Full repo diff:

Admin privileges

Our deployer is currently the feeToSetter, meaning it has the ability to set who takes the 5 basis points off of each transaction (currently set to nobody, in the future will be set to $UBE stakers).

In the near future, we will give this privilege to a Timelock contract. In the further future, this privilege will fully be transitioned to token holders.

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.

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

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.