Liquidations
Liquidations, Price feed stability, Smart contract secuirty
Introduction
When a trader uses leverage, the actual position size is larger than the collateral used to open the position. As a result, there exists a price at which a trader's losses equal the initial collateral used to open the position, at which a trader must be liquidated. However, due to asset volatility (particularly with high leverage), execution time, and potential price feed latency, liquidations must occur before collateral value (- PnL) has declined to zero, instead occurring when collateral value has fallen to 10% of original collateral deposited.
Liquidation Prices
Trades liquidation prices can get closer over time if you pay borrowing fees.
Liquidation Price Distance = Open Price * (Collateral * 0.9 - Borrowing Fees) / Collateral / Leverage.
Liquidation price = If Long: Open Price - Liquidation Price Distance Else (Short): Open Price + Liquidation Price Distance.
For example, let's say that you have opened a long on BTC/USD at 20,000 USD using 100x leverage and 50 USDT collateral, and that you have paid 1 USDT in borrowing fees:
Liquidation Price = 20,000 - 20,000 * (50 * 0.9 - 1) / 50 / 100 = 19,824 USD.
Liquidation Bots
There are certain interactions with the Bitperp protocol which must be automated off-chain, as they cannot be programmed into the smart contracts. These include limit orders, stop losses, take profits, and liquidations. Bitperp lets anyone permissionlessly run a bot for executing these orders. A comprehensive guide and docker container will be available on our github (coming soon). Additionally, we plan on launching a Runes collection soon which if owned by a Liquidation Bot runner will create additional rewards.
Environment Variables for Bitperp Liquidation Bot V1
Name | Description |
---|---|
LOG_LEVEL | Sets the level at which the bot should log. Valid values are: |
ENABLE_CONSOLE_LOGGING | Whether or not log messages should be output to the console. |
ENABLE_FS_LOGGING | Whether or not log messages should be output to a log file. This will log into a |
WSS_URLS | The RPC endpoint URLs that should be used for all blockchain communication. |
PRICES_URL | The WSS endpoint where the Gains backend pricing service is running. |
PRIVATE_KEY | The private key of your account that should be used to execute transactions. ⚠️ DO NOT PUBLISH THIS ANYWHERE. ⚠️ |
PUBLIC_KEY | The public key of your account that should be used to execute transactions. IF ORACLE OPERATOR: Make sure this address is either |
EVENT_CONFIRMATIONS_SEC | The number of seconds that must pass for an event coming from the blockchain to be considered as confirmed and safe for execution against. |
COLLATERAL_PRICE_REFRESH_INTERVAL_SEC | How often collateral prices should be refetched. Defaults to 5s |
MIN_PRIORITY_GWEI | The minimum priority gas fee in GWEI that should be used when triggering orders. |
MAX_GAS_PRICE_GWEI | The maximum gas price in GWEI that should be used when triggering orders. |
MAX_GAS_PER_TRANSACTION | |
PRIORITY_GWEI_MULTIPLIER | A multiplier that can be applied to the current priority gas fee which was fetched from the polygon gas station. |
AUTO_HARVEST_SEC | How frequently the bot will harvest any rewards earned from triggering orders. |
FAILED_ORDER_TRIGGER_TIMEOUT_SEC | How long the bot should wait before it will retry an order after it has failed to successfully process on chain. |
OPEN_TRADES_REFRESH_SEC | How frequently the bot should fully refresh trade data from the Gains smart contracts on chain. By default, the bot is keeping itself up to date based on delta events it's receiving from the chain so this isn't technically necessary, but it's a good fail safe in case the bot fails to hear about a certain even due to connectivity or other issues. Setting this to |
GAS_REFRESH_INTERVAL_SEC | How frequently to get the latest gas prices from the gas station. |
FETCH_TRADING_VARIABLES_REFRESH_INTERVAL_SEC | How frequently trading variables should be refreshed from the Gains smart contracts on chain. There are many variables that go into the calculations of triggering order and these variables need to be freshed to ensure the bot is always using the latest numbers. This is always done at start up, but does not need to be done too frequently at runtime. |
DRY_RUN | Set to |
CHAIN_ID | The ID of the block chain the bot is going to be interacting with. This defaults to |
NETWORK_ID | The ID of the network of the block chain the bot is going to be interacting with. This defaults to |
CHAIN | The name of the block chain the bot is going to be interacting with. This defaults to |
BASE_CHAIN | The name of the base block chain the bot is going to be interacting with. This only needs to be set if you're testing on a network that is forked from a different chain. (e.g. testing on Polygon's Mumbai you would set this to |
HARDFORK | The ethereum hardfork of the block chain the bot is going to be interacting with. This defaults to |
USE_MULTICALL | Whether or not the bot should multicall fetching open orders and other information. Some RPC providers may restrict multicalls. Set to |
MAX_RETRIES | How many times the bot should attempt to trigger an order. Set to |
ORACLE_ADDRESS | FOR ORACLE OPERATORS ONLY: The address of your oracle. The |
Last updated