Getting Started Guide

LiquidScheduler Getting Started

  _       _                   _       _   ____           _                  _           _               
 | |     (_)   __ _   _   _  (_)   __| | / ___|    ___  | |__     ___    __| |  _   _  | |   ___   _ __ 
 | |     | |  / _` | | | | | | |  / _` | \___ \   / __| | '_ \   / _ \  / _` | | | | | | |  / _ \ | '__|
 | |___  | | | (_| | | |_| | | | | (_| |  ___) | | (__  | | | | |  __/ | (_| | | |_| | | | |  __/ | |   
 |_____| |_|  \__, |  \__,_| |_|  \__,_| |____/   \___| |_| |_|  \___|  \__,_|  \__,_| |_|  \___| |_|   
                 |_|                                                                                    

LiquidScheduler is an on chain scheduling solution for EOS based actions.

The service has 2 parts, a transaction scheduler, and an interval. The scheduler is used for scheduling actions to take place in the future and the interval may be used for running services on a reliable cron such as a price feed.

LiquidScheduler takes a name timer, a std::vector<char> payload object, and an uint32_t seconds interval/deferred schedule time as its parameters. Multiple timers may be used within the same contract. For example, if a contract deals with multiple accounts, a timer can be set up for each account. The payload parameter can be used to pass data to the timer_callback function, (or start_interval for intervals) which is used to run the scheduled task/interval. At the end of the timer_callback is a return response to reschedule the transaction if needed. If the return is truthy, the task will reschedule again based on the interval passed, if it is false, the task will not be rescheduled.

Currently there can only be 1 timer_callback so it is recommended to separate the schedule and interval services into separate contracts if needed.

One use case would be setting up LiquidHarmony (oracle) fetches on a continual basis. An example of this can be seen in the portfolio example which fetches 3 prices on an infinite loop.

Another great place to understand the service is in the unit tests.

The price feed example uses LiquidHarmony web oracles and the LiquidScheduler to periodically update a price on chain only when the new price is more or less than 1% of the last updated price, conserving CPU by only running actions when necessary. See here

Prerequisites

Unbox LiquidScheduler DAPP Service box

This box contains the LiquidScheduler smart contract libraries, DSP node logic, unit tests, and everything else needed to get started integrating / testing the DAPP Network LiquidScheduler in your smart contract.

mkdir cron-dapp-service; cd cron-dapp-service
# npm install -g @liquidapps/zeus-cmd
zeus box create
zeus unbox cron-dapp-service
zeus test -c

Last updated