Granular Insights On Chain Using Hourly Network Data Metrics
Resources
This notebook demonstrates basic functionality offered by the Coin Metrics Python API Client and Network Data Pro.
Coin Metrics offers a vast assortment of data for hundreds of cryptoassets. The Python API Client allows for easy access to this data using Python without needing to create your own wrappers using requests and other such libraries.
To understand the data that Coin Metrics offers, feel free to peruse the resources below.
The Coin Metrics API v4 website contains the full set of endpoints and data offered by Coin Metrics.
Download the entire notebook as either a jupyter notebook to run yourself or as a pdf from the two links below
Notebook Setup
from os import environ
import pandas as pd
import numpy as np
import seaborn as sns
import logging
from datetime import date, datetime, timedelta
from coinmetrics.api_client import CoinMetricsClient
import logging
import matplotlib.pyplot as plt
import matplotlib
from matplotlib.ticker import FuncFormatter
import warnings
%matplotlib inline
# We recommend privately storing your API key in your local environment.
try:
api_key = environ["CM_API_KEY"]
logging.info("Using API key found in environment")
except KeyError:
api_key = ""
logging.info("API key not found. Using community client")
client = CoinMetricsClient(api_key)
2024-10-04 11:52:04 INFO Using API key found in environment
Hourly Metrics
Coin Metrics is pleased to announce the release of a new set of hourly metrics for Network Data Pro. This feature unlocks a new level granularity for our existing suite of on-chain metrics.
Previously, our Network Data Pro offering provided both Daily (EOD) and Block-by-Block (BBB) aggregations of on-chain metrics. Now, users have the ability to capture on-chain activity at an intermediate frequency, providing timely insights into metrics like Active Address Count, Transaction Fees, and more.
Retrieve Hourly Metrics Catalog
asset_metrics_reference = client.reference_data_asset_metrics(page_size=10000).to_dataframe()
list_metrics_nd = list(asset_metrics_reference.loc[asset_metrics_reference['product']=='Network Data', 'metric'])
asset_metrics_catalog = client.catalog_asset_metrics_v2(
assets='eth',
metrics=list_metrics_nd,
page_size=10000
).to_list()
list_hourly_metrics_nd = []
for asset in asset_metrics_catalog:
for metric in asset['metrics']:
if 'frequencies' in metric.keys():
for frequency in metric.get('frequencies'):
if '1h' in frequency.values():
list_hourly_metrics_nd.append(metric['metric'])
# # alternatively, use this dataframe. note this is only doable starting coinmetrics-api-client version 2024.10.4.15
# asset_metrics_catalog = client.catalog_asset_metrics_v2(page_size=10000).to_dataframe()
# list_hourly_metrics_nd = list(asset_metrics_catalog.loc[asset_metrics_catalog.frequency=='1h', 'metric'].unique())
First, we'll examine the relationship between Ethereum's transaction count (TxCnt) and the amount of ETH being "burned," or removed from circulation (SplyBurntNtv).
Since the introduction of EIP-1559, Ethereum has segmented gas fees into two separate fees: the "base fee" and the "priority tip." While the priority tip is rewarded to validators, the base fee is burnt. Over the long-term, this has enabled ETH to offer a deflationary monetary policy, with periods of high transaction activity permanently destroying units of ETH and lowering the total circulating supply.
# Function to format y-axis tick labels
def thousands(x, pos):
'The two args are the value and tick position'
return '%1.0fK' % (x * 1e-3)
fig, (ax1, ax2) = plt.subplots(2, 1, sharex=True, figsize=(14,8))
ax1.set_title('\nETH Transaction Count \nand Supply Burnt (1H)\n', color='black', fontsize=16) # Change title color to white for visibility
# Plot TxCnt as a line plot
ax1.plot(fee_burn_and_tx_metrics.index, fee_burn_and_tx_metrics['TxCnt'], color='lime')
ax1.set_facecolor('#212530')
ax1.set_ylabel('Transaction Count', color='black')
ax1.tick_params(length=0, axis='y', labelcolor='black')
ax1.tick_params(length=0, axis='x', labelcolor='black')
ax1.yaxis.set_major_formatter(FuncFormatter(thousands))
ax1.grid(axis='y',linestyle='--', color='gray') # Change gridline color to white for visibility
cmap = matplotlib.cm.Reds(np.linspace(0.5,0.75,20))
cmap = matplotlib.colors.ListedColormap(cmap[::-1, :-1])
# Plot SplyBurntUSD as a scatter plot with the colormap
sc = ax2.scatter(fee_burn_and_tx_metrics.index, fee_burn_and_tx_metrics['SplyBurntNtv'], c=fee_burn_and_tx_metrics['SplyBurntNtv'], cmap=cmap)
ax2.set_facecolor('#212530')
ax2.set_xlabel('')
ax2.set_ylabel('Supply Burnt (ETH)', color='black') # Change label color to white for visibility
ax2.tick_params(length=0,axis='y', labelcolor='black') # Change tick color to white for visibility
ax2.grid(axis='y',linestyle='--', color='gray') # Change gridline color to white for visibility
ax2.set_ylim(fee_burn_and_tx_metrics['SplyBurntNtv'].min()*1.05,0)
fig.tight_layout()
plt.show()
BTC Block Interval vs. Mean Fee
In contrast to Etheruem's predictable 12-second block time, Bitcoin's block interval is based on probabilistic factors— there's no way of knowing for sure when the next block will come in.
The blockchain's difficulty adjustment software targets an average block interval of 10 minutes, but blocks can occasionally take an hour or more to be mined, resulting in brief periods of transaction congestion. This congestion can result in spikes in transaction fees, as a busy backlog of BTC users bid up fees in order to ensure their inclusion in the next block.
In the following analysis, we examine how Bitcoin's median transaction fee (FeeMedUSD) responds to prolonged block intervals (BlkIntMean).
