update readme + license (#30)

This PR is aimed to merge the updated README and add a LICENSE.

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2023 CoW Protocol
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -3,61 +3,63 @@
 
 
 
-This is a tool that monitors all settlements that happen onchain - primarily focusing on EBBO tests. More concretely, we give the promise to our users that they will get a price that is at least as good as what they can find on other DEXs and by parsing publicly available liquidity, we want to test how often solutions with better surplus could have been provided.
+This tool monitors all settlements that happen on-chain, focusing on EBBO testing. More concretely, we promise our users that they will get a price that is at least as good as what they can find on other DEXs. By parsing publicly available liquidity, we can monitor how often solver solutions with better surplus could have been provided.
 
 
-
 ## Scripts
 
-  
+The project consists of 3 main components: <br>
 
-The project consists of 3 main components:
 
-
 1. In the first component, for each auction, we look at all solutions that did NOT win and check whether any of them actually provided a better deal to an order that got executed by the winning solution. This currently is best used for analyzing historical data. This script utilizes the callData of all solutions.
-
 The output consists of all orders that could have provided the user a better surplus with corresponding solver and absolute/relative values of the surplus difference. It also provides the error rate of each solver. The competition endpoint is used for this. To run this, set start_block, end_block or tx_hash in `test.py`.
-
-
-*After dependencies have been installed, run the following from the ebbo directory:* <br>
-
-       python3 -m tests.unit.test
 <br>
-2. The second component is a spin-off from the first that serves as a logging tool on the most recent data available using the competition endpoint. It gathers the most recent settlements available, and analyses them to see if any of them could have given a better surplus. 
-
-*To start the daemon, run the following from the ebbo directory:* <br>
-
-    python3 -m src.daemon
+2. The second component is a spin-off from the first that serves as a live logging tool which gathers the most recent settlements on CoW Protocol, and checks them for EBBO. <br>
+<br>
+3. The third component relies on on-chain data and the instance.json describing the auction. This component parses all settlements that happened on-chain, recovers the surplus that each order got, and for each executed order, calls Quasimodo and requests a solution that only executes that order. Then, it checks what surplus Quasimodo gives to that order and compares with what happened on-chain.
 
 
-3. The third component will rely on onchain data and the instance.json describing the auction. This component parses all settlements that happened onchain, recovers the surplus that each order got, and then, for each executed order separately, calls Quasimodo and asks for a solution that only executes that order. Then, it checks what surplus Quasimodo gives to that order and compares with what happened onchain.
 
-*Relevant file for this test:*
+## Setup Project
 
-`on_chain_surplus.py`
-
-
+Clone Repository: <br>
 
 
-## Running Code
-
-
+    git clone https://github.com/cowprotocol/ebbo.git
 
-To test either of the components, create a `config.py` file in the root directory (ebbo) and set variables `ETHERSCAN_KEY` and `INFURA_KEY` as string values from [Etherscan API Key](https://etherscan.io/myapikey) in your profile and Infura once you have an account created one. You will also need a `DUNE_KEY` for running the historical data test.
 
-  
+Version python 3.10 is used. <br>
 
 ### Dependencies:
 
-Version python 3.10 is used. <br>
-Please install the following libraries as dependencies using pip/pip3. <br>
+
+Install the following libraries as dependencies. <br>
 
     pip install requests
+
     pip install web3
+
     pip install dune-client
-
+
+    pip  install  python-dotenv
 
 
+To test either of the components, create a `.env` file in the root directory (ebbo) and set variables `ETHERSCAN_KEY` and `INFURA_KEY` as string values from [Etherscan API Key](https://etherscan.io/myapikey) in your profile and Infura once you have an account created one. You will also need a `DUNE_KEY` for running the historical data test. <br>
+Sample `.env` structure:
+
+    INFURA_KEY = 'string key here'
+    ETHERSCAN_KEY = 'string key here'
+    DUNE_KEY = 'string key here'
+
+
+*To start the EBBO daemon, run the following from the ebbo directory:* <br>
+
+    python3 -m src.daemon
+
+*If you wish to run the EBBO tool over historical data, set the (start_block, end_block) or tx_hash in `test.py` and run the following from the ebbo directory:* <br>
+
+       python3 -m tests.unit.test
+
 You should be good to go now!