Comment on page
- 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:
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.
The following steps were taken to perform the deployment:
- 2.Ubeswap was deployed at commit
a88cca4007e57586a19ccfee3a0968dfbab5c736using the following commands:
yarn buildto build the contracts
yarn hardhat deploy --network mainnet --step exchangeto deploy the initial exchange
- 1.The deployer address was used as the
feeToSetterof the factory. This will later be migrated to a smart contract. This is the only centralized part of the protocol.
yarn hardhat deploy --network mainnet --step liquidityto seed the initial liquidity pool of CELO/cUSD
- 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:
feeToSettercould 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.