Harnessing the Power of
Deep Learning

1: Introduction to AI Research at Liquidator DAO

The Liquidator DAO team is creating innovative tools for cryptocurrency price prediction. In particular, we are applying neural networks to a best-in-class library of on-chain and off-chain metrics, determining how these metrics portend changes in market price. On-chain metrics include active addresses, address balance distributions, miner income, mining difficulty, and similar. Off-chain metrics are largely related to the activity of exchanges and markets, such as open interest, liquidations, prices for call and put options, etc.

To this end, we source data from Glassnode (at a hefty price), pre-process it in Python, and train neural networks using the TensorFlow library. In particular, we are examining changes in Glassnode-derived metrics over time, with the goal of modeling price movements on timescales ranging from days to weeks.

We are acutely aware that AI has become a “buzzword” in cryptocurrency space. For example, numerous websites and sketchy Telegram personalities promote “AI-powered” trading bots, for use on Binance and other exchanges. Aside from technical risks (such as password theft), such “AI” bots do not perform consistently well, and their operation is opaque. When money is involved, opacity is dangerous because it can conceal fraud and incompetence.


In truth, this problem is not limited to the crypto-sphere; it is present in most fields related to information technology. From logistics to marketing, salesmen are fond of promising customers that some proprietary “AI algorithm” will solve all of a customer’s problems. This “AI” algorithm is never revealed (even to a customer who pays to use it), and if this “AI” performs poorly at its task, the salesmen will insist that the problem lies elsewhere: surely the algorithm produced by the salesman’s company is not to blame – rather, the customer has failed to provide the proper data.

If the AI is performing well, then the salesman will smile and encourage further adoption.

If the AI is performing poorly, then the salesman will strike a thoughtful pose and patiently explain that the customer should double down on AI implementation – after all, artificially intelligent systems can “learn”, and the more data they have, the better. In any case, the salesman is certain that the AI simply needs time to optimize – “let it run for another month”, he will suggest, and when its performance is no better when a month has passed, he will insist that it needs another quarter to optimize, and then another year, and so-on.

No matter the situation, the salesman knows the solution: The best response to good AI is more AI, and the best response to bad AI is also more AI. Under no circumstances will the salesman entertain the thought that his company’s AI is less than enlightened; under no circumstances will his company ever expose the code so that errors can be found and corrected; under no circumstances will he admit that perhaps the AI has been designed to maximize the profits of his company, rather than the customer’s company. One of our DAO members recalls an incident in which a salesman from the marketing company AdRoll gave the typical artificial-intelligence spiel, but with a comical twist: this salesman (who knew nothing of computing or mathematics) used the word “logarithm” when he meant to say “algorithm”, as in “AdRoll’s proprietary logarithm will optimize your online advertising”, etc.


At Liquidator DAO, we’re doing things differently.

To the greatest extent compatible with bona fide business interests, we are making our AI development public. In particular, we have released datasets from Glassnode that we employ to train our neural network, as well as technical details of our approach.

We can’t expose everything (particularly, we will not be circulating copies of the final neural network outside the DAO itself). However, in the spirit of data science, we are open-sourcing our strategy, process, and source data. We believe:

1. The more eyes on our work, the better.

2. Vigorous debate about the technicalities of our approach will help us pursue the most promising paths.

3. Contributing to the cryptocurrency space at large will help the Liquidator project grow and attract participants.

2: Goals & Executive Decisions

The surest path to failure is to attempt to be everything to everyone. This is why America is such a mess, and why Elden Ring is so excellent: at Liquidator DAO, we aspire to do a few things, and to do them well. The following are certain executive decisions and goals of our AI development:

A. Belief in the Predictability of Cryptocurrency Markets: We assert that markets in general (and cryptocurrency markets in particular) are at least partially predictable based upon past data. Indeed, past data is all that we can look at: data from the future, sadly, is hard to come by. This does not mean that we expect our predictions to be perfect, exact, or infallible, but merely that, through careful study of hundreds of metrics relating to top cryptocurrencies, we expect to make predictions which are better than we might obtain by flipping (physical) coins. We reject arrogance, but we also reject the philosophy of predictive nihilism: that is, we disagree with absolutist interpretations of the efficient-market hypothesis.

This hypothesis, in its strongest form, posits that markets are fundamentally and irreducibly unpredictable. An efficient-market absolutist does not merely believe that the Liquidator DAO will fail in attempting to predict cryptocurrency prices, nor does he merely believe that the task before us is difficult, complicated, or unfeasible: he believes it is truly impossible. To an efficient-market absolutist, no amount of data, computation power, or human intelligence is sufficient: even with perfect knowledge of the market in question, including insight into the thoughts of every trader, the financials of every company; even with perfect models of the brains and bodies of all humans at nanosecond prediction, he would be certain of our failure. To such a predictive nihilist, attempting to anticipate price movement is as absurd as attempting to manufacture a perpetual-motion machine or to travel at superluminal speeds: success is prohibited by physical laws.

We reject this defeatism. We believe that price prediction is ultimately an engineering challenge like any other: difficult, but not insurmountable. We further believe that an imperfect tool is better than no tool at all.

B. Focus on Blue-Chip Cryptocurrencies: The Liquidator DAO is concentrating its work on price prediction for Bitcoin (BTC) and Ethereum (ETH). We are potentially open to expanding into price prediction for major ERC-20 tokens, but this is a secondary project, and we have no intent to develop models for tokens on Binance SmartChain or other non-Ethereum virtual machines. If you are frustrated that we are not studying your favorite niche token, that’s too damn bad. We have reached this decision for several reasons:

First, we believe that the (numerical) majority of cryptocurrencies will fail and have little future. This is because human civilization does not, in our thinking, “need” very many cryptocurrencies, and because network effects in a competitive market typically result in a few big winners and many losers destined for obscurity and oblivion. We agree that some of the diversity in cryptocurrencies is legitimately useful. The world needs a store-of-value cryptocurrency which is truly decentralized via proof-of-work mining (such as BTC). The world needs a smart-contract, VM-supporting cryptocurrency (such as ETH). The world needs a good oracle chain (ex. ChainLink). The world needs a high-privacy cryptocurrency (for example, Monero – though XMR is really what BTC should have been, in hindsight). Perhaps the world even needs a few memecoins, a few “reflectionary” coins, a few settlement layers, and a few “environmentally friendly” proof-of-stake coins, though this is less certain. Hence, the number of cryptocurrencies truly “needed” in a free market is perhaps on the order of ten, or even on the order of one hundred, but it’s certainly not tens of thousands. As of this writing, there are just shy of 70,000 flavors of ERC-20 tokens alone. Binance SmartChain, with lower network fees than Ethereum, has roughly 200,000 unique token types. Further tokens are spread across thousands of smaller blockchains, most of which have one or more native cryptocurrencies. If we consider NFTs, each of which behaves somewhat like a unique, indivisible cryptocurrency with a supply of exactly 1 token, the total number of unique cryptographic assets is on the order of tens of millions. Model development is time-, labor-, and resource-intensive, and we want to focus on cryptocurrencies that we believe, in good faith and with high certainty, will be around for years to come.

Second, we believe that major cryptocurrencies, typically those with undiluted market capitalizations of at least $100B (2022 inflation-adjusted US dollars), are more resistant to the effects of events which cannot be predicted by our models. For example, Liquidator DAO’s deep-learning systems aren’t designed to anticipate when a token will be listed on an exchange (or blacklisted), or when some positive news (a desirable partnership) or negative news (a concerning legal case) unfolds. Small-capitalization cryptocurrencies typically have smaller communities prone to both irrational panic and irrational exuberance. If our approach to AI centered around sentiment analysis, we might focus on these currencies, but our approach is more quantitative, and so we are focusing on currencies where we believe quantitative factors are most important to price.

Third, smaller cryptocurrencies are usually more centralized that BTC or ETH. In extreme cases, a single anonymous developer may be able to mint and/or burn tokens at any time and for any reason. Tokens with unclear, overly-complex, or volatile tokenomics (ex. variable transaction “taxes”) are clearly a concern because sudden changes in the “ground rules” of functionality will invalidate our models. As Liquidator DAO grows and developers become more aware of our project, there is also the risk that token developers with excessive privileges over their currencies could alter tokenomics with the explicit goal of wrecking Liquidator DAO’s futures positions. For this reason, we would never develop an AI model for SafeMoon or the many similar tokens coins it has “inspired”.

Fourth and finally, blue-chip cryptocurrencies have generally been around for long periods of time and typically have the best-quality metrics available. In our AI approach, each interval of time (such as a day) represents a unit of training data, and a decade-old cryptocurrency will therefore have ten times as many data points available as a year-old currency. Beyond these chronological considerations (which relate to the quantity of data), there are considerations as to quality: Little data on derivatives, futures liquidations, funding rates, supply in profit/loss, etc. is available for minor tokens. We can easily pull data to determine exactly how many dollars of liquidations occurred against Ethereum short-holders on Binance on Thursday, October 8th, 2020, between 11:30 and 11:40 AM London time. We can’t get anywhere near this level of resolution for smaller cryptographic assets. To some degree, high-anonymity tokens using zk-SNARKs or ring signatures (Monero/XMR, ZCash, Dero, etc.) present similar challenges because their protocols are intentionally opaque, and we are actively researching ways to build models for these.

C. Focus on Day-to-Month Time Intervals: When predicting prices and executing trades, our time horizons will range from one day to several months. In particular, we do not intend to train neural networks with the goal of trading multiple times per hour, per minute, or per second. The Liquidator DAO’s goal is to beat other market participants by trading smarter, not by trading faster. Hence, our AI approach is not a form of HFT (High-Frequency Trading) in the conventional sense. Some reasons for this relate to practicality: gathering data, processing it, and feeding it into a model all take time, as does implementing the proposed trade. The need to trade on very short timescales would severely limit the sophistication of models we could develop. Further, not all APIs for input data offer timescales under 24 hours, and noise increases at shorter intervals. Other reasons are inherent to the nature of the blockchains that support major cryptocurrencies. Given that on-chain metrics are a major component in our model, attempting to trade on a timescale shorter than average block time (for BTC: ten minutes) would be counterproductive, since incoming data can never be “fresher” than the preceding block. Variation in block times, and the imperative to wait for several confirmations (and hence several multiples of the block-time) before accepting a block, expand the time horizon further. Finally, we believe that price movements on very short timescales are more likely to be influenced by non-quantitative factors (ex. Elon Musk’s Twitter feed), and would therefore be outside the scope of our model. We wish to trade on the timescale that is the most predictable.

D. Change Predicts Change: On a more technical note, developers of deep-learning models face questions regarding preprocessing the data they feed into their neural networks. In essence, a neural network develops a model which should ideally take some input data (in our case, historical on- and off-chain data about cryptocurrencies) and emit an accurate output (in our case, a near-future price prediction). There are, however, nuances about how this data is presented.

In terms of output, we could demand that our model predicts a specific output price – for example, a prediction that, in 24 hours, the price of BTC will be $64,350.28. Alternatively, we could demand that it predicts price change, in the form of a price multiplier. Multipliers greater than 1 would indicate anticipated growth, multipliers less than 1 would indicate a prediction of price decline, and a multiplier of exactly 1 would suggest a stable price. For example, a multiplier of 1.02 would indicate a 2% anticipated price increase, whereas 0.96 would indicate a 4% price drop, and so-forth. We have chosen to develop our model to output multipliers rather than exact prices for several reasons. First, in terms of a decision to open a short (or a long), the polarity of expected change is more important than the exact magnitude of that change. To be sure, the magnitude is useful as well, and there would be nothing better than knowing–with good certainty–the precise price of some digital asset on a particular future date. However, directionality is more important overall than magnitude, and so we want to train our model with directionality as a primary endpoint. Second, any model which is asked to predict future prices in dollar (or other-fiat) terms will necessarily lean heavily on recent actual prices. If you were asked to predict the dollar-price of BTC tomorrow, the single most important datapoint in your analysis would likely be BTC’s price today. If BTC is worth $50,000 today, then it’s very likely to be worth about $50,000 tomorrow; certainly it’s unlikely to have a value of $5,000 or $500,000. No metric besides recent price would be nearly as significant, because enough money is invested in blue-chip cryptocurrencies nowadays that they have significant financial “inertia”, i.e., very large sums of money must be moved into or out of them in order to shift their market prices. Designing our model to predict multipliers, therefore, will prevent the neural networks we train from fixating excessively on recent price and ignoring other metrics: the price of BTC today tells us a great deal about what the price will be tomorrow, but little about whether tomorrow’s price will be higher or lower than today’s.

In terms of input, we face a similar choice: do we “tell” our model the specific values of predictive metrics at given times in the past (1, 2, 3, 4, 5, 10, 20, 30…days ago), or do we tell it how much those same metrics have changed in the past however-many days? Here, we have also decided to focus on change. For example, we believe that the statement “exchange balances have decreased by 20% over the past 30 days” is more informative than the statement “exchange balances were $247M 30 days ago”. It is the decrease in on-exchange balances (more than the balances themselves) that indicates increasing scarcity and is predictive of an increase in price.

For these reasons, we describe our approach as “change predicts change”: We feed temporal changes in metrics into our model, with the goal of getting an accurate prediction of near-future price change out.

E. Fiat Units Over Native Units: One category of cryptocurrency-related metrics can be pulled in both “native” units (which vary according to the metric) and “fiat” units (here, we use USD). For example, Ethereum transaction volume can be pulled in either fiat units (USD transacted on a certain day) or in “native” units (ETH transacted on a certain day). The same can be said for UniSwap liquidity, which may be expressed in either USD or ETH terms.

A second category of metrics can only be pulled in native units, primarily in cases where the native unit does not correspond to units of a cryptocurrency. For example, the total number of transactions can only be pulled in native units (those native units being transaction count), and similarly, funding rates in futures exchanges can only be expressed in percentages, which are native units for that metric.

A third category of metrics can only reasonably be pulled in fiat units. Technically speaking, any metric that can be pulled in fiat units can also be pulled in native units, because any dollar amount can also be expressed in terms of ETH, BTC, or other cryptocurrency as long as we know the date associated with the metric and can look up the exchange rate prevailing on that day in order to perform the necessary conversion. However, there are some cases where it makes little sense to pull a metric in native units. For example, the native unit of BTC price is itself BTC, and pulling BTC price in native units will therefore always produce the same value: 1 (one BTC = one BTC).

Our approach here is simple: if a metric can only be pulled in native units (category #2), we of course pull it in native units. If it can potentially be pulled in fiat units (categories #1 and #3), we will pull it in fiat units, specifically USD. We believe this is the optimal approach as USD price movement is, ultimately, what we want to predict. However, we will be providing data pulled in native units (where possible) as well, as a matter of public interest, even though we don’t feed this data into our models.

3A: Data – Raw, Chronological, Fiat-Favored

These files represent the results of the first step in data-gathering. They include “raw” data (i.e., no preprocessing has occurred). Data is shown chronologically, such that the far-left column used as an index corresponds to the calendar date matching each row of cells. Dates are expressed in ISO format, [YYYY-MM-DD]. Note that Microsoft Excel will automatically convert these dates to the default format set for your operating system upon opening the file. The data here is “fiat-favored”, meaning that we have pulled financial metrics in USD whenever it is possible and reasonable to do so. For example, we pull daily trading volume in terms of dollars transacted, not BTC or ETH transacted. Details about the meanings and units of all metrics can be found in the GlassNode API Documentation GitBook, under the “API Endpoints” section and its subsections. Blank cells indicate that no data is available.

3B: Data – Raw, Chronological, Native-Favored

These files contain identical data to those in set 3A, except here all metrics were pulled in “native” units (BTC or ETH) instead of “fiat” units (USD), where possible. These files are provided as a public service and are not used directly by Liquidator’s Deep Learning system, as we favor fiat-based metrics. In many cases, columns are redundant between 3A-set and 3B-set files, given that certain metrics can only be pulled in native or in fiat units.

4A: Data – Patched, Chronological, Fiat-Favored

In the second step, we begin preprocessing our chronological data by “patching” the blank cells in our tables. Note that, although these cells simply appear as empty when a CSV is opened, they are treated as instances of ‘NaN’ (‘Not a Number’) in database applications and by the PANDAS Python library. Ultimately, we do not want to feed blank cells into our deep-learning algorithm, as the presence of any blank in a row of data (one row corresponding to one day) will effectively invalidate that entire row and prevent us from using it for training our neural network. At the same time, we need to ensure that whatever data we insert in the “patching” process does not “teach” our deep-learning model any spurious or false lessons. Finally, as we will be updating the trading data frequently, the “patching” method must be determinate in a mathematical sense: given the same inputs, it must give the same outputs, regardless of date range and regardless of whether the data we are preprocessing will be used for model training or will be used for making actual predictions.

The approach we use is linear regression with respect to price. That is, for each given metric with blank values corresponding to certain dates, we first collect a list of rows (indexed by dates) that do not have blank values. As we have price data for all days (that is, there are no gaps in price-as-a-metric), we can create a list of third-order tuples as:

{ISO Date; Price on Date; Metric Value on Date}

From these tuples, we wish to derive an equation which expresses metric value as a function of price, i.e. we want some equation of the form:

No single equation of reasonable complexity will be “perfect”, i.e. there is no best-fit function that will plot a line or curve perfectly through each of the points corresponding to our third-order tuples. However, we want a function that will achieve good agreement with the vast majority of tuples, and so we will derive our function by minimizing the square of the delta between the best-fit predicted value and actual value. We can then patch gaps in the data according to:

We have color-coded the equation to demonstrate that certain summations can be calculated once (in the derivation phase) but then used multiple times when actually patching. This is important for code optimization, because summation operations require iterating through the entire list of (asset price; metric value) pairs for each metric and are computationally expensive.

Certain metrics can only reasonably be positive. For example, the count of transactions-per-day for BTC, ETH, or any other cryptocurrency cannot be less than zero. Therefore, Liquidator’s patching function contains a feature to detect if any negative values are present in existing data. If none are present, then the equation above is adjusted to force all patch values to be positive or zero.

The following files are patched in the aforementioned method for fiat-expressed metrics:

4B: Data – Patched, Chronological, Native-Favored

This data is similarly patched, but favors metrics expressed in native (BTC or ETH) terms:

BLUE: #201cff