This is a bot application for automating the execution of the Astroport DCA orders
Astroport DCA-BOT requires Python v3.9+
Create virtual environment and install the requirements.txt dependencies. On Ubuntu you can simply run
make install
It will create a virtual environment venv in the root directory of the project:
.
├── bot
├── test
└── venv
│ └── bin
│ └── activate
│ └── python3.9
│ └── pip3.9
│ └── ...
│ └── ...
Activate the virtual environment:
source venv/bin/activate
Create PYTHONPATH, DCA_BOT environmental variables. Run the following cmds in the root directory of the project:
export PYTHONPATH=$(pwd)
export DCA_BOT=prod
(prod=production, dev=development)
The environment variables created in this way will disappear after you exit the current shell session. To create them permanently follow the instructions on this link.
Start the bot:
make start
Run unit tests:
make test-unit
Run integration tests:
make test-int
The integration tests are using the following localterra image dautt/astroport:v1.2.0 where we have deployed all the relevant astroport core contracts and dca contract along with some test tokens. For more details on the integration test setup looks at these files:
test/integration/localterra/localterra.json
test/integration/setup.py
When running the integration tests, there are two tests that may fail occasionally due to timeout issue. So do not be alarmed by that.
test2 user is uploading the dca contract. ... ERROR
test_instantiate (test_dca.TestDca)
test2 user is instantiating a new contract. ... ERROR
Run all tests:
make test
Before starting the bot, make sure the localterra blockchain is running
make local_terra_run
and
export DCA_BOT=dev
Before starting the bot, make sure to edit the relevant information in the settings:
bot/settings/prod.py
and
export DCA_BOT=prod
To track the the relevant information of the dca contract the bot uses SQLite database.
The location of the database is defined in the settings file.
When the bot is running a dca database is created with the following objects (tables,view, triggers):
| Table | Type | Description | Sync job | Sync cfg |
|---|---|---|---|---|
user |
User data | It stores the user's addresses | manually | |
dca_orders |
User data | It stores the user's dca orders | sync_users_data, schedule_orders, schedule_next_run |
SYNC_USER_FREQ, SCHEDULE_ORDER_FREQ |
user_tip_balance |
User data | It stores the user's tip balances | sync_users_data |
SYNC_USER_FREQ |
whitelisted_fee_asset |
dca config | It stores the whitelisted fee assets of the dca contract | sync_dca_cfg |
SYNC_CFG_FREQ |
whitelisted_token |
dca config | It stores the whitelisted token of the dca contract | sync_dca_cfg |
SYNC_CFG_FREQ |
whitelisted_hop |
dca config | It stores the whitelisted hop of the dca contract. | sync_dca_cfg |
SYNC_CFG_FREQ |
purchase_history |
Bot | It stores the history of the purchases which the bot has executed | N.A |
N.A |
token_price |
Bot | It stores the price of the whitelisted tokens. This table is used to calculated the best execution hop | sync_token_price |
SYNC_TOKEN_PRICE_FREQ |
log_error |
Bot | It stores the error msg of the bot | N.A |
N.A |
| View | Type | Description |
|---|---|---|
whitelisted_hops_all |
dca config | It is a view based on the whitelisted_hop. It is a convenient data structure to queries all the hops between a start asset and a target asset |
| Trigger | Type | Description |
|---|---|---|
reset_schedule |
user data | This trigger is associated with the table dca_orders and it will reset the columns schedule and next_run_time after the execution of a order or if the next_run_time is expired. |
trigger_updated_at |
user data | This trigger is associated with the table token_price and it will update the column updated_at after a price token is updated |
To better visualize the data in the SQLite database you may use this open source app, SQLiteStudio along with this sample queries script queries.