Every Market Crash Liquidates Long Positions Worth Billions. Those Losses Are Our Gains.

How To Trade Liquidator Token

---

---

Tokenomics & Locks

The Liquidator project uses straightforward tokenomics, without reflection, “taxes”, or other gimmicky features. These tokenomics are the product of careful consideration. To learn why, please read our mini-FAQ below:

---

Question 1:

“Why is the supply of Liquidator token only one million? Why didn’t you mint a quadrillion billion zillion Brazilian tokens? Even in 2022, the concept of ‘market cap’ is not widely understood, and buyers will perceive a token as ‘cheaper’ if they can trade a dollar for a number of tokens so large that expressing it requires scientific notation. Don’t you know that a high token supply encourages buying?”

Answer 1:

We are well-aware of the trend of projects minting more tokens than atoms in the observable Universe. The Liquidator team doesn’t follow trends, however. We are a fundamentally different project, and we set ourselves apart from the memecoins and moonshots in many ways – one of which is avoiding the gimmick of minting absurdly large numbers of tokens. In terms of buyers, we believe in attracting quality over quantity, and the sort of person who buys Liquidator tokens isn’t going to be fooled by high token supply. There are also three major practical reasons for keeping the number of tokens sane.

First, high token supply means that users will be dealing with enormous numbers of tokens in their wallets, and typing out long strings of zeroes is time-consuming and error-prone, especially in the heat of the moment when trading volumes are high and every second counts. Likewise, minting quintillions of tokens ensures that charts and price quotes will forever be a nightmare to read. There is a reason why petrol stations don’t list the price of gasoline in thousandths of a cent per tablespoon; there is a reason why grocery stores don’t list the price of rice in millionths of a dollar per rice grain. Serious traders know that their time is valuable, and we refuse to make them squint at charts because they’re uncertain if there are thirteen or fourteen zeroes after the decimal point on the Y-axis. Long strings of identical digits are difficult to read, and this can result in errors. There is, in fact, a biological analogy to this: even DNA replicase enzymes tend to make mistakes when the same nucleotide is repeated hundreds of times in a row.

Second, inflated token counts scare away serious traders. Not all shitcoins have high supply, and not all tokens with high supply are shitcoins, but the correlation is undeniable. Avoiding this practice is a long-term investment in the reputation and respectability of the Liquidator project.

Third, and perhaps most importantly, the price of a token influences what pair(s) it is listed against on centralized exchanges. Due to technical constraints, exchanges typically will not list tokens with very low value against major stablecoins (USDC, USDT, etc.). Instead, they will insist on listing them only against proprietary stablecoins (ex. one-cent stablecoins that are exchange-specific), and we want to avoid this for obvious reasons.

---

Question 2:

“Why isn’t the Liquidator token reflective? That is – why don’t you have a mechanism in place to discourage selling by ‘taxing’ transactions and sending a portion of each transaction to a burn address, or to a marketing wallet, or to a redistribution wallet, or to the liquidity pool, or to Vitalik? By the way, did you hear that Vitalik just updated his address? That’s right, he has a new address – I’ll DM you his public key. That way, you can send me him tokens. No, that’s not my address, it’s Vitalik’s address – pinkie swear!”

Answer 2:

The decision to avoid reflection, automatic liquidity, and other “gimmicky” tokenomics is based on the combined experience of Liquidator’s developers and (equally important) our moderator team, the latter of whose members has spent years “in the trenches” of Telegram and Discord channels for other crypto projects.

Firstly, reflective tokenomics send a clear message that the token’s only value (or, at least, a substantial part of its value) is derived from an ever-increasing flow of new buyers. In a sense, reflection is the programmatic and mathematical incarnation of a Ponzi scheme: newer purchasers “pay off” earlier purchasers, and when the influx of new buyers ends, the house of cards comes falling down. Liquidator is different: we create value for holders by profiting from liquidations on major exchanges, and we want to make that crystal clear.

Secondly, complex tokenomics ensure that a project’s Telegram channel will be perpetually full of confused users who are panicking because their transactions haven’t gone through due to insufficient slippage. This has the potential to disrupt the conversation around a token, and wastes moderation and community-management resources. Ask any moderator of any cryptocurrency project with reflection, and you’ll hear the same thing: no matter how many messages are pinned, and no matter how many times the need for slippage is emphasized, someone will still be confused. By avoiding such features, the Liquidator project ensures that trading in our token is simple, straightforward, and user-friendly.

Thirdly, reflection and similar features are a major impediment to Centralized Exchange (“CEX”) listings. Representatives of the Liquidator project have been in contact with centralized exchanges since before our token contract was even written, and we consistently hear that exchanges strongly prefer to list tokens without these features. The reason for this is simple: CEX users tend to become displeased when reflection mechanisms cause tokens to “disappear” during withdrawals, and these upset users will complain to their exchanges about this, even though tokenomics are of course outside of an exchange’s control. From the standpoint of an exchange operator, reflective tokens present a high reputational and customer-service risk. This doesn’t mean that centralized exchanges will never list assets with complex tokenomics – certain such tokens have been listed. However, exchanges demand far higher established trading volume and much larger liquidity pools (not to mention much higher listing fees) when dealing with reflectionary tokens. The simple tokenomics of Liquidator’s crypto-asset allow us to list on more exchanges, sooner, and with less cost than would otherwise be possible.

Telegram Channel

Join our Telegram channel at t.me/LiquidatorDAO for discussion.

Liquidator Whitepaper

I. ABSTRACT:

“Liquidate” is a curious verb.

In one sense, liquidation describes the forced closure of a financial position. Consider a Binance trader: he might choose to open a leveraged long position in futures, effectively borrowing money to purchase more units of a cryptocurrency than he could otherwise afford. These tokens are in fact purchased on his behalf by Binance. If the tokens rise in price, he will reap profits far in excess of those he would earn from conventional (i.e., unleveraged) trading. However, if the tokens fall in price to the point where his financial losses are poised to exceed the value of his collateral, Binance will close his position at a loss – typically, at a total loss. We call this “liquidation” because the tokens representing his position are sold in exchange for some liquid asset, typically a fiat currency or a stablecoin representing the same.

In another sense, when the core of the Chernobyl Nuclear Power Plant detonated, the “Liquidators” (Ликвидаторы) were the men who labored in perilous conditions and gave their lives to contain the catastrophic radiation leaks consequent to the blast.

We see one obvious parallel between these uses of the word “liquidate”: in both cases, liquidation is a sort of “cleaning up”, and a way of resolving a dangerous situation. In the financial case, liquidation involves an exchange protecting itself from financial losses by eliminating the risk of “holding a customer’s bags”, i.e., the risk of absorbing the losses of a customer’s unprofitable leveraged Futures position. In the radiological case, liquidation involves a nation protecting its civilians from irradiation by eliminating the risk of further isotope leaks.

There exists a second parallel – a deeper, more meaningful parallel. The explosion at Chernobyl was, at its core (both metaphorically and literally), caused by a chain reaction. This reaction started small: a single neutron collided with an atom of Uranium-235, releasing energy and splitting the destabilized nucleus into fission products, among which were three additional neutrons. Each of these three neutrons split another atom of U-235, and one neutron became three, then nine, then twenty-seven, and so-on. The core had reached criticality, and the rest, of course, is history. Binance, like Chernobyl, is susceptible to chain reactions. Just as a nuclear meltdown can begin with a single neutron, so can a market meltdown begin with a single liquidation: as an insolvent trader is liquidated, Binance must sell off his cryptocurrency holdings before they drop in value further. However, this sell-off itself decreases the price of the cryptocurrency in question, and this price movement can force other traders with leveraged long positions into liquidation. Further liquidations cause additional selling by Binance, which causes further price drops, which in turn cause ever-more liquidations. This process can result in billions of dollars in liquidations, as occurred on April 21st, 2021 (over $5B liquidated) and on May 17th, 2021 (over $2B liquidated).

Money lost in liquidations disappears from the accounts of reckless Futures traders, but it does not disappear in an absolute sense; rather, it accrues to market-makers, holders of short positions, and to an exchange’s “insurance fund”. Money on an exchange, like mass-energy in an atomic nucleus, is conserved. One man’s short position is another man’s long position; one man’s loss is another man’s gain.

Liquidation cascades are hazardous, but just as Man may someday harness the power of atomic chain reactions to conquer the stars, so we at Liquidator.Finance harness the power of liquidation “chain reactions” to extract value from cryptocurrency exchanges and their customers. If a particular trading pair has large amounts of positive leverage (i.e., the dollar-values and leverage factors of long positions are large relative to total liquidity), it is “fissile”: Just like highly-enriched uranium, it is unstable and can be provoked into undergoing a violent chain reaction.

When Liquidator.Finance identifies such currency pairs, we use a portion of the liquidity of our token as collateral to open massive short Futures positions, causing Binance or other exchanges to sell tokens on our behalf, thereby increasing effective supply and dropping prices. As prices drop, traders with long positions are liquidated en masse, each liquidation triggering further price drops and ever-more liquidations, until all or nearly all long positions have been liquidated. The value of these liquidations – potentially in the millions of dollars – is transferred to our short position. We then close the shorts and use the profits both to add liquidity to the Liquidator token (increasing price stability) and to purchase our own tokens at market value (boosting prices). As the value of the Liquidator token and its liquidity pools grows, we take on ever-more-ambitious projects.

Here, we speak primarily of long-position Futures liquidations. However, short positions can also be liquidated. This is rarer, given that most Binance users are broadly bullish on cryptocurrencies (if they weren’t broadly bullish, they likely wouldn’t be on Binance); hence long positions tend to be dominant over shorts for most asset pairs at most times, and squeezing long positions is often easier and more profitable than squeezing short positions. Regardless, the fact that any leveraged position can be liquidated for fun & profit allows Liquidator.Finance to generate revenue for token-holders no matter the market conditions.

The largest cryptocurrency whales use the same strategy we employ, forcing smaller traders into liquidation, consuming their margin accounts like so many krill filtered from the twenty-thousand-league depths of the Seven Seas. The average trader stands little chance against these whales on his own. Individually, we may be minnows, but through Liquidator.Finance, it is we who become the whale.

You wake up in the morning, reach for your phone, and see the headline:

“Crypto Markets Crash In Worst Sell-Off On Record – $20 Billion In Futures Liquidated In Less Than An Hour”

Will you cry into your morning coffee? Or, will you smile, knowing that you’re on the other side of these liquidations, and that these losses are your gains?

---

II. SYMBOLISM:

The Liquidator.Finance project includes Atomic Age symbolism from the USSR in honor of the sacrifices made by the Chernobyl liquidators. As the Liquidators served the Soviet Union, so we serve the purchasers of our tokens.

---

III. THE ECONOMICS OF FUTURES MARKETS

Futures are a subset of financial options, and to understand them, we begin with a treatment of options more generally.

An options contract represents the right to buy or sell some financial asset or commodity in the future at a pre-arranged price. This price, known as the strike price, is agreed upon at the time the contract is bought. The moment an options contract is bought (by a trader) is also the moment when it is sold (by another trader, market-maker, exchange, or other counterparty). Critically, the strike price is intrinsic to the contract and will not fluctuate with market conditions, having the potential to be greater (or less) than the free-market price of the underlying asset at any given time. It is the ability to buy (or sell) units of an underlying asset at a price other than market price that gives options their potential financial value.

An enormous variety of options are available, and this variety is not exclusively due to the range of underlying assets referenced. Even for a single asset (such as Bitcoin, or platinum, or shares of AMC), a wide range of contracts exist, defined in part by the following characteristics:

This whitepaper is not a primer on financial instruments generally. We will not be presenting a comprehensive review of every nuance of every iteration of every options contract available in every nation and in every epoch since the 17th century Dutch Golden Age. Rather, we will focus on futures contracts offered by Binance, which are typical of futures contracts in the cryptocurrency space. Importantly, cryptocurrency futures behave differently from “normal” stock market options in several respects. RobinHood and Binance may have significant overlap in terms of user base, but the financial instruments they offer are dissimilar in critical aspects. Binance’s futures contracts – which are typical of cryptocurrency futures overall – have the following characteristics:

Based on these principles, we can begin a mathematical treatment of futures contracts. Let us first express the relationship between notional value, leverage, and position size:

These relationships are intuitively reasonable. For example, we see that increases in either margin or leverage will result in the increase in the notional value of a position (which in turn amplifies, in an absolute sense, the financial impact of a particular futures investment, all else being equal). We also see that increasing the notional value of a position or decreasing the margin will increase leverage: the more a man borrows (or the less collateral he puts up), the higher his leverage.

Now, let’s generalize these equations so that we can analyze cases in which a trader has multiple positions against a single margin pool. This will allow us to simulate the positions of traders who use Binance’s “cross-margin” feature, or equivalent features on other exchanges. The simulation of split-margin traders is much simpler, as we can treat each position independently. For cross-margined cases, we write:

We consider n to be the total number of positions held by a trader, and we count positions from i=0, i=1, i=2, etc. until we reach i=n.

Measuring leverage is useful, but this information alone will not tell us when a trader will be liquidated. Even a trader with infinitely-high leverage is in theory no risk to an exchange as long as his open futures are in net profit. Therefore, in the next section of this whitepaper, we will add the opening and current prices of futures positions to our calculations.

---

IV. LIQUIDATION IN FUTURES MARKETS

As cryptocurrency traders, we are accustomed to thinking about futures markets from the perspective of a trader. It is natural to contemplate a topic from one’s own perspective: you probably don’t think much about economic development from the standpoint of a Tuvaluan, as you don’t live in the tiny island-nation of Tuvalu; you probably don’t think much about cryptocurrency from the perspective of an exchange operator, as you don’t run a cryptocurrency exchange. If, by chance, you live in Tuvalu or operate a cryptocurrency exchange (or both), feel free to congratulate yourself: you are the exception.

As Sun Tzu advised, whenever you are involved in a financial transaction, you ought to walk a kilometer in your counterparty’s shoes. Imagine you run a cryptocurrency exchange and offer leveraged trades: you don’t want to end up rekt when your users take on reckless positions (which some of them inevitably will), so you develop a system to liquidate their positions when prices move against them. Your first step is to calculate a trader’s instantaneous profit or loss (which we will call “return”) at any time t, as a function of the notional value of their position, the direction of the position (long or short), and the delta between the entry price and current price of the traded asset:

If this return-on-position ever falls below margin, then that position is “underwater”: closing it will result in a loss greater than the trader’s collateral, meaning that the exchange cannot confiscate enough money from the trader to make up the loss. An exchange in this position is between a rock and a hard place: it can close the position at a loss and pay off a portion of a user’s bad debt, or it can hold the position and hope it will enter profit, with the risk that the losses will increase over time if past price trends continue. This latter choice is particularly perilous in the case of short futures positions: asset prices cannot fall below zero but can rise without limit, so a short futures position can sink infinitely deep underwater, incurring infinite loss.

To prevent these sorts of situations, exchanges enforce maintenance-margin values. We will refer to them hereafter as “safety margins”, to avoid confusion with other uses of the term “margin”. A safety margin is the degree to which a position’s collateral exceeds its instantaneous profit (or loss). Let’s begin by expressing safety margin as a dollar-value:

We can also express safety margin as a percentage of nominal position value:

Generally, exchanges set larger safety-margin percentage requirements for larger fiat-value positions. This is because, the larger a position, the more difficult it is to liquidate (all else equal). Further, larger positions will result in larger absolute losses if they are not closed before going underwater. Similarly, higher safety-margin requirements are enforced for positions that involve thinly-traded assets, since less liquidity is available. For example, for BTC-USD futures, Binance requires that a $250k position be collateralized at 1% (i.e., $2,500 of minimum collateral), whereas a $250M position must be collateralized at 25% (i.e., $62.5M minimum collateral). BTC-USD is the highest-volume futures pair on Binance and most other exchanges, and so it has the loosest margin requirements of all pairs. Let’s examine safety-margin requirements for certain other pairs, assuming a $100k nominal position in each case:

Comparing the extremes is helpful: Binance will allow a trader to come within $5k of being underwater on a $100k position in BAT, but that same trader is allowed to come within $500 of being underwater for an identically-sized position in BTC. Binance provides tables listing safety margins for four categories of cryptographic assets (BTC, ETH, select large-caps, and select small-caps); let’s present them here, as we will need them for calculations later:

1. Bitcoin-USD Pair (supports both Tether/USDT and Binance Dollar/BUSD):

2. Ethereum-USD Pair (supports Tether/USDT only; Binance Dollar support under development):

3. Medium-Sized Pairs (supports Tether/USDT only):

4. Smallest-Sized Pairs Not Otherwise Specified (supports Tether/USDT only):

We can see the trend in maintenance margins by plotting the four tiers of futures contracts on a log-log chart. We use longer-wavelength colors to indicate higher-risk trading pairs:

We can put our equations and tables to work by making a sample calculation. For no discernible reason, the ‘Chans have adopted ChainLink as their preferred cryptocurrency, selecting it from among myriad alternatives without any definite cause. We will honor this accident-of-history by analyzing a hypothetical ChainLink long position with nominal value of $1M, entry price of $20, and collateral of $200,000. The leverage factor of this position is:

By the standards of cryptocurrency, this is relatively “moderate” leverage, and well within the limits established by Binance. Looking at Table 3, we see that ChainLink is a “medium-sized pair”, and that a position of $1M requires a 5% safety margin. This theoretically allows leverage as high as (1) / (5%) = 20x, so our ChainLink bull is not over-leveraged (at least, not in the sense of risking a margin call) at the current price.

We can calculate this trader’s liquidation point (i.e., the price that ChainLink must fall to in order to trigger a liquidation) by setting the “safety margin”, S%, to 5%. We can then rearrange to find P(t), the price at time t, which will push the trader’s margin to this level:

This trader will be liquidated if the price of ChainLink (LINK) falls from $20 to $16. This liquidation-point calculation is the first of three key concepts critical to the Liquidator Finance strategy.

V. FUNDING RATES: THE CANARY IN THE COALMINE

The second critical calculation relates to funding rates in futures markets. In order to understand funding rates, we must first understand the difference between “spot” and “mark” prices on exchanges. The “spot” price is what we generally think of as the fiat price of an asset; it is the spot price that one reads on CoinMarketCap (CMC) and CoinGecko (CG), and when prices are quoted in the news, they are invariably spot prices. The “mark” price of an asset, however, is the price that is quoted in futures markets. Cryptocurrency perpetual futures are not excercisable in the sense that options are; therefore the futures market and spot market are isolated and can have different prices. For example, at the time of this writing, the prices of Bitcoin on Binance are as follows:

Although spot and futures markets are isolated from each other, both are subject to the same principles of supply-and-demand (in fact, all assets are subject to these principles). The fact that the BTC mark price is higher than the spot price (by $16.95, or roughly 0.04%) demonstrates that there is more demand for Bitcoin futures contracts than Bitcoin itself. It’s not difficult to understand why: futures offer more leverage than spot positions, and with net bullish sentiment, futures are more attractive than spot positions. As a result, futures are priced at a premium. Note that this divergence is reflective of trader behavior and nothing more; the fact that BTC futures contracts cost more than spot Bitcoin does not imply that futures are “better” in any deep theoretical sense.

In conventional, fixed-term futures markets, the contract price (“mark price”) will naturally converge towards the spot (“true”) asset price, because divergence presents an arbitrage opportunity to those with enough capital to actually exercise options. In this sense, fixed-term futures are self-correcting towards spot prices for the same reason that stock options will likewise converge towards market value. Perpetual futures, however, are not self-correcting. Without any mechanism to force mark prices towards spot prices, exuberant traders could purchase long futures for some asset to such an extent that the mark price would rise far above the spot price, rendering these financial instruments useless as they no longer reflect changes in the price of the base asset. Similarly, a pack of bears opening short futures positions could force mark price far below spot price.

Binance and other exchanges therefore use a system known as “futures funding” to push mark prices towards spot prices. The funding system is, in a sense, a way of financially punishing those who open positions that increase divergence, while rewarding those who open positions that decrease divergence. Funding involves the involuntary transfer of collateral balances between traders, where the amount of transfer is proportional to the notional value of a position. Therefore, two traders with identical collateral balances taking positions in the same direction on the same asset pair at the same time will not necessarily experience equal transfers: if one trader is more leveraged than the other (and hence has a larger notional position against the same collateral), he will experience larger transfers.

Within Binance, funding occurs every 8 hours. A positive funding rate indicates that positions are overall long (and so long-holders will pay short-holders), whereas a negative funding rate implies that positions are overall short (and shorts pay longs). The funding amount a trader will pay (or receive) is simply the product of funding rate and notional position value:

All futures pairs on Binance are synchronized with respect to funding rates; that is, funding on the ETH-USD pair occurs at the same time as funding on the BTC-USD pair, and so-on. For a trader with n positions associated with the same margin account (cross-leverage), the net funding for positions i=0 to i=n will be :

From a trader’s perspective, funding rates are important because of their potential to erode margins and push a position closer to liquidation even if the market itself does not move in a direction adverse to that trader’s position. Simply holding a position for an excessive amount of time can lead to losses if that position is in the same net direction as most other positions. This means that a trader who “goes with the flow” and is generally bullish while others are bullish and bearish while others are bearish will see his collateral decrease the longer a position is held open. This doesn’t apply to all traders, but it applies to most, because most traders are indeed “going with the flow” – by definition, “going with the flow” is whatever most traders are doing. Certain traders will take a contrarian stance, opening shorts while futures markets are net long, and vice versa. These traders can generate modest gains at minimal risk, and their strategy is a reasonable one, despite the mockery they receive on Binance Trollbox. Funding transfers are trader-to-trader, and while exchanges set funding rates, they do not themselves collect or pay out these transfers. Hence, what is to some the cost of doing business (i.e., the cost of holding a position open) is to others a golden opportunity.

Liquidator Finance does engage in opening and closing futures positions, so these considerations are of some interest to us. However, our primary interest is not in how funding rates affect long-term profitability of positions, but rather, in what we can uncover about futures markets by studying funding rates.

In the most general sense, funding rates reveal how ripe the futures market is for liquidations. When funding rates are high, this indicates that most traders are highly-leveraged into long positions, setting the stage for a long squeeze. When funding rates are low (i.e., negative and with high absolute value), this indicates high leverage in short positions and prepares us for a short squeeze. When funding rates are near-zero, this indicates little net leverage and suggests that we at Liquidator would do best to bide our time before entering the markets and triggering liquidations to generate profit.

Funding rates on Binance and other exchanges are the sums of two main components: the static rate and dynamic rate. We will define each in turn.

Prior to delving into the dynamic funding rate, we need to examine how exchanges model the price-impacts of trades. We know, from supply and demand, that opening a long-futures contract will tend to raise mark prices, while opening a short-futures contract will tend to lower mark prices. The opposite occurs during closure: closing a long position pushes prices down, and closing a short position pushes prices up. These perturbations are caused by the finite liquidity levels seen on all real exchanges. In an “ideal” world, in which all exchanges had infinite liquidity and all trades were infinitesimally small relative to this liquidity pool, trades would have zero price impact, their puny volume being absorbed into an oceanic order-book. The non-ideality of the real world makes Liquidator’s strategy possible.

Binance uses the term “impact margin notional” (IMN) to designate a dollar-value which corresponds to the largest notional futures position that could be opened with $200 in collateral. The IMN therefore depends on the leverage available in a futures market. Currently, there are four IMNs, corresponding to four tiers of cryptocurrency, ranging from the most thickly-traded to the most thinly-traded:

The impact margin notional values for these four tiers are therefore:

From these IMN values, Binance performs actual trades on its own platform once per minute in each futures market and monitors the price impact of these trades. Specifically, it monitors the bid-ask spread based on the average price at which its orders fill. If nothing else, this approach should serve as a testament to just how complex liquidity is: so complex that the largest cryptocurrency exchange in history chooses to determine it experimentally rather than to model it, despite having access to order books and various proprietary information of great value to any data scientist.

The Dynamic Funding Rate is expressed in terms of bid-fill and ask-fill prices as below:

There are two special cases in which this equation is trivial and evaluates to zero. The first is the case in which (A_bid – Q_spot) = (Q_spot – A_ask), i.e. the upwards price impact of opening a long position is exactly equal to the downwards price impact of opening a short position, assuming equal position values. The second is the infinite liquidity case, in which neither asks nor bids influence the price at all. We will ignore these cases going forward in this whitepaper; at Liquidator, we are interested in cases where dynamic funding rate is non-zero and the market is unbalanced.

We can make the above equation more useful by changing how we think about the difference between bid and spot prices. Specifically, (A_bid – Q_spot) will always be exactly half the upwards price impact of opening a long futures contract for an IMR value (in the case of BTC, $25k) worth of tokens. Suppose the current price of BTC is $100,000 and a purchase of a $25,000 long-futures contract pushes the price up to $100,001. The very first infinitesimally-small portion of this order fills at $100,000 (the mark price before opening), and the very last infinitesimally-small portion fills at $100,001 (the price after the order completely fills). Therefore the average fill price is halfway between these at $100,000.50, and (A_bid – Q_spot) = ($100,000.50 – $100,000) = $0.50, or exactly half the price impact. We can say the same thing about (Q_spot – A_ask), which is exactly half the (downwards) price impact of opening a short futures contract of IMR value. If we treat these variables as changes in price over time (specifically, between the time immediately before an order fills and the time immediately after it fills), we can rewrite them as derivatives:

These derivatives cannot be solved symbolically; they can only be solved approximately through numerical methods based on computations drawing from order book and open interest data. The exact approach we take is a trade secret of the Liquidator DAO, and we will not disclose it here in order to protect our competitive advantage. Disclosing our approach and the API queries involved could also threaten our API access, primarily for exchange APIs but potentially also for third-party data sources, namely Glassnode. Qualitatively, we can say this: while Binance calculates funding rate based upon the price impacts of trades, we have an effective method to reverse the equation. We start with the funding rate provided by Binance and use it in combination with other data sources to determine the price impacts of opening short or long positions. When price sensitivity is high, we rapidly open positions that force other traders into liquidation, allowing us to close our contracts quickly and at enormous profit.

---

VI. THE LIQUIDATOR STRATEGY

“Don’t trade futures. Don’t trade with leverage”.

You’ve heard it before, including from many of the top thinkers in the cryptocurrency space. They aren’t saying this because they are financially cautious or “conservative”; very few crypto traders could be honestly described as such, at least by the standards of conventional finance. They’re saying this because the overwhelming majority of leverage traders lose money when their positions are inevitably liquidated into insurance funds. Exchanges profit so heavily from busted futures positions that they have been credibly described as being “liquidation engines”. Criticism of leveraged-future trading doesn’t stem exclusively from fears about traders getting rekt; liquidations also affect the spot market, and the volatility caused by over-leveraged traders losing their shirts has contributed to major crashes in the larger crypto market, scaring retail investors and institutions alike away from digital assets. Therefore, there is a widespread belief that futures trading is- for lack of a better word- “bad” for cryptocurrency writ large.

The Liquidator DAO does not take any absolute position on leverage being “good” or “bad”. Only a Sith deals in absolutes, after all, and there’s a massive difference between trading altcoin futures at 125x leverage and using short futures at moderate leverage to hedge against market downturns. What we can say is this: As long as futures exist, traders will from time to time get rekt, and that money has to go somewhere. Why should exchanges have all the fun? We’ll take those profits, thank you.

We generate revenue for token-holders in an eight-stage process, as summarized in the following diagram:

In greater detail, the stages are as follows:

Stage 1: Liquidator DAO members study the futures markets and determine a strategy for triggering a liquidation cascade, using DAO features to vote on proposals. Once a promising target is identified, we move onto the next step.

Stage 2: A small portion of liquidity is temporarily removed from the DEX (decentralized exchange) pool. This removal is “symmetrical”, i.e. Liquidator tokens and Ethereum are withdrawn in amounts that are equal in value. For example, if the total liquidity pool is 500,000 Liquidator tokens and 5,000 ETH (implying that each Liquidator token is worth 1/100 of 1 ETH, or roughly $25 given market prices at the time of this writing), DAO members might vote to remove 10% of liquidity. This removed liquidity constitutes 500 ETH and 50,000 Liquidator tokens. The Liquidator tokens are held for safekeeping on a DAO-controlled wallet, while the ETH are transferred from the DAO wallet to an exchange. Importantly, this liquidity removal will not affect the Liquidator token’s price; the ratio of Ethereum to tokens has not changed.

Stage 3: The ETH tokens are deposited on an exchange, such as Binance, by the DAO’s designee. There, they are converted into stablecoins at market prices. Typically, we convert to USDC, BUSD, or USDT. The Liquidator DAO recognizes the potential backing issues related to certain stablecoins; therefore we deal with the most reputable stablecoins available and hold them only for long enough to execute our liquidation strategy.

Stage 4: Liquidator DAO uses the stablecoins as collateral in a margin account. In this example, 500 ETH is equivalent to $1.25M in collateral, which (at 10x leverage) provides over ten million dollars of market-moving power.

Stage 5: We quickly open a massive but well-collateralized position, triggering a sudden price change in the targeted futures market. In the case of a long-squeeze (i.e., when we short a cryptocurrency for which there are many over-leveraged long traders), our position causes a dramatic drop in the price of the targeted currency, resulting in long traders being rapidly liquidated, in turn leading to further price drops and further liquidations. This pushes our short position further and further into the green, with leverage amplifying our gains. This is the stage in which value is generated.

Stage 6: We gradually close our position over the course of several hours or days so as not to further disturb prices and so as to maximize our profits at the most favorable exit prices. If we assume that our $1.25M in collateral generated $12.5M in potential leverage and the liquidation avalanche we trigger drops prices of the token we short by 20%, our total holdings at the end would be $3.75M ($1.25M in collateral and $2.5M in profits).

Stage 7: We now convert back from stablecoins to ETH, and withdraw this Ethereum to a DAO-controlled wallet. The original Liquidator tokens and the ETH used for collateral are added back to the liquidity pool.

Stage 8: The excess profit (in this example, $2.5M in ETH) is used to purchase tokens from the liquidity pool. Since this results in adding ETH and subtracting Liquidator tokens, the ETH-to-token ratio will rise, and Liquidator tokens will become more valuable. Assuming an injection of $2.5M into a liquidity pool of containing 5,000 ETH, we would expect a price increase of 20%. This is the stage in which value generated previously is distributed to Liquidator token holders.

VII. DAO FEATURES & VOTING

The Liquidator DAO allows token-holders to create and vote on proposals (as well as to designate trusted executors), with voting power proportionate to token balance. Hence, someone with 2 tokens has twice the voting power as someone with 1 token. We have taken precautions in designing our smart contract in order to eliminate the risk of “DAO piracy”, or takeover of the DAO by a bad actor with 51% voting power. For example, the minting function is permanently revoked, such that a bad actor sailing the high seas will not be able to board our ship and create a proposal to mint himself extra tokens, regardless of how swashbuckling he is and regardless of whether or not he controls over 50% of all cannonballs.

We have developed a system which is signature-based and which stores proposals and vote totals off-blockchain. Liquidator DAO members still use Metamask to interact with the DAO, but will merely sign messages (rather than making transactions) with their wallets. This provides greater user safety, and equally importantly, ensures that proposal-creation and voting are cost-free; no Liquidator token-holder will be required to pay for gas fees in order to interact with the DAO. Use the link below to access the Liquidator DAO:

IIX. TOKENOMICS

The tokenomics of Liquidator DAO are simple: There exist exactly 1,000,000 (one million) tokens, and no further tokens can ever be minted. You may confirm this by examination of the Solidity contract, as verified by Etherscan:

Minting is a bit like your parents having sex: If they didn’t, then you would exist, and similarly, without minting, Liquidator wouldn’t exist. We may not particularly enjoy thinking about minting, but it had to happen. The Solidity contract linked above therefore does contain a minting function, but it fired only once – namely, when the contract was compiled and deployed. This function is not callable from any external address once the contract is live on Ethereum. The only callable functions are those needed to transfer tokens and track balances, namely:

See the FAQ section for an explanation of why Liquidator uses simple tokenomics. In brief, we have avoided gimmicks such as minting enormous numbers of tokens or employing reflectionary mechanisms because these offer little utility and increase the complexity of the smart contract. In particular, by avoiding these silly features, we ensure that Liquidator tokens will be listed more promptly on centralized exchanges than would otherwise be the case. Centralized exchanges very rarely list reflectionary tokens due to the customer service nightmare caused by traders who do not understand why some percentage has been deducted from their withdrawals. With our straightforward tokenomics, we avoid such problems.

We will inevitably face another, higher-level question about our tokenomics: Why Ethereum? In life, there are few certainties. Among them are death, taxes, and that from time to time, someone in our Telegram chat will declare:

“Don’t you know how high ETH gas fees are? Why did you build on Ethereum? You should have built the Liquidator project on {Avalanche/Cardano/EOS/Terra/Solana/PolkaDot/hBar/Binance SmartChain/Flare Network (Ripple)/AlgoRand/whatever other ‘Ethereum killer’ has been launched in the last five minutes}”

In some cases, the Telegram anons who type these messages are shilling for their chains-of-choice, usually because they have financial investments in Layer-1 networks or are being paid by someone who does. In other cases, these anons may be genuinely concerned about gas fees, and may believe honestly (though not necessarily correctly) that some Ethereum alternative would be better for the Liquidator project. In certain cases, we can articulate exactly why we didn’t build Liquidator on an alternative L1. For example:

In a more general sense, the Liquidator developers and investors believe in Ethereum not merely despite its gas fees, but in part because of its gas fees. The fact that Ethereum vastly exceeds other chains in terms of total value locked (TVL) in spite of its fees is a testament to its endurance and the strength of its developer ecosystem. Ethereum is also the most decentralized of any virtual-machine blockchain, and is the most secure due to its outsize share of hashpower. The Liquidator DAO is a long-term project, and we’re confident that Ethereum will remain a major player in the cryptocurrency space a decade from now; after all, Ethereum is already a decade old, and if it were poised to fail, it would already have failed by now. Can one say with equal conviction that Binance SmartChain (PancakeSwap) or Avax or Cardano will still exist in a meaningful way in the year 2030? We think not.

Cryptocurrencies are frequently evaluated according to an evolutionary or Darwinian model. This model assumes survival of the fittest: that those crypto networks with desirable, useful traits (high security, good decentralization, strong privacy, voluminous transaction bandwidth, quick block times, easy contract creation, deflationary tokenomics, etc.) will out-compete and ultimately displace cryptocurrencies with worse technical qualities. However, the Liquidator team takes issue with such a model, primarily because it does not match what we empirically see: Litecoin is “superior” to Bitcoin in nearly every technical respect, but Litecoin is clearly in decline relative to its competitors.

We propose that cryptocurrencies are less like bacteria subject to evolutionary pressures in a Petri dish, and more like religious cults. The cryptocurrency world has its own mysterious prophet (Satoshi Nakamoto), its own living Pope to direct the faithful (Vitalik Buterin), its own Mecca (Bitcoin-Volcano City, El Salvador) and its own angels and demons (Sminem and the Bogdanoff twins, respectively). We have our own schisms: just as the Protestant Reformation led to the proliferation of Christian sects, and just as disagreements over succession to Mohammed led to the Sunni/Shia split, arguments over transaction reversals in response to a 2016 DAO hack led to a hard fork between Ethereum and Ethereum Classic.

Joseph Smith led the Latter-Day Saints out of persecution under the cruel, polygamy-prohibiting sheriffs of Rochester, New York and into the Promised Land of Salt Lake City.

Moses led the Jews out of slavery under Pharaoh Ramses and into the Promised Land of milk and honey.

Satoshi Nakamoto led the Crypto-Bros out of bondage under the IRS and into the Promised Land of tax fraud and unregistered machine guns.

Prometheus stormed Mount Olympus and stole the secret of fire from the Elder Gods; Satoshi stormed the Internet and stole the secret of currency from the Elderly Federal Reserve Chairman.

We all have our legends, don’t we?

If we understand cryptocurrency as a sort of religion, we next need to recognize that “religion” and “spirituality”, while related words, are not synonyms. If they were synonyms, then we’d only need one word in our language. Spirituality can be an individual philosophy or set of beliefs, but religion is, by definition, an activity that people engage in together. Religion, like cryptocurrency, depends on community and is a fundamentally social and interactive phenomenon: you can mint the most sophisticated of all cryptocurrencies in your wife’s boyfriend’s basement, but if nobody but you uses it, then it is irrelevant for all practical purposes. Our conviction that Ethereum is the best platform for the Liquidator DAO is based in part on the Strict Church Theory (an unfortunately-named sociological concept; perhaps “Sectarian Success Theory” would be a better term).

The Strict Church Theory holds that sectarian religious movements are successful not in spite of their strictness and conflicts with the outside world, but rather because of this strictness. Note that, within this whitepaper, “sectarian” is used in the technical sense, not in the way that Margaret Thatcher uses it (neither English Protestants nor Irish Catholic Republicans are really “sectarian”, and the Troubles are better understood as economic conflicts than as sectarian conflicts). At first glance, the success of strict religious groups (particularly, their success in retaining members) seems surprising: one would expect that, the stricter a religious sect is, the more difficult it would be to retain members, because strictness creates disincentives to continued membership. For example, within Judaism, one would expect that the strict rules of Orthodox Judaism (ex. prohibitions on wearing conventional clothing and the requirement of hours of prayer daily) would lead to a high rate of people leaving that sect. The more lax rules of Conservative Judaism (ex. keeping Kosher) would lead to a moderate rate of “turnover”, and the minimal rules of Reform Judaism would be expected to result in the lowest rate of adherents losing their religion. Yet, this is exactly the opposite of what is observed: in reality, very few Orthodox Jews lose their religion, whereas very many Reform Jews do so, with Conservative Jews somewhere in between. The same is true within Christianity: highly “relaxed” Christian groups, such as Mainline Protestants, have far lower retention than strict groups such as Apostolic Anabaptists, among whom are the Amish. This seems surprising: one would imagine that retaining Amish Christianity (in the case of men, that means a lifetime of hard manual labor from sunrise to sunset without electronics or modern entertainment; in the case of women, it means bearing a natural number of children and raising a large family in a technologically-primitive setting) would be a harder pill to swallow than going to church once a year at Easter. The Amish do know about cellular phones, automobiles, the Internet, cryptocurrency, and all the other conveniences of modern life; they even allow their young people to go out “into the world” during Rumspringa, but the overwhelming majority of Amish return from their adventures in mainstream American society and make lifelong commitments to living the faith of their birth. Of those born Amish, roughly 98% will die Amish, a truly remarkable retention rate. Similar patterns are seen in Islam, Sikhism, Hinduism, and other faiths, including indigenous religions: the stricter the faith, the higher the retention. Why is this?

We need to get beyond logical fallacies, such as the obvious ad hominem attack (“The Amish are all brainwashed! That’s why they don’t leave their faith!”). In truth, the Amish would probably say the same about us, and if they knew the depths of our technology additions, the collective centuries of sleep that crypto-traders have lost staring into their monitors with candle-charts reflected in their bloodshot eyes at 4:00 in the morning, they’d have some good evidence. Criticizing others as being hopelessly “brainwashed” or “indoctrinated” is useless: Every religious and political faction thinks this about its opponents. Instead, we need to recognize two realities:

The founders of Liquidator DAO believe that Ethereum is like the faith of the Amish: the fees may be high, but that is a positive: it screens out those who lack true conviction in cryptocurrency. The value of Ethereum (or any other cryptocurrency, or any fiat currency) comes from a single source:

Sola Fide – Only Faith.

IX. SOLIDITY CONTRACT

Below is the Solidity contract for the Liquidator token in its entirety:

pragma solidity ^0.8.0;

/**
* @dev Interface of the ERC20 standard as defined in the EIP.
*/
interface IERC20 {
/**
* @dev Returns the amount of tokens in existence.
*/
function totalSupply() external view returns (uint256);

/**
* @dev Returns the amount of tokens owned by `account`.
*/
function balanceOf(address account) external view returns (uint256);

/**
* @dev Moves `amount` tokens from the caller's account to `recipient`.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transfer(address recipient, uint256 amount) external returns (bool);

/**
* @dev Returns the remaining number of tokens that `spender` will be
* allowed to spend on behalf of `owner` through {transferFrom}. This is
* zero by default.
*
* This value changes when {approve} or {transferFrom} are called.
*/
function allowance(address owner, address spender) external view returns (uint256);

/**
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* IMPORTANT: Beware that changing an allowance with this method brings the risk
* that someone may use both the old and the new allowance by unfortunate
* transaction ordering. One possible solution to mitigate this race
* condition is to first reduce the spender's allowance to 0 and set the
* desired value afterwards:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
*
* Emits an {Approval} event.
*/
function approve(address spender, uint256 amount) external returns (bool);

/**
* @dev Moves `amount` tokens from `sender` to `recipient` using the
* allowance mechanism. `amount` is then deducted from the caller's
* allowance.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transferFrom(
address sender,
address recipient,
uint256 amount
) external returns (bool);

/**
* @dev Emitted when `value` tokens are moved from one account (`from`) to
* another (`to`).
*
* Note that `value` may be zero.
*/
event Transfer(address indexed from, address indexed to, uint256 value);

/**
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
* a call to {approve}. `value` is the new allowance.
*/
event Approval(address indexed owner, address indexed spender, uint256 value);
}

// File: @openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol

// OpenZeppelin Contracts v4.4.0 (token/ERC20/extensions/IERC20Metadata.sol)

pragma solidity ^0.8.0;

/**
* @dev Interface for the optional metadata functions from the ERC20 standard.
*
* _Available since v4.1._
*/
interface IERC20Metadata is IERC20 {
/**
* @dev Returns the name of the token.
*/
function name() external view returns (string memory);

/**
* @dev Returns the symbol of the token.
*/
function symbol() external view returns (string memory);

/**
* @dev Returns the decimals places of the token.
*/
function decimals() external view returns (uint8);
}

// File: @openzeppelin/contracts/utils/Context.sol

// OpenZeppelin Contracts v4.4.0 (utils/Context.sol)

pragma solidity ^0.8.0;

/**
* @dev Provides information about the current execution context, including the
* sender of the transaction and its data. While these are generally available
* via msg.sender and msg.data, they should not be accessed in such a direct
* manner, since when dealing with meta-transactions the account sending and
* paying for execution may not be the actual sender (as far as an application
* is concerned).
*
* This contract is only required for intermediate, library-like contracts.
*/
abstract contract Context {
function _msgSender() internal view virtual returns (address) {
return msg.sender;
}

function _msgData() internal view virtual returns (bytes calldata) {
return msg.data;
}
}

// File: @openzeppelin/contracts/token/ERC20/ERC20.sol

// OpenZeppelin Contracts v4.4.0 (token/ERC20/ERC20.sol)

pragma solidity ^0.8.0;

/**
* @dev Implementation of the {IERC20} interface.
*
* This implementation is agnostic to the way tokens are created. This means
* that a supply mechanism has to be added in a derived contract using {_mint}.
* For a generic mechanism see {ERC20PresetMinterPauser}.
*
* TIP: For a detailed writeup see our guide
* https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
* to implement supply mechanisms].
*
* We have followed general OpenZeppelin Contracts guidelines: functions revert
* instead returning `false` on failure. This behavior is nonetheless
* conventional and does not conflict with the expectations of ERC20
* applications.
*
* Additionally, an {Approval} event is emitted on calls to {transferFrom}.
* This allows applications to reconstruct the allowance for all accounts just
* by listening to said events. Other implementations of the EIP may not emit
* these events, as it isn't required by the specification.
*
* Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
* functions have been added to mitigate the well-known issues around setting
* allowances. See {IERC20-approve}.
*/
contract ERC20 is Context, IERC20, IERC20Metadata {
mapping(address => uint256) private _balances;

mapping(address => mapping(address => uint256)) private _allowances;

uint256 private _totalSupply;

string private _name;
string private _symbol;

/**
* @dev Sets the values for {name} and {symbol}.
*
* The default value of {decimals} is 18. To select a different value for
* {decimals} you should overload it.
*
* All two of these values are immutable: they can only be set once during
* construction.
*/
constructor(string memory name_, string memory symbol_) {
_name = name_;
_symbol = symbol_;
}

/**
* @dev Returns the name of the token.
*/
function name() public view virtual override returns (string memory) {
return _name;
}

/**
* @dev Returns the symbol of the token, usually a shorter version of the
* name.
*/
function symbol() public view virtual override returns (string memory) {
return _symbol;
}

/**
* @dev Returns the number of decimals used to get its user representation.
* For example, if `decimals` equals `2`, a balance of `505` tokens should
* be displayed to a user as `5.05` (`505 / 10 ** 2`).
*
* Tokens usually opt for a value of 18, imitating the relationship between
* Ether and Wei. This is the value {ERC20} uses, unless this function is
* overridden;
*
* NOTE: This information is only used for _display_ purposes: it in
* no way affects any of the arithmetic of the contract, including
* {IERC20-balanceOf} and {IERC20-transfer}.
*/
function decimals() public view virtual override returns (uint8) {
return 18;
}

/**
* @dev See {IERC20-totalSupply}.
*/
function totalSupply() public view virtual override returns (uint256) {
return _totalSupply;
}

/**
* @dev See {IERC20-balanceOf}.
*/
function balanceOf(address account) public view virtual override returns (uint256) {
return _balances[account];
}

/**
* @dev See {IERC20-transfer}.
*
* Requirements:
*
* - `recipient` cannot be the zero address.
* - the caller must have a balance of at least `amount`.
*/
function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
_transfer(_msgSender(), recipient, amount);
return true;
}

/**
* @dev See {IERC20-allowance}.
*/
function allowance(address owner, address spender) public view virtual override returns (uint256) {
return _allowances[owner][spender];
}

/**
* @dev See {IERC20-approve}.
*
* Requirements:
*
* - `spender` cannot be the zero address.
*/
function approve(address spender, uint256 amount) public virtual override returns (bool) {
_approve(_msgSender(), spender, amount);
return true;
}

/**
* @dev See {IERC20-transferFrom}.
*
* Emits an {Approval} event indicating the updated allowance. This is not
* required by the EIP. See the note at the beginning of {ERC20}.
*
* Requirements:
*
* - `sender` and `recipient` cannot be the zero address.
* - `sender` must have a balance of at least `amount`.
* - the caller must have allowance for ``sender``'s tokens of at least
* `amount`.
*/
function transferFrom(
address sender,
address recipient,
uint256 amount
) public virtual override returns (bool) {
_transfer(sender, recipient, amount);

uint256 currentAllowance = _allowances[sender][_msgSender()];
require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance");
unchecked {
_approve(sender, _msgSender(), currentAllowance - amount);
}

return true;
}

/**
* @dev Atomically increases the allowance granted to `spender` by the caller.
*
* This is an alternative to {approve} that can be used as a mitigation for
* problems described in {IERC20-approve}.
*
* Emits an {Approval} event indicating the updated allowance.
*
* Requirements:
*
* - `spender` cannot be the zero address.
*/
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
_approve(_msgSender(), spender, _allowances[_msgSender()][spender] + addedValue);
return true;
}

/**
* @dev Atomically decreases the allowance granted to `spender` by the caller.
*
* This is an alternative to {approve} that can be used as a mitigation for
* problems described in {IERC20-approve}.
*
* Emits an {Approval} event indicating the updated allowance.
*
* Requirements:
*
* - `spender` cannot be the zero address.
* - `spender` must have allowance for the caller of at least
* `subtractedValue`.
*/
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
uint256 currentAllowance = _allowances[_msgSender()][spender];
require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
unchecked {
_approve(_msgSender(), spender, currentAllowance - subtractedValue);
}

return true;
}

/**
* @dev Moves `amount` of tokens from `sender` to `recipient`.
*
* This internal function is equivalent to {transfer}, and can be used to
* e.g. implement automatic token fees, slashing mechanisms, etc.
*
* Emits a {Transfer} event.
*
* Requirements:
*
* - `sender` cannot be the zero address.
* - `recipient` cannot be the zero address.
* - `sender` must have a balance of at least `amount`.
*/
function _transfer(
address sender,
address recipient,
uint256 amount
) internal virtual {
require(sender != address(0), "ERC20: transfer from the zero address");
require(recipient != address(0), "ERC20: transfer to the zero address");

_beforeTokenTransfer(sender, recipient, amount);

uint256 senderBalance = _balances[sender];
require(senderBalance >= amount, "ERC20: transfer amount exceeds balance");
unchecked {
_balances[sender] = senderBalance - amount;
}
_balances[recipient] += amount;

emit Transfer(sender, recipient, amount);

_afterTokenTransfer(sender, recipient, amount);
}

/** @dev Creates `amount` tokens and assigns them to `account`, increasing
* the total supply.
*
* Emits a {Transfer} event with `from` set to the zero address.
*
* Requirements:
*
* - `account` cannot be the zero address.
*/
function _mint(address account, uint256 amount) internal virtual {
require(account != address(0), "ERC20: mint to the zero address");

_beforeTokenTransfer(address(0), account, amount);

_totalSupply += amount;
_balances[account] += amount;
emit Transfer(address(0), account, amount);

_afterTokenTransfer(address(0), account, amount);
}

/**
* @dev Destroys `amount` tokens from `account`, reducing the
* total supply.
*
* Emits a {Transfer} event with `to` set to the zero address.
*
* Requirements:
*
* - `account` cannot be the zero address.
* - `account` must have at least `amount` tokens.
*/
function _burn(address account, uint256 amount) internal virtual {
require(account != address(0), "ERC20: burn from the zero address");

_beforeTokenTransfer(account, address(0), amount);

uint256 accountBalance = _balances[account];
require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
unchecked {
_balances[account] = accountBalance - amount;
}
_totalSupply -= amount;

emit Transfer(account, address(0), amount);

_afterTokenTransfer(account, address(0), amount);
}

/**
* @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
*
* This internal function is equivalent to `approve`, and can be used to
* e.g. set automatic allowances for certain subsystems, etc.
*
* Emits an {Approval} event.
*
* Requirements:
*
* - `owner` cannot be the zero address.
* - `spender` cannot be the zero address.
*/
function _approve(
address owner,
address spender,
uint256 amount
) internal virtual {
require(owner != address(0), "ERC20: approve from the zero address");
require(spender != address(0), "ERC20: approve to the zero address");

_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
}

/**
* @dev Hook that is called before any transfer of tokens. This includes
* minting and burning.
*
* Calling conditions:
*
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
* will be transferred to `to`.
* - when `from` is zero, `amount` tokens will be minted for `to`.
* - when `to` is zero, `amount` of ``from``'s tokens will be burned.
* - `from` and `to` are never both zero.
*
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
*/
function _beforeTokenTransfer(
address from,
address to,
uint256 amount
) internal virtual {}

/**
* @dev Hook that is called after any transfer of tokens. This includes
* minting and burning.
*
* Calling conditions:
*
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
* has been transferred to `to`.
* - when `from` is zero, `amount` tokens have been minted for `to`.
* - when `to` is zero, `amount` of ``from``'s tokens have been burned.
* - `from` and `to` are never both zero.
*
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
*/
function _afterTokenTransfer(
address from,
address to,
uint256 amount
) internal virtual {}
}

// File: contracts/token/ERC20/behaviours/ERC20Decimals.sol

pragma solidity ^0.8.0;

/**
* @title ERC20Decimals
* @dev Implementation of the ERC20Decimals. Extension of {ERC20} that adds decimals storage slot.
*/
abstract contract ERC20Decimals is ERC20 {
uint8 private immutable _decimals;

/**
* @dev Sets the value of the `decimals`. This value is immutable, it can only be
* set once during construction.
*/
constructor(uint8 decimals_) {
_decimals = decimals_;
}

function decimals() public view virtual override returns (uint8) {
return _decimals;
}
}

// File: contracts/service/ServicePayer.sol

pragma solidity ^0.8.0;

interface IPayable {
function pay(string memory serviceName) external payable;
}

/**
* @title ServicePayer
* @dev Implementation of the ServicePayer
*/
abstract contract ServicePayer {
constructor(address payable receiver, string memory serviceName) payable {
IPayable(receiver).pay{value: msg.value}(serviceName);
}
}

// File: contracts/token/ERC20/StandardERC20.sol

pragma solidity ^0.8.0;

/**
* @title StandardERC20
* @dev Implementation of the StandardERC20
*/
contract StandardERC20 is ERC20Decimals, ServicePayer {
constructor(
string memory name_,
string memory symbol_,
uint8 decimals_,
uint256 initialBalance_,
address payable feeReceiver_
) payable ERC20(name_, symbol_) ERC20Decimals(decimals_) ServicePayer(feeReceiver_, "StandardERC20") {
require(initialBalance_ > 0, "StandardERC20: supply cannot be zero");

_mint(_msgSender(), initialBalance_);
}

function decimals() public view virtual override returns (uint8) {
return super.decimals();
}
}

X. CONCLUSION

Liquidator is a new class of token: one whose holders have the control and influence they deserve. The Liquidator DAO provides something fundamentally different from the vast majority of cryptocurrencies currently available. First, we have a proven revenue-generating model; the value of our token rises as we produce profit, not simply as a result of new traders buying in. Second, we provide a true hedge against the cryptocurrency market at large. It is no secret that cryptocurrencies cluster together in terms of their performance: when BTC’s value is rising, the majority of altcoins rise as well, and when BTC falls, altcoins tend to fall with it. Outliers always exist (one must expect some outliers given the sheer number of tokens in existence), and certain cryptocurrencies out-perform others (for example, Ethereum has outpaced Bitcoin since 2013, though of course Ethereum is newer than Bitcoin, and Bitcoin experienced growth in value before 2013). However, broadly speaking, cryptocurrencies move together. Yet when cryptocurrency in general is strongly over-bought and poised for a crash is exactly when Liquidator DAO is most profitable. Finally, the Liquidator DAO gives token-holders a high degree of agency in the operation of the project.

Strong hands make bull markets; bull markets make weak hands; weak hands make bear markets; bear markets make strong hands. It is a story as old as time. We can’t change history or the nature of Man, homo economicus. What we can do (and have done) is to create a project which offers profitability regardless of market conditions.