Key Risk Indicator (KRI) Feed

A Background on Network Risk

Bitcoin is the first successful implementation of a blockchain with its own native cryptocurrency. It solved a fundamental problem in computer science abstractly expressed by Lamport, Shostak, and Pease in 1982 as the Byzantine Generals Problem, or BGP. The crux of this problem is that, in networks where participants do not trust each other, it is hard to discern statements that are true from those that are false. If enough network participants are malicious or are acting erratically, it becomes impossible for honest participants to converge on what is true. It took decades for this problem to be effectively solved in an open network with the advent of Bitcoin’s Nakamoto Consensus. Beyond providing a solution to the BGP, Bitcoin effectively gave birth to an entire industry as it demonstrated a novel way to issue and settle assets.\

A fundamental property of Nakamoto Consensus that was key in solving the BGP is the ability for the ordering of blocks in the blockchain to be changed if certain conditions are met. The most common of such events are Chain Reorganizations, or “reorgs”. When reorgs occur, transactions may be removed from the blockchain. Previously valid blocks are removed and transactions are sent back to the memory pool or the mempool, the space within a blockchain node where unprocessed transactions are temporarily stored. A drawback of this system is that if fee conditions in the network change by the time such transactions return to the mempool, their final settlement might be impeded without additional action by users. Cryptoasset exchanges have historically been impacted by this in times of network fee volatility, especially during the 2017 bull market.\

The very same property also makes it possible for network attacks, such as so-called “51% attacks,” in which an attacker attains enough mining power to trigger reorgs for personal gain. The feasibility of these attacks depends on the number of honest miners securing a network: while these attacks have never been successfully performed on a large network like Bitcoin, smaller networks such as Bitcoin Gold, Vertcoin, and Ethereum Classic have been targeted. In most cases, cryptoasset exchanges are the main targets of these attacks. By simply reverting exchange deposits, attackers have been able to net millions of dollars worth of cryptoassets. Unfortunately, just like naturally occurring reorgs, market participants such as exchanges have few resources to manage such risks and assess the likelihood of their transactions being affected.\

FARUM solves this problem by tracking the full spectrum of possible risks by making use of both conventional and unconventional data sources. Raw data on blockchain transactions across all supported networks is formatted in accordance with Coin Metric’s Universal Blockchain Data Model (UBDM), which is provisioned via the Atlas API. In order to also provide alerts on unprocessed transactions, FARUM employs Coin Metric’s Mempool Collector, a low-latency mempool querying engine built from the ground up to maximize performance. These sources provide a complete view of both processed and unprocessed transactions from which network risk can be managed and alerts can be created.\

Data Sources Supporting FARUM

Given the wide spectrum of risk vectors that must be covered, FARUM looks beyond transactional data flowing through a cryptoasset’s peer-to-peer network. Since observing mining pool protocols can provide a view on future blocks, additional data sources include the Mining Pool Collector, which connects to several mining pools via the Stratum protocol to obtain information about blocks being mined and/or impending network attacks. In order to evaluate potential attack vectors and/or ongoing attacks, FARUM employs many other collectors that will be described in this document.

See:

• Network Risk Overview

Block Attributes

• block_base_fee

• block_priority_fee

Block Size

• block_size

Block Times

• time_inter_block

• time_since_last_block

Blocks

• block_count_at_tip

• block_count_by_same_miner_6b

• block_count_by_unknown_miners_6b

• block_count_without_segwit

Empty Blocks

• block_count_consecutive_empty

• block_count_empty_6b

• block_missed_slots

Feerates

• mempool_feerate_mean

• mempool_feerate_median

• mempool_next_block_approx_feerate_max

• mempool_next_block_approx_feerate_mean

• mempool_next_block_approx_feerate_median

• mempool_next_block_approx_feerate_min

• mempool_next_block_inclusion_approx_feerate_min

Fees

• mempool_fee

• mempool_fee_entered_1m

• mempool_fee_mean

• mempool_fee_mean_entered_1m

• mempool_fee_median

Hashrate

• block_hashrate_mean_1d

Outputs

• mempool_output_value

• mempool_output_value_entered_1m

Rewards

• mining_reward_mean

• mining_reward_spread

Transaction Feerates

• block_feerate_max

• block_feerate_mean

• block_feerate_median

• block_feerate_min

Transaction Fees

• block_fee_max

• block_fee_mean

• block_fee_median

• block_fee_min

• block_fees

Transaction Sizes

• mempool_size

• mempool_size_entered_1m

• mempool_size_left_1m

• mempool_vsize

• mempool_vsize_entered_1m

• mempool_vsize_left_1m

Transactions

• block_tx_count

• mempool_count

• mempool_count_entered_1m