Auction Keeper Bot Setup Guide
Walkthrough how to set up your own Auction Keeper
Level: Intermediate
Estimated Time: 60 minutes
Audience: Developers
Overview
The Maker Protocol, which powers Multi Collateral Dai (MCD), is a smart contract based system that backs and stabilizes the value of Dai through a dynamic combination of Vaults (formerly known as CDPs), autonomous feedback mechanisms, and incentivized external actors. To keep the system in a stable financial state, it is important to prevent both debt and surplus from building up beyond certain limits. This is where Auctions and Auction Keepers come in. The system has been designed so that there are three types of Auctions in the system: Surplus Auctions, Debt Auctions, and Collateral Auctions. Each auction is triggered as a result of specific circumstances.
Auction Keepers are external actors that are incentivized by profit opportunities to contribute to decentralized systems. In the context of the Maker Protocol, these external agents are incentivized to automate certain operations around the Ethereum blockchain. This includes:
Seeking out opportunities and starting new auctions
Detect auctions started by other participants
Bid on auctions by converting token prices into bids
More specifically, Keepers participate as bidders in the Debt and Collateral Auctions when Vaults are liquidated and auction-keeper enables the automatic interaction with these MCD auctions. This process is automated by specifying bidding models that define the decision making process, such as what situations to bid in, how often to bid, how high to bid etc. Note that bidding models are created based on individually determined strategies.
Learning Objectives
This guide's purpose is to provide a walkthrough of how to use auction-keeper
and interact with a Kovan deployment of the Multi Collateral Dai (MCD) smart contracts. More specifically, the guide will showcase how to set up and run an Auction Keeper bot for yourself. After going through this guide, you will achieve the following:
Learn about Auction Keepers and how they interact with the Maker Protocol
Understand bidding models
Get your own auction keeper bot running on the Kovan testnet
Guide Agenda
This guide will show how to use the auction-keeper to interact with the Kovan deployment of the MCD smart contracts. More specifically, the guide will showcase how to go through the following stages of setting up and running an Auction Keeper bot:
Introduction
Bidding Models
Starting and stopping bidding models
Communicating with bidding models
Setting up the Keeper Bot (Flip Auction Keeper)
Prerequisites
Installation
Running your Keeper Bot (Usage)
Keeper Limitations
Accounting
Getting MCD K-DAI
Getting MCD K-MKR
Getting MCD Collateral Tokens
Testing
Support
We are proud to say that since the Maker Protocol is an open-source platform, all of the code we have created to run the Keeper bot is free and accessible to all.
1. Introduction
Auction Keepers participate in auctions as a result of liquidation events and thereby acquire collateral at attractive prices. An auction-keeper
can participate in three different types of auctions:
Auction Keepers have the unique ability to plug in external bidding models, which communicate information to the Keeper on when and how high to bid (these types of Keepers can be left safely running in the background). Shortly after an Auction Keeper notices or starts a new auction, it will spawn a new instance of a bidding model and act according to its specified instructions. Bidding models will be automatically terminated by the Auction Keeper the moment the auction expires.
Note:
Auction Keepers will automatically call deal
(claiming a winning bid / settling a completed auction) if the Keeper's address won the auction.
Auction Keeper Architecture
As mentioned above, Auction Keepers directly interact with Flipper
, Flapper
and Flopper
auction contracts deployed to the Ethereum mainnet. All decisions which involve pricing details are delegated to the bidding models. The Bidding models are simply executable strategies, external to the main auction-keeper
process. This means that the bidding models themselves do not have to know anything about the Ethereum blockchain and its smart contracts, as they can be implemented in basically any programming language. However, they do need to have the ability to read and write JSON documents, as this is how they communicate/exchange with auction-keeper
. It's important to note that as a developer running an Auction Keeper, it is required that you have basic knowledge on how to properly start and configure the auction-keeper. For example, providing startup parameters as keystore / password are required to setup and run a Keeper. Additionally, you should be familiar with the MCD system, as the model will receive auction details from auction-keeper in the form of a JSON message containing keys such as lot, beg, guy, etc.
Simple Bidding Model Example:
A simple bidding model could be a shell script which echoes a fixed price (further details below).
The Purpose of Auction Keepers
The main purpose of Auction Keepers are:
To discover new opportunities and start new auctions.
To constantly monitor all ongoing auctions.
To detect auctions started by other participants.
To Bid on auctions by converting token prices into bids.
To ensure that instances of bidding model are running for each auction type as well as making sure the instances match the current status of their auctions. This ensure that Keepers are bidding according to decisions outlined by the bidding model.
The auction discovery and monitoring mechanisms work by operating as a loop, which initiates on every new block and enumerates all auctions from 1
to kicks
. When this occurs, even when the bidding model decides to send a bid, it will not be processed by the Keeper until the next iteration of that loop. It's important to note that the auction-keeper
not only monitors existing auctions and discovers new ones, but it also identifies and takes opportunities to create new auctions.
2. Bidding Models
Starting and Stopping Bidding Models
Auction Keeper maintains a collection of child processes, as each bidding model is its own dedicated process. New processes (new bidding model instances) are spawned by executing a command according to the --model
command-line parameter. These processes are automatically terminated (via SIGKILL
) by the keeper shortly after their associated auction expires. Whenever the bidding model process dies, it gets automatically re-spawned by the Keeper.
Example:
Communicating with bidding models
Auction Keepers communicate with bidding models via their standard input/standard output. Once the process has started and every time the auction state changes, the Keeper sends a one-line JSON document to the standard input of the bidding model.
A sample JSON message sent from the keeper to the model looks like the:
Glossary (Bidding Models):
id
- auction identifier.flipper
- Ethereum address of theFlipper
contract (only forflip
auctions).flapper
- Ethereum address of theFlapper
contract (only forflap
auctions).flopper
- Ethereum address of theFlopper
contract (only forflop
auctions).bid
- current highest bid (will go up forflip
andflap
auctions).lot
- amount being currently auctioned (will go down forflip
andflop
auctions).tab
- bid value (not to be confused with the bid price) which will cause the auction to enter thedent
phase (only forflip
auctions).beg
- minimum price increment (1.05
means minimum 5% price increment).guy
- Ethereum address of the current highest bidder.era
- current time (in seconds since the UNIX epoch).tic
- time when the current bid will expire (None
if no bids yet).end
- time when the entire auction will expire (end is set to0
is the auction is no longer live).price
- current price being tendered (can beNone
if price is infinity).
Bidding models should never make an assumption that messages will be sent only when auction state changes. It is perfectly fine for the auction-keeper
to periodically send the same message(s) to bidding models.
At the same time, the auction-keeper
reads one-line messages from the standard output of the bidding model process and tries to parse them as JSON documents. It will then extract the two following fields from that document:
price
- the maximum (forflip
andflop
auctions) or the minimum (forflap
auctions) price the model is willing to bid.gasPrice
(optional) - gas price in Wei to use when sending a bid.
An example of a message sent from the Bidding Model to the Auction Keeper may look like:
In the case of when Auction Keepers and Bidding Models communicate in terms of prices, it is the MKR/DAI price (for flap
and flop
auctions) or the collateral price expressed in DAI for flip
auctions (for example, OMG/DAI).
Any messages written by a Bidding Model to stderr (standard error) will be passed through by the Auction Keeper to its logs. This is the most convenient way of implementing logging from Bidding Models.
3. Setting up the Auction Keeper Bot (Installation)
Prerequisite
Git
This project requires virtualenv to be installed if you want to use Maker's python tools. This helps to ensure that you are running the right version of python as well as check that all of the pip packages that are installed in the install.sh are in the right place and have the correct versions.
X-code (for Macs)
Getting Started
Installation from source:
Clone the
auction-keeper
repository:
Switch into the
auction-keeper
directory:
Install required third-party packages:
Set up the virtual env and activate it:
5. Install requirements:
Potential Errors:
Needing to upgrade pip version to 19.2.2:
Fix by running
pip install --upgrade pip
.
For other known Ubuntu and macOS issues please visit the pymaker README.
4. Running your Keeper Bot
The Kovan version runs on the Kovan Release 1.0.2
To change to your chosen version of the kovan release, copy/paste your preferred contract addresses in kovan-addresses.json
in lib/pymaker/config/kovan-addresses.json
1. Creating your bidding model (an example detailing the simplest possible bidding model)
The stdout (standard output) provides a price for the collateral (for flip
auctions) or MKR (for flap
and flop
auctions). The sleep
locks the price in place for a minute, after which the keeper will restart the price model and read a new price (consider this your price update interval).
The simplest possible bidding model you can set up is when you use a fixed price for each auction. For example:
Once you have created your bidding model, save it as model-eth.sh
(or whatever name you feel seems appropriate).
2. Setting up an Auction Keeper for a Collateral (Flip) Auction
Collateral Auctions will be the most common type of auction that the community will want to create and operate Auction keepers for. This is due to the fact that Collateral auctions will occur much more frequently than Flap and Flop auctions.
Example (Flip Auction Keeper):
This example/process assumes that the user has an already existing shell script that manages their environment and connects to the Ethereum blockchain and that you have some Dai and Kovan ETH in your wallet. If you don't have any balance, check the section below on how to get some.
An example on how to set up your environment: as my_environment.sh
SERVER_ETH_RPC_HOST
- Should not be an infura node, as it doesn't provide all the functionality that the python script needs
ACCOUNT_KEY
- Should have the absolute path to the keystore and password file. Define the path as shown above, as the python script will parse through both the keystore and password files.
Once finalized, you should save your script to run your Auction Keeper as flip-eth-a.sh
(or something similar to identify that this Auction Keeper is for a Flip Auction). In addition, make sure to verify the above copy+pasted script doesn't create extra spaces or characters on pasting+saving in your editor. You will notice an error when running it later below otherwise.
Important Note about Running Auction Keepers on the Ethereum Mainnet!
If you get to the point where the auction keeper bot is not accepting mainnet as a valid argument, this is because there is no
network
parameter. To fix this, just omit that parameter.
Other Notes:
All Collateral types (
ilk
's) combine the name of the token and a letter corresponding to a set of risk parameters. For example, as you can see above, the example uses ETH-A. Note that ETH-A and ETH-B are two different collateral types for the same underlying token (WETH) but have different risk parameters.For the MCD addresses, we simply pass
--network mainnet|kovan
in and it will load the required JSON files bundled within auction-keeper (or pymaker).
3. Passing the bidding the model as an argument to the Keeper script
Confirm that both your bidding model (model-eth.sh) and your script (flip-eth-a.sh) to run your Auction Keeper are saved.
The next step is to
chmod +x
both of them.Lastly, run
flip-eth-a.sh model-eth.sh
to pass your bidding model into your Auction Keeper script.
Example of a working keeper:
After running the ./flip-eth-a.sh model-eth.sh
command you will see an output like this:
Now the keeper is actively listening for any action. If it sees an undercollateralized position, then it will try to bid for it.
Auction Keeper Arguments Explained
To participate in all auctions, a separate keeper must be configured for flip
of each collateral type, as well as one for flap
and another for flop
.
--type
- the type of auction the keeper is used for. In this particular scenario, it will be set toflip
.--ilk
- the type of collateral.--addresses
- .json of all of the addresses of the MCD contracts as well as the collateral types allowed/used in the system.--vat-dai-target
- the amount of DAI which the keeper will attempt to maintain in the Vat, to use for bidding. It will rebalance it upon keeper startup and upondeal
ing an auction.--model
- the bidding model that will be used for bidding.--from-block
to the block where the first urn was created to instruct the keeper to use logs published by the vat contract to bulid a list of urns, and then check the status of each urn.
Call bin/auction-keeper --help
for a complete list of arguments.
Auction Keeper Limitations
If an auction starts before the auction Keeper has started, the Keeper will not participate in the auction until the next block has been mined.
Keepers do not explicitly handle global settlement (
End
). If global settlement occurs while a winning bid is outstanding, the Keeper will not request ayank
to refund the bid. The workaround is to callyank
directly usingseth
.There are some Keeper functions that incur gas fees regardless of whether a bid is submitted. This includes, but is not limited to, the following actions:
Submitting approvals.
Adjusting the balance of surplus to debt.
Biting a CDP or starting a flap or flop auction, even if insufficient funds exist to participate in the auction.
The Keeper will not check model prices until an auction officially exists. As such, it will
kick
,flap
, orflop
in response to opportunities regardless of whether or not your DAI or MKR balance is sufficient to participate. This imposes a gas fee that must be paid.After procuring more DAI, the Keeper must be restarted to add it to the
Vat
.
5. Accounting
The Auction contracts exclusively interact with DAI (for all auctions types) and collateral (for flip
auctions) in the Vat
. More explicitly speaking:
The DAI that is used to bid on auctions is withdrawn from the
Vat
.The Collateral and surplus DAI won at auction end is placed in the
Vat
.
By default, all the DAI and collateral within your eth-from
account is exit
'ed from the Vat and added to your account token balance when the Keeper is shut down. Note that this feature may be disabled using the keep-dai-in-vat-on-exit
and keep-gem-in-vat-on-exit
switches, respectively. The use of an eth-from
account with an open CDP is discouraged, as debt will hinder the auction contracts' ability to access your DAI, and the auction-keeper
's ability to exit
DAI from the Vat
.
When running multiple Auction Keepers using the same account, the balance of DAI in the Vat
will be shared across all of the Keepers. If using this feature, you should set --vat-dai-target
to the same value for each Keeper, as well as sufficiently high in order to cover total desired exposure.
Note:
MKR used to bid on flap
auctions is directly withdrawn from your token balance. The MKR won at flop
auctions is directly deposited to your token balance.
Getting Kovan MCD DAI, MKR and other Collateral tokens
1. Getting MCD K-DAI (K-MCD 0.2.12 Release)
Contract address: 0xb64964e9c0b658aa7b448cdbddfcdccab26cc584
Log into your MetaMask account from the browser extension. Add or confirm that the custom MCD K-DAI token is added to your list of tokens.
This done by selecting "Add Token" and then by adding in the details under the "Custom token" option.
Head to Oasis Borrow here.
Confirm that you are in fact on the Kovan Network before proceeding.
Connect your MetaMask account.
Approve the MetaMask connection.
Below the "Overview" button, find and select the plus sign button to start setting up your CDP.
Select the collateral type you want to proceed with and click "Continue".
e.g. ETH-A
Deposit your K-ETH and generate K-DAI by selecting and inputing an amount of K-ETH and the amount of K-DAI you would like to generate. To proceed, click "Continue".
e.g. Deposit 0.5 K-ETH and generate 100 DAI.
Click on the checkbox to confirm that you have read and accepted the Terms of Service then click the "Create CDP" button.
Approve the transaction in your MetaMask extension.
Click the "Exit" button and wait for your CDP to be created.
After all of these steps have been completed, you will have the generated MCD K-DAI and it will be present within your wallet. You can easily payback your DAI or generate more.
2. Getting MCD K-MKR (K-MCD 1.0.2 Release)
Contract address: 0xaaf64bfcc32d0f15873a02163e7e500671a4ffcd
This requires familiarity with Seth as well as having the tool set up on your local machine. If unfamiliar, use this guide to install and set it up.
Run the following command in Seth:
Address information:
The
0x94598157fcf0715c3bc9b4a35450cce82ac57b20
address is the faucet that issues 1 MKR per request.The
0xaaf64bfcc32d0f15873a02163e7e500671a4ffcd
address is that of the MCD K-MKR token. It will issue 1 MKR.
Important Note: The faucet address and token addresses often change with each dss deployment. The current addresses displayed above are from the 0.2.12 Release. Please visit https://changelog.makerdao.com/ for the most updated release version.
Please refer to this guide to obtain collateral test tokens for Kovan.
3. Getting MCD Collateral Tokens
6. Testing your Keeper
To help with the testing of your Auction Keeper, we have created a collection of python and shell scripts herein that may be used to test auction-keeper
, pymaker
's auction facilities, and relevant smart contracts in dss
. For more information about testing your Auction Keeper with your own testchain visit tests/manual/README.
7. Support
We welcome any questions or concerns about the Auction Keepers in the #keeper channel in the Maker Chat.
Last updated