This post is about bootstrapping of tokens and contracts related to Gold oracle pool and Dexy. New additions will be added to this post as bootstrapping goes on.
top-up , where it is accepting GORTs (at least 1 GORT per call)
withdrawal, where it is possible to withdraw to treasury address (stored in register R5), but not more than 1 GORT per block (last payout block number is stored in register R4), and could be increased to any value no more than current height, and up to the same number of GORTs can be withdrawn. Treasury address for next withdrawal can be updated in this action.
Withdrawal action is similar to treasury contract from pre-genesis state, but the latter was done in ErgoTree, while the current contract is available in ErgoScript.
Hopefully emission to treasury contract may be useful for other applications as well.
This contract is using along with oracle pool’s refresh contract. The refresh contract is allowing to withdraw up to 2 *(number of active oracles) GORTs, and oracle demands for at least 1 GORT. So the dev emission contract can take up to (number of active oracles) GORTs per epoch. Currently the offchain is done in the way that the leading oracle is getting 2 GORTs per epoch, other oracles 1 GORT per epoch, and dev emission contract is getting (number of active oracles) GORTs. This is not enforced via oracle pool data refresh contract atm, but such enforcement could be done.
3 tokens issued to make parallelization of actions easier (so would be simpler to do top-up and buyback at the same time), and all the tokens are bound to buyback contract:
Most of actions in the bank contracts, and also LP redemption are relying on liquidity pool’s price to oracle price ratio. To avoid relying in such actions on two data inputs (which would probably mean a lot of failed txs as the inputs are constantly being updated), and also to extract common functionality from multiple contracts, we use tracking contracts here.
A tracker is like a monitor that triggers an alarm when an event occurs. The alarm continues to “ring” until the tracker resets the alarm, which can only happen after the event has ended. Thus, if the alarm is in a “triggered” state, we can be sure that the event is ongoing (i.e., not yet ended). In our case, the event we are monitoring is the ratio of LP rate and Oracle rate going below (or above) some value. The registers define the ratio to monitor (R4, R5) and whether we are monitoring above or below (R6), along with the height at which the trigger occurred (R7). The value in R7 will be “infinity” if the event has ended.
This box is be spent whenever tracker state must change i.e., move from trigger to reset or vice versa. This box can only be be spent if the tracker state changes.