Key Risk Indicator (KRI) Feed
Last updated
Last updated
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.\
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:
block_base_fee
block_priority_fee
block_size
time_inter_block
time_since_last_block
block_count_at_tip
block_count_by_same_miner_6b
block_count_by_unknown_miners_6b
block_count_without_segwit
block_count_consecutive_empty
block_count_empty_6b
block_missed_slots
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
mempool_fee
mempool_fee_entered_1m
mempool_fee_mean
mempool_fee_mean_entered_1m
mempool_fee_median
block_hashrate_mean_1d
mempool_output_value
mempool_output_value_entered_1m
mining_reward_mean
mining_reward_spread
block_feerate_max
block_feerate_mean
block_feerate_median
block_feerate_min
block_fee_max
block_fee_mean
block_fee_median
block_fee_min
block_fees
mempool_size
mempool_size_entered_1m
mempool_size_left_1m
mempool_vsize
mempool_vsize_entered_1m
mempool_vsize_left_1m
block_tx_count
mempool_count
mempool_count_entered_1m