This project is meant to implement the analogous of the Markowitz model for the choice of an efficient portfolio (Markowitz, H.M. (March 1952). "Portfolio Selection"), but in the world of crypto assets. In particular, we focused our attention on the Ethereum blockchain, and the relative ERC20 tokens in the domain of the chain. This simply sketch represents MARKO's architecture.
Without further ado, let's jump into the quickstart:
To be completed with an illustrative video. Coming soon
This part of the readme is meant to help with quickstart the Django HTTP server in order to be able to initialize in it a RESTful API and test its endpoints. Note that in production this would not be done, as we host the server in a EC2 Amazon VM. In such a way our API would be exposed to the WAN and reachable by the contracts living in the ethereum blockchain. To call the running server, check out the addresses of our VM hosting the server and endpoint routes, both provided inside the White Paper.
To quick start the project locally (at localhost), a bash file has been written and it needs to be called in the main directory with the following snippet of terminal code:
pip install -r requirements.txt #install all the requirements
python manage.py crontab add #add the cron job for awakening the contracts
python manage.py runserver #start the server locally (127.0.0.1)
The server will allow the following endpoints, declared in Markowitz/api/strategy.py :
They both interact in turn with a MongoDB (NoSQL) database where information is stored and can be retrieved for later awakenings of the contract.
Most Viable Product requirements:
- Coding of the Ethereum smart contract in solidity
- Creation of the HTTP Server and related Endpoints
- Creation of the NoSQL database in MongoDB
- Hosting the server in the WAN
- Coding of a toy exchange protocol in solidity
- Test the results
Production requirements (assuming the above are completed):
- Adopt serious security protocols
- Remove the limitation of 5 tokens max per portfolio
- Minimize the fees paid by optimizing information exchange in calls
- Integrate a true exchange in the process
- Deploy the contract outside of testing environments
- MARKO's own database for timeseries data on crypto prices
- Integration of BalancerAMM
- Production testing
We need to make a distinction on the time at which we find ourselves in. Chronologically, the following events take place:
- A certain contract C is created by a specific user.
- C at creation calls the server S in order to get registered in the awakening register.
- Every month, at awakening time decided by the Django Cron server-side, S contacts C.
- When answering, the C calls back S requesting an optimized version of the portfolio.
- S provides the response to the C, which updates its assets' allocation accordingly.
We got you covered, MARKO's whitepaper can be found in this same repository under the "White Paper" folter, in a pdf format. It thoroughly dissects and explains MARKO's functionings without you having to go through the whole code to make sense of it.
## License