₿itcoin Sustainability: Visual Analysis

Consumers are increasingly demanding that the financial services they use reflect their values. Many industries have been quick to respond. A glance at any major financial services provider's website reveals extensive information about their environmental, social, and governance (ESG) goals [1].

Traditional finance's mysterious cousin, decentralised finance (DeFi), has been criticised for being less responsible in terms of ESG. DeFi's claim to fame is its ability to support a robust financial ecosystem without centralised control. However, this decentralisation comes at a cost. The technology enabling DeFi assets, known as blockchain, can be computationally intense. Think of it like running a global spreadsheet of every transaction that requires constant upkeep from thousands of computers, it’s no small feat.

The most well-known DeFi asset, Bitcoin, consumes a significant amount of energy. To put it in perspective, the energy used by Bitcoin rivals that of small countries [2]. This raises questions about its long-term sustainability.

The goal of this project is to visually explore the dynamics of Bitcoin's sustainability measured by its electricity consumption.

• Key questions:
• What are the current sustainability trends?
• What is the relationship between Bitcoin's market fundamentals, technological features, and sustainability?
• Are these relationships useful for predicting future electricity consumption?

The analysis combines data from two sources. Market and technical fundamentals were sourced from Coin Metrics [3]. Energy consumption data was collected from the Cambridge Bitcoin Electricity Consumption Index (CBECI), hosted by the Cambridge Centre for Alternative Finance (CCAF) [4]. The index offers a live estimate of Bitcoin's electricity consumption. This data was downloaded manually and is hosted on my GitHub. Both data sources provided comprehensive sets of daily observations.

Unfortunately, the automated aspect of this project is limited. The first limitation is that CCAF does not offer an API. The CCAF data can be requested at any time, although there can be delays in receiving a response. In the future I would like to construct a workaround. Potentially, a python scraping script could capture the most recent values. The second limitation is financial. Most comprehensive Bitcoin APIs are paid, while free ones tend to be limited. Once purchased. Automation simply requires an edit to the Vega-lite specification to pull data from the API instead of the csv hosted on my GitHub repository.

• The Vega-lite specifications can be accessed via the embedded charts.
• Click here if you would like to access the data used.
• Definitions

The primary challenge to analysis was the model selection process for the machine learning component. The machine learning model initially had a critical flaw: using randomized data samples meant future data was being used to predict past events, creating artificially high accuracy. After some research, I switched to temporal windows, using only historical data to predict future values. This time-based approach produced more realistic predictions compared to the original random sampling method.

The analysis in the non-ML charts came rather easily. The biggest challenge was getting the parameter sliders to work on multiple plots for the dashboard. Through iteration and consulting with Claude LLM, I developed a solution. I believe the effort was worth it because this trellis-like set up offers a much more comprehensive view of the data than a single plot would.