The primary expense that must be paid by a blockchain is that of security. The blockchain must pay miners or validators to economically participate in its consensus protocol, whether proof of work or proof of stake, and this inevitably incurs some cost. There are two ways to pay for this cost: inflation and transaction fees. Currently, Bitcoin and Ethereum, the two leading proof-of-work blockchains, both use high levels of inflation to pay for security; the Bitcoin community presently intends to decrease the inflation over time and eventually switch to a transaction-fee-only model. NXT, one of the larger proof-of-stake blockchains, pays for security entirely with transaction fees, and in fact has negative net inflation because some on-chain features require destroying NXT; the current supply is 0.1% lower than the original 1 billion. The question is, how much “defense spending” is required for a blockchain to be secure, and given a particular amount of spending required, which is the best way to get it?

Absolute size of PoW / PoS Rewards

To provide some empirical data for the next section, let us consider bitcoin as an example. Over the past few years, bitcoin transaction revenues have been in the range of 15-75 BTC per day, or about 0.35 BTC per block (or 1.4% of current mining rewards), and this has remained true throughout large changes in the level of adoption.

It is not difficult to see why this may be the case: increases in BTC adoption will increase the total sum of USD-denominated fees (whether through transaction volume increases or average fee increases or a combination of both) but also decrease the amount of BTC in a given quantity of USD, so it is entirely reasonable that, absent exogenous block size crises, changes in adoption that do not come with changes to underlying market structure will simply leave the BTC-denominanted total transaction fee levels largely unchanged.

In 25 years, bitcoin mining rewards are going to almost disappear; hence, the 0.35 BTC per block will be the only source of revenue. At today’s prices, this works out to ~$35000 per day or $10 million per year. We can estimate the cost of buying up enough mining power to take over the network given these conditions in several ways.

First, we can look at the network hashpower and the cost of consumer miners. The network currently has 1471723 TH/s of hashpower, the best available miners cost $100 per 1 TH/s, so buying enough of these miners to overwhelm the existing network will cost ~$147 million USD. If we take away mining rewards, revenues will decrease by a factor of 36, so the mining ecosystem will in the long term decrease by a factor of 36, so the cost becomes $4.08m USD. Note that this is if you are buying new miners; if you are willing to buy existing miners, then you need to only buy half the network, knocking the cost of what Tim Swanson calls a “Maginot line” attack all the way down to ~$2.04m USD.

However, professional mining farms are likely able to obtain miners at substantially cheaper than consumer costs. We can look at the available information on Bitfury’s $100 million data center, which is expected to consume 100 MW of electricity. The farm will contain a combination of 28nm and 16nm chips; the 16nm chips “achieve energy efficiency of 0.06 joules per gigahash”. Since we care about determining the cost for a new attacker, we will assume that an attacker replicating Bitfury’s feat will use 16nm chips exclusively. 100 MW at 0.06 joules per gigahash (physics reminder: 1 joule per GH = 1 watt per GH/sec) is 1.67 billion GH/s, or 1.67M TH/s. Hence, Bitfury was able to do $60 per TH/s, a statistic that would give a $2.45m cost of attacking “from outside” and a $1.22m cost from buying existing miners.

Hence, we have $1.2-4m as an approximate estimate for a “Maginot line attack” against a fee-only network. Cheaper attacks (eg. “renting” hardware) may cost 10-100 times less. If the bitcoin ecosystem increases in size, then this value will of course increase, but then the size of transactions conducted over the network will also increase and so the incentive to attack will also increase. Is this level of security enough in order to secure the blockchain against attacks? It is hard to tell; it is my own opinion that the risk is very high that this is insufficient and so it is dangerous for a blockchain protocol to commit itself to this level of security with no way of increasing it (note that Ethereum’s current proof of work carries no fundamental improvements to Bitcoin’s in this regard; this is why I personally have not been willing to commit to an ether supply cap at this point).

In a proof of stake context, security is likely to be substantially higher. To see why, note that the ratio between the computed cost of taking over the bitcoin network, and the annual mining revenue ($932 million at current BTC price levels), is extremely low: the capital costs are only worth about two months of revenue. In a proof of stake context, the cost of deposits should be equal to the infinite future discounted sum of the returns; that is, assuming a risk-adjusted discount rate of, say, 5%, the capital costs are worth 20 years of revenue. Note that if ASIC miners consumed no electricity and lasted forever, the equilibrium in proof of work would be the same (with the exception that proof of work would still be more “wasteful” than proof of stake in an economic sense, and recovery from successful attacks would be harder); however, because electricity and especially hardware depreciation do make up the great bulk of the costs of ASIC mining, the large discrepancy exists. Hence, with proof of stake, we may see an attack cost of $20-100 million for a network the size of Bitcoin; hence it is more likely that the level of security will be enough, but still not certain.

The Ramsey Problem

Let us suppose that relying purely on current transaction fees is insufficient to secure the network. There are two ways to raise more revenue. One is to increase transaction fees by constraining supply to below efficient levels, and the other is to add inflation. How do we choose which one, or what proportions of both, to use?

Fortunately, there is an established rule in economics for solving the problem in a way that minimizes economic deadweight loss, known as Ramsey pricing. Ramsey’s original scenario was as follows. Suppose that there is a regulated monopoly that has the requirement to achieve a particular profit target (possibly to break even after paying fixed costs), and competitive pricing (ie. where the price of a good was set to equal the marginal cost of producing one more unit of the good) would not be sufficient to achieve that requirement. The Ramsey rule says that markup should be inversely proportional to demand elasticity, ie. if a 1% increase in price in good A causes a 2% reduction in demand, whereas a 1% increase in price in good B causes a 4% reduction in demand, then the socially optimal thing to do is to have the markup on good A be twice as high as the markup on good B (you may notice that this essentially decreases demand uniformly).

The reason why this kind of balanced approach is taken, rather than just putting the entire markup on the most inelastic part of the demand, is that the harm from charging prices above marginal cost goes up with the square of the markup. Suppose that a given item takes $20 to produce, and you charge $21. There are likely a few people who value the item at somewhere between $20 and $21 (we’ll say average of $20.5), and it is a tragic loss to society that these people will not be able to buy the item even though they would gain more from having it than the seller would lose from giving it up. However, the number of people is small and the net loss (average $0.5) is small. Now, suppose that you charge $30. There are now likely ten times more people with “reserve prices” between $20 and $30, and their average valuation is likely around $25; hence, there are ten times more people who suffer, and the average social loss from each one of them is now $5 instead of $0.5, and so the net social loss is 100x greater. Because of this superlinear growth, taking a little from everyone is less bad than taking a lot from one small group.

Notice how the “deadweight loss” section is a triangle. As you (hopefully) remember from math class, the area of a triangle is width * length / 2, so doubling the dimensions quadruples the area.

In Bitcoin’s case, right now we see that transaction fees are and consistently have been in the neighborhood of ~50 BTC per day, or ~18000 BTC per year, which is ~0.1% of the coin supply. We can estimate as a first approximation that, say, a 2x fee increase would reduce transaction load by 20%. In practice, it seems like bitcoin fees are up ~2x since a year ago and it seems plausible that transaction load is now ~20% stunted compared to what it would be without the fee increase (see this rough projection); these estimates are highly unscientific but they are a decent first approximation.

Now, suppose that 0.5% annual inflation would reduce interest in holding BTC by perhaps 10%, but we’ll conservatively say 25%. If at some point the Bitcoin community decides that it wants to increase security expenditures by ~200,000 BTC per year, then under those estimates, and assuming that current txfees are optimal before taking into account security expenditure considerations, the optimum would be to push up fees by 2.96x and introduce 0.784% annual inflation. Other estimates of these measures would give other results, but in any case the optimal level of both the fee increase and the inflation would be nonzero. I use Bitcoin as an example because it is the one case where we can actually try to observe the effects of growing usage restrained by a fixed cap, but identical arguments apply to Ethereum as well.

Game-Theoretic Attacks

There is also another argument to bolster the case for inflation. This is that relying on transaction fees too much opens up the playing field for a very large and difficult-to-analyze category of game-theoretic attacks. The fundamental cause is simple: if you act in a way that prevents another block from getting into the chain, then you can steal that block’s transactions. Hence there is an incentive for a validator to not just help themselves, but also to hurt others. This is even more direct than selfish-mining attacks, as in the case of selfish mining you hurt a specific validator to the benefit of all other validators, whereas here there are often opportunities for the attacker to benefit exclusively.

In proof of work, one simple attack would be that if you see a block with a high fee, you attempt to mine a sister block containing the same transactions, and then offer a bounty of 1 BTC to the next miner to mine on top of your block, so that subsequent validators have the incentive to include your block and not the original. Of course, the original miner can then follow up by increasing the bounty further, starting a bidding war, and the miner could also pre-empt such attacks by voluntarily giving up most of the fee to the creator of the next block; the end result is hard to predict and it’s not at all clear that it is anywhere close to efficient for the network. In proof of stake, similar attacks are possible.

How to distribute fees?

Even given a particular distribution of revenues from inflation and revenues from transaction fees, there is an additional choice of how the transaction fees are collected. Though most protocols so far have taken one single route, there is actually quite a bit of latitude here. The three primary choices are:

• Fees go to the validator/miner that created the block
• Fees go to the validators equally
• Fees are burned

Arguably, the more salient difference is between the first and the second; the difference between the second and the third can be described as a targeting policy choice, and so we will deal with this issue separately in a later section. The difference between the first two options is this: if the validator that creates a block gets the fees, that validator has an incentive equal to the size of the fees to include as many transactions as possible. If it’s the validators equally, each one has a negligible incentive.

Note that literally redistributing 100% of fees (or, for that matter, any fixed percentage of fees) is infeasible due to “tax evasion” attacks via side-channel payment: instead of adding a transaction fee using the standard mechanism, transaction senders will put a zero or near-zero “official fee” and pay validators directly via other cryptocurrencies (or even PayPal), allowing validators to collect 100% of the revenue. However, we can get what we want by using another trick: determine in protocol a minimum fee that transactions must pay, and have the protocol “confiscate” that portion but let the miners keep the entire excess (alternatively, miners keep all transaction fees but must in turn pay a fee per byte or unit gas to the protocol; this a mathematically equivalent formulation). This removes tax evasion incentives, while still placing a large portion of transaction fee revenue under the control of the protocol, allowing us to keep fee-based issuance without introducing the game-theoretic malicentives of a traditional pure-fee model.

The protocol cannot take all of the transaction fee revenues because the level of fees is very uneven and because it cannot price-discriminate, but it can take a portion large enough that in-protocol mechanisms have enough revenue allocating power to work with to counteract game-theoretic concerns with traditional fee-only security.

One possible algorithm for determining this minimum fee would be a difficulty-like adjustment process that targets a medium-term average gas usage equal to 1/3 of the protocol gas limit, decreasing the minimum fee if average usage is below this value and increasing the minimum fee if average usage is higher.

We can extend this model further to provide other interesting properties. One possibility is that of a flexible gas limit: instead of a hard gas limit that blocks cannot exceed, we have a soft limit G1 and a hard limit G2 (say, G2 = 2 * G1). Suppose that the protocol fee is 20 shannon per gas (in non-Ethereum contexts, substitute other cryptocurrency units and “bytes” or other block resource limits as needed). All transactions up to G1 would have to pay 20 shannon per gas. Above that point, however, fees would increase: at (G2 + G1) / 2, the marginal unit of gas would cost 40 shannon, at (3 * G2 + G1) / 4 it would go up to 80 shannon, and so forth until hitting a limit of infinity at G2. This would give the chain a limited ability to expand capacity to meet sudden spikes in demand, reducing the price shock (a feature that some critics of the concept of a “fee market” may find attractive).

What to Target

Let us suppose that we agree with the points above. Then, a question still remains: how do we target our policy variables, and particularly inflation? Do we target a fixed level of participation in proof of stake (eg. 30% of all ether), and adjust interest rates to compensate? Do we target a fixed level of total inflation? Or do we just set a fixed interest rate, and allow participation and inflation to adjust? Or do we take some middle road where greater interest in participating leads to a combination of increased inflation, increased participation and a lower interest rate?

In general, tradeoffs between targeting rules are fundamentally tradeoffs about what kinds of uncertainty we are more willing to accept, and what variables we want to reduce volatility on. The main reason to target a fixed level of participation is to have certainty about the level of security. The main reason to target a fixed level of inflation is to satisfy the demands of some token holders for supply predictability, and at the same time have a weaker but still present guarantee about security (it is theoretically possible that in equilibrium only 5% of ether would be participating, but in that case it would be getting a high interest rate, creating a partial counter-pressure). The main reason to target a fixed interest rate is to minimize selfish-validating risks, as there would be no way for a validator to benefit themselves simply by hurting the interests of other validators. A hybrid route in proof of stake could combine these guarantees, for example providing selfish mining protection if possible but sticking to a hard minimum target of 5% stake participation.

Now, we can also get to discussing the difference between redistributing and burning transaction fees. It is clear that, in expectation, the two are equivalent: redistributing 50 ETH per day and inflating 50 ETH per day is the same as burning 50 ETH per day and inflating 100 ETH per day. The tradeoff, once again, comes in the variance. If fees are redistributed, then we have more certainty about the supply, but less certainty about the level of security, as we have certainty about the size of the validation incentive. If fees are burned, we lose certainty about the supply, but gain certainty about the size of the validation incentive and hence the level of security. Burning fees also has the benefit that it minimizes cartel risks, as validators cannot gain as much by artificially pushing transaction fees up (eg. through censorship, or via capacity-restriction soft forks). Once again, a hybrid route is possible and may well be optimal, though at present it seems like an approach targeted more toward burning fees, and thereby accepting an uncertain cryptocurrency supply that may well see low decreases on net during high-usage times and low increases on net during low-usage times, is best. If usage is high enough, this may even lead to low deflation on average.

]]> https://earlybirdsinvest.com/on-inflation-transaction-fees-and-cryptocurrency-monetary-policy/feed/ 0 58019 https://earlybirdsinvest.com/uncle-rate-and-transaction-fee-analysis/ https://earlybirdsinvest.com/uncle-rate-and-transaction-fee-analysis/#respond Thu, 11 Sep 2025 12:44:49 +0000 https://earlybirdsinvest.com/uncle-rate-and-transaction-fee-analysis/

One of the important indicators of how much load the Ethereum blockchain can safely handle is how the uncle rate responds to the gas usage of a transaction. In all blockchains of the Satoshian proof-of-work variety, any block that is published has the risk of howbecoming a “stale”, ie. not being part of the main chain, because another miner published a competing block before the recently published block reached them, leading to a situation where there is a “race” between two blocks and so one of the two will necessarily be left behind.

One important fact is that the more transactions a block contains (or the more gas a block uses), the longer it will take to propagate through the network. In the Bitcoin network, one seminal study on this was Decker and Wattenhofer (2013), which found that the average propagation time of a block was about 2 seconds plus another 0.08 seconds per kilobyte in the block (ie. a 1 MB block would take ~82 seconds). A more recent Bitcoin Unlimited study showed that this has since reduced to ~0.008 seconds per kilobyte due to transaction propagation technology improvements. We can also see that if a block takes longer to propagate, the chance that it will become a stale is higher; at a block time of 600 seconds, a propagation time increase of 1 second should correspond to an increased 1/600 chance of being left behind.

In Ethereum, we can make a similar analysis, except that thanks to Ethereum’s “uncle” mechanic we have very solid data to analyze from. Stale blocks in Ethereum can be re-included into the chain as “uncles”, where they receive up to 75% of their original block reward. This mechanic was originally introduced to reduce centralization pressures, by reducing the advantage that well-connected miners have over poorly connected miners, but it also has several side benefits, one of which is that stale blocks are tracked for all time in a very easily searchable database – the blockchain itself. We can take a data dump of blocks 1 to 2283415 (before the Sep 2016 attacks) as a source of data for analysis.

Here is a script to generate some source data: http://github.com/ethereum/research/tree/master/uncle_regressions/block_datadump_generator.py

Here is the source data: http://github.com/ethereum/research/tree/master/uncle_regressions/block_datadump.csv

The columns, in order, represent block number, number of uncles in the block, the total uncle reward, the total gas consumed by uncles, the number of transactions in the block, the gas consumed by the block, the length of the block in bytes, and the length of the block in bytes excluding zero bytes.

We can then use this script to analyze it: http://github.com/ethereum/research/tree/master/uncle_regressions/base_regression.py

The results are as follows. In general, the uncle rate is consistently around 0.06 to 0.08, and the average gas consumed per block is around 100000 to 300000. Because we have the gas consumed of both blocks and uncles, we run a linear regression to estimate of how much 1 unit of gas adds to the probability that a given block will be an uncle. The coefficients turn out to be as follows:

Block 0 to 200k: 3.81984698029e-08
Block 200k to 400k: 5.35265798406e-08
Block 400k to 600k: 2.33638832951e-08
Block 600k to 800k: 2.12445242166e-08
Block 800k to 1000k: 2.7023102773e-08
Block 1000k to 1200k: 2.86409050022e-08
Block 1200k to 1400k: 3.2448993833e-08
Block 1400k to 1600k: 3.12258208662e-08
Block 1600k to 1800k: 3.18276549008e-08
Block 1800k to 2000k: 2.41107348445e-08
Block 2000k to 2200k: 1.99205804032e-08
Block 2200k to 2285k: 1.86635688756e-08

Hence, each 1 million gas worth of transactions that gets included in a block now adds ~1.86% to the probability that that block will become an uncle, though during Frontier this was closer to 3-5%. The “base” (ie. uncle rate of a 0-gas block) is consistently ~6.7%. For now, we will leave this result as it is and not make further conclusions; there is one further complication that I will discuss later at least with regard to the effect that this finding has on gas limit policy.

Gas pricing

Another issue that touches uncle rates and transaction propagation is gas pricing. In Bitcoin development discussions, a common argument is that block size limits are unnecessary because miners already have a natural incentive to limit their block sizes, which is that every kilobyte they add increases the stale rate and hence threatens their block reward. Given the 8 sec per megabyte impedance found by the Bitcoin Unlimited study, and the fact that each second of impedance corresponds to a 1/600 chance of losing a 12.5 BTC block reward, this suggests an equilibrium transaction fee of 0.000167 BTC per kilobyte assuming no block size limits.

In Bitcoin’s environment, there are reasons to be long-term skeptical about the economics of such a no-limit incentive model, as there will eventually be no block reward, and when the only thing that miners have to lose from including too many transactions is fees from their other transactions, then there is an economic argument that the equilibrium stale rate will be as high as 50%. However, there are modifications that can be made to the protocol to limit this coefficient.

In Ethereum’s current environment, block rewards are 5 ETH and will stay that way until the algorithm is changed. Accepting 1 million gas means a 1.86% chance of the block becoming an uncle. Fortunately, Ethereum’s uncle mechanism has a happy side effect here: the average uncle reward is recently around 3.2 ETH, so 1 million gas only means a 1.86% chance of putting 1.8 ETH at risk, ie. an expected loss of 0.033 ETH and not 0.093 as would be the case without an uncle mechanism. Hence, the current gas prices of ~21 shannon are actually quite close to the “economically rational” gas price of 33 shannon (this is before the DoS attacks and the optimizations arising therefrom; now it is likely even lower).

The simplest way to push the equilibrium gasprice down further is to improve uncle inclusion mechanics and try to get uncles included in blocks as quickly as possible (perhaps by separately propagating every block as a “potential uncle header”); at the limit, if every uncle is included as quickly as possible, the equilibrium gas price would go down to about 11 shannon.

Is Data Underpriced?

A second linear regression analysis can be done with source code here: http://github.com/ethereum/research/tree/master/uncle_regressions/tx_and_bytes_regression.py

The purpose here is to see if, after accounting for the above computed coefficients for gas, there is a correlation with the number of transactions or with the size of a block in bytes left over. Unfortunately, we do not have block size or transaction count figures for uncles, so we have to resort to a more indirect trick that looks at blocks and uncles in groups of 50. The gas coefficients that this analysis finds are higher than the previous analysis: around 0.04 uncle rate per million gas. One possible explanation is that if a single block has a high propagation time, and it leads to an uncle, there is a 50% chance that that uncle is the high-propagation-time block, but there is also a 50% chance that the uncle will be the other block that it competes against. This theory matches well with the 0.04 per million “social uncle rate” and the ~0.02 per million “private uncle rate” finding; hence we will take it as the most likely explanation.

The regression finds that, after accounting for this social uncle rate, one byte accounts for an additional ~0.000002 uncle rate. Bytes in a transaction take up 68 gas, of which 61 gas accounts for its contribution to bandwidth (the remaining 7 is for bloating the history database). If we want the bandwidth coefficient and the computation coefficient in the gas table to both reflect propagation time, then this implies that if we wanted to really optimize gas costs, we would need to increase the gas cost per byte by 50 (ie. to 138). This would also entail raising the base gas cost of a transaction by 5500 (note: such a rebalance would not mean that everything gets more expensive; the gas limit would be raised by ~10% so that the average-case transaction throughput would remain unchanged). On the other hand, the risk of worst-case denial-of-service attacks is worse for execution than for data, and so execution requires larger safety factors. Hence, there is arguably not sufficiently strong evidence to do any re-pricings here at least for the time being.

One possible long-term protocol change would be to introduce separate gas pricing mechanisms for in-EVM execution and transaction data; the argument here is that the two are much easier to separate as transaction data can be computed separately from everything else, and so the optimal strategy may be to somehow allow the market to balance them; however, precise mechanisms for doing such a thing still need to be developed.

Gas Limit Policy

For an individual miner determining their gas price, the “private uncle rate” of 0.02 per million gas is the relevant statistic. From the point of view of the whole system, the “social uncle rate” of 0.04 per million gas is what matters. If we did not care about safety factors and were ok with an uncle rate of 0.5 uncles per block (meaning, a “51% attack” would only need 40% hashpower to succeed, actually not as bad as it sounds) then at least this analysis suggests that the gas limit could theoretically be raised to ~11 million (20 tx/sec given an average 39k gas per tx as is the case under current usage, or 37 tx/sec worth of simple sends). With the latest optimizations, this could be pushed even higher. However, since we do care about safety factors and prefer to have a lower uncle rate to alleviate centralization risks, 5.5 million is likely an optimal level for the gas limit, though in the medium term a “dynamic gas limit” formula that targets a particular block processing time would be a better approach, as it would be able to quickly and automatically adjust in response to attacks and risks.

Note that the concern about the centralization risks and the need for safety factors do not stack on top of each other. The reason is that during an active denial-of-service attack, the blockchain needs to survive, not be long-term economically centralization-resistant; the argument is that if the attacker’s goal was to economically encourage centralization, then the attacker could just donate money to the biggest pool in order to bribe other miners to join it.

In the future, we can expect virtual machine improvements to decrease uncle rates further, though improvements to networking are eventually going to be required as well. There is a limit to how much scalability is possible on a single chain, with the primary bottleneck being disk reads and writes, so after some point (likely 10-40 million gas) sharding will be the only way to process more transactions. If we just want to decrease equilibrium gas prices, then Casper will help substantially, by making the “slope” of uncle rate to gas consumption near-zero at least up to a certain point.

What does non-saving mean in this context?

Non-active means “we are missing things because we are not guaranteed, especially in the presence of enemies or when the volume is really high.” Also, the “package relay” in quotes refers to the fact that there is no package relay protocolpart of the opportunistic logic that can be seen when an orphanage transaction happens to be CPFping a failed transaction with low refueling.

Perhaps a good similarity is if you’re a restaurant chef who doesn’t have a dedicated server. Once you’re finished cooking, you can opportunistically bring food to the table, which is often fine, but delayed during rush hour. The ticket system is also not evaluated. If you can’t keep all the tickets, then random tickets will fall to the ground and forget to order them. One annoying customer can ruin someone else’s dining experience by ordering 100 diet cokes.

We can hire others to serve food. It certainly makes the restaurant more efficient (e.g. BIP 331, still WIP), but it doesn’t solve everything. Starting from 30.0, there is a strategy to limit customers to rates so they don’t forget to send out huge amounts (see “P2P: Improve Service Boundaries in Txorphanage” https://github.com/bitcoin/bitcoin/pull/31829).

Are there any situations where parents’ transactions cannot be confirmed yet?

The most important limitation of 28.0 is that Cook can only offer something very simple (1P1C package). Anything above 1P1C will not work. If the child has another unconfirmed parent, the logic of opportunism will not work, even if it is already in Mempools. This has also been changed (“Package Validation: Relax the package.

When broadcasting a transaction via SendRawTransaction, Bitcoin Core 28.0 automatically forms a 1P1C package

That’s the right thing to do. When you send a transaction to Mempool, the node does everything automatically. If it is a 0-FEE parent + child package, sendrawtransaction You might complain about the fees, so you submitpackage RPC (equivalent to multi-transactions sendrawtransaction (with a very similar API). RPCs also accept single transactions, so it may be most convenient to use them all the time.

Bitcoin (BTC) treasury companies reached a record holding of 840,000 BTC in August, but underlying data reveal weakening institutional demand.

According to a Sept. 5 report by CryptoQuant, purchase volumes and transaction sizes plummeted to multi-year lows.

Strategy led corporate Bitcoin accumulation with 637,000 BTC, representing 76% of total treasury holdings. At the same time, 32 other companies control the remaining 203,000 BTC.

Holdings surged following the November 2024 US Presidential Election, with Strategy more than doubling its position from 279,000 to 637,000 BTC and other companies expanding their holdings 13-fold from 15,000 to 203,000 BTC.

Declining purchase volumes

Strategy acquired 3,700 BTC in August, down dramatically from 134,000 BTC purchased in November 2024. Other treasury companies purchased 14,800 BTC, which is below the 2025 average of 24,000 BTC and significantly lower than their June peak of 66,000 BTC.

The average Bitcoin per transaction dropped to 1,200 for Strategy and 343 for other companies, down 86% from early 2025 highs. The report attributed the smaller transaction sizes to liquidity constraints or potential market hesitation among institutional buyers.

Monthly holdings growth decelerated sharply for Strategy, falling from 44% in December 2024 to just 5% in August. Other treasury companies experienced similar patterns, with monthly growth dropping from 163% in March to 8% in August.

Despite recording 53 purchase transactions in June and maintaining elevated activity through August with 46 transactions, the frequency masks declining institutional appetite. Treasury companies completed only 14 transactions in November 2024, making current levels appear robust by comparison.

The Crypto Investor Blueprint: A 5-Day Course On Bagholding, Insider Front-Runs, and Missing Alpha

Nice Your first lesson is on the way.

Please add [email protected] to your email whitelist.

The report focused on pure-play, publicly-traded Bitcoin treasury companies holding 1,000 BTC or more, excluding mining companies and firms with substantial operating businesses like Tesla and Coinbase.

Regulatory and market pressures mount

The treasury market faces new regulatory headwinds as Nasdaq implements shareholder approval requirements for equity issuances used to purchase crypto.

The rule change targets the crypto-treasury playbook, where public companies sell equity or convertibles to fund token purchases. As a result, this change could slow the rapid capital deployment that characterized 2025.

In addition, Sequans Communications became the first Bitcoin treasury company to execute a reverse stock split, adjusting its American Depositary Shares structure to maintain NYSE listing requirements.

The company controls 3,205 BTC, valued at approximately $355 million, but its stock declined 75% this year, raising concerns about potential asset sales to defend share prices.

The report concluded by revealing patterns similar to the 2020-2021 cycle, when Strategy’s holdings growth peaked at 78% before declining to 6% a year later. The current setup suggests institutional Bitcoin accumulation may be entering a similar deceleration phase.

Mentioned in this article

Good Morning, Asia. Here’s what’s making news in the markets:

Welcome to Asia Morning Briefing, a daily summary of top stories during U.S. hours and an overview of market moves and analysis. For a detailed overview of U.S. markets, see CoinDesk’s Crypto Daybook Americas.

Bitcoin’s price is holding near records, but the chain itself is quiet. Glassnode data shows transaction fees have collapsed back toward decade lows, even as BTC flirts with six figures.

In past cycles, fee spikes tracked bull markets as traders bid for blockspace. This year, the fee curve is flat while price rises, a clear sign that onchain demand is no longer driving the market.

A new report from Galaxy Research shows median daily fees have fallen more than 80% since April 2024, with as much as 15% of daily blocks now clearing at just 1 satoshi per vbyte. Nearly half of recent blocks are not full, signaling weak demand for blockspace and a dormant mempool.

This is a sharp contrast to prior bull cycles, where price rallies translated into congestion and fee spikes.

The data confirms a structural shift: spot ETFs and custodians now hold more than 1.3 million BTC, and coins parked in those wrappers rarely touch the chain again.

At the same time, retail activity that once clogged the Bitcoin blockchain has migrated to Solana, where memecoins and NFTs benefit from cheaper and faster execution. The result, Galaxy notes, is that the bitcoin price is being set by custodial inflows while the network’s onchain demand – once a proxy for price movement – has slowed down.

For miners, this dynamic is particularly punishing. With rewards halved to 3.125 BTC and fees contributing less than 1% of block revenue in July, profitability is under strain. That stress is pushing listed miners to diversify into AI and HPC hosting.

Read more: Bitcoin Mining Faces ‘Incredibly Difficult’ Market as Power Becomes the Real Currency

A report from earlier this year by Rittenhouse Research argues that Galaxy Digital’s move out of mining altogether could be the model for the sector.

This move has been applauded by the equity markets. While BTC is down more than 3% on-year, the CoinShares Bitcoin Mining ETF has gained nearly 22%. Investors are rewarding firms that have leaned into diversification rather than relying on block rewards alone.

Listed miners tell a similar story. Hive, Core Scientific, and TeraWulf all reported Q2 results padded by HPC and AI hosting revenues.

Those with no diversification, like Bitdeer and BitFuFu, remain deeply exposed to electricity costs, equipment depreciation, and a fee market that Galaxy warns in its report is “anything but robust.”

The juxtaposition is telling: Galaxy’s own research warns that the Bitcoin blockchain’s settlement role is stagnating, while Galaxy’s balance sheet is being repositioned for growth in AI data centers.

Onchain data makes the point: without organic demand for blockspace, fees can’t fund security. And if fees stay low, equity markets are painting a clear picture that mining sector’s best future returns may come from AI, not Bitcoin.

Market Movements

BTC: Bitcoin traded at $113,286.95, down 1.79%, after briefly plunging to a six-week low near $110,600, with the broader crypto market facing heavy liquidations and volatility.

ETH: Ether traded flat at $4,779 as Jerome Powell’s dovish Jackson Hole remarks boosted expectations of a September rate cut, with asset managers predicting new highs for bitcoin and an ETH breakout above $5,000 despite risks from treasury adoption and equity volatility.

Gold: Gold closed at $3,371 after Powell’s dovish Jackson Hole remarks boosted September rate-cut odds.

Nikkei 225: Asia-Pacific stocks climbed Monday, with Japan’s Nikkei 225 up 1.08%, after Powell signaled potential Fed rate cuts in September during his Jackson Hole speech.

Elsewhere in Crypto

• The Funding: Why raising a crypto VC fund is harder now — even in a bull market (The Block)
• Why Luca Netz Will Be ‘Disappointed’ If Pudgy Penguins Doesn’t IPO Within 2 Years (Decrypt)
• KPMG Says Investor Interest in Digital Assets Will Drive Strong Second Half for Canadian Fintechs (CoinDesk)

I wrote the following function to build and sign a Taproot (P2TR) transaction using @cmdcode/tapscript: My intention is to support spending on both key and script paths.

The problem is that it doesn’t work as expected.

Script-Path spending often fails validation (e.g. block error, invalid witness, or failed script execution).

Can someone review my code and point out what’s wrong with my logic or implementation? I especially appreciate the advice on how to fix performance improvements in script path failures and key path cases.

import { Address, Signer, Tap, Tx } from '@cmdcode/tapscript';

protected buildTaprootTx(
  senderKey: { publicKey: Uint8Array; privateKey: Uint8Array },
  utxos: Array<{ txid: string; vout: number; value: number }>,
  recipient: string,
  amountSat: number,
  feeSat: number,
  mode: 'key' | 'script' | 'both',
  scriptLeaves: Array = (),
  opReturnData?: Uint8Array | string,
  changeAddr?: string
): string {
  // ... (full code as in my gist, see link below)
}

Complete code

question:

• What am I doing wrong, especially when it comes to script path spending?

• Is there a better way to configure or optimize features for performance and accuracy?

• If you find any obvious bugs or misconceptions in how you use TapRoot key/Script Path Logic, please point them out.

Code reviews, suggestions, or references to practical examples are highly appreciated. thank you!

The total on-chain stablecoin transaction volume surged to a new all-time high of $1.5 trillion in July, marking a significant milestone in the sector.

According to Sentora’s (formerly IntoTheBlock) data, this figure represents a sharp increase from the $1.26 trillion processed in June and surpasses the previous high seen in August 2024, when volumes topped $1.4 trillion.

Meanwhile, a closer look at the July numbers revealed that Circle’s USDC dominated the stablecoin market, accounting for nearly 50% of the total volume. USDC transactions reached approximately $748 billion in July.

Meanwhile, Tether’s USDT, the largest stablecoin by circulating supply, followed with a volume of $420 billion. The decentralized DAI stablecoin secured the third spot with $261 billion in transactions.

Why stablecoin volume rose in July

The remarkable increase in stablecoins’ on-chain volume can be attributed to several factors, including Bitcoin and Ethereum’s record performances in July.

Last month, Bitcoin price rose to a new all-time high of over $123,000 while ETH’s price also approached the $4000 threshold.

The price performance of these assets sparked significant on-chain activity from investors, who invested their profits in non-volatile digital assets like USDT and USDC.

In addition, the stablecoin industry saw the approval of its first major bill in the US, which helped clear the regulatory uncertainty in the sector.

The GENIUS Act, signed into law on July 19, established clear guidelines for stablecoins and digital asset-backed financial products. The new regulations include reserve requirements and oversight by the Federal Reserve, which are likely to foster greater trust and stability in the sector.

As a result, prominent financial institutions like JPMorgan and other top global companies like Meta have been exploring the use of stablecoins for cross-border transactions and other financial services, which further legitimizes the market.

With this clearer regulatory backdrop and surging adoption, stablecoin market capitalization has climbed past $278 billion, according to CryptoSlate’s data.

Mentioned in this article

The transaction will not be cancelled and there will be no refunds. However, senders don’t have to wait for anything to happen, at least in theory, before trying to use their money in a different way.

When a user broadcasts a transaction, it represents an attempt to move the coins involved. Once that transaction is confirmed, everyone will agree that it happened. But before we confirm, it’s a matter of perspective. Usually, the sender wallet deals with coins as soon as a transaction is created, but as far as blockchain is concerned, they still reside in the sender wallet.

This protocol does not prevent the sender from creating another transaction that uses the same coin. Therefore, it inevitably competes with the first coin (via a principle called Alternate Buy (RBF)). Some wallets allow RBFs only to increase the fees for transactions that are too slow, but some wallets allow users to “waive” non-confident transactions in situations where they allow them to spend their funds in different ways, in some circumstances.

In short, there is no refund. Because as far as networks are concerned, non-traditional transactions simply aren’t. It happened. It’s a question of how to deal with it for the sender’s wallet.

PayPal has launched a new initiative, “Pay with Crypto,” aimed at streamlining global commerce and significantly reducing the cost of cross-border transactions, according to a July 28 statement.

According to the company, the service offers merchants a 90% reduction in international transaction fees compared to traditional credit card processors.

Pay with crypto

This is made possible by instant conversions from crypto into fiat or PayPal USD (PYUSD), its native stablecoin. The platform supports over 100 cryptocurrencies, including Bitcoin and Ethereum, and is compatible with major wallets like Coinbase and MetaMask.

PayPal estimates that this move opens access to over 650 million crypto users worldwide, allowing merchants to tap into a rapidly growing digital asset economy.

Alex Chriss, PayPal’s President and CEO, emphasized the program’s potential to eliminate long-standing barriers in international commerce.

He said:

“Imagine a shopper in Guatemala buying a special gift from a merchant in Oklahoma City. Using PayPal’s open platform, the business can accept crypto for payments, increase their profit margins, pay lower transaction fees, get near instant access to proceeds, and grow funds stored as PYUSD at 4% when held on PayPal.”

“Pay with Crypto” consolidates fiat and crypto payments into a single interface, giving consumers flexible payment options while empowering merchants to reach global markets. It also aligns with PayPal’s broader efforts to expand stablecoin usage and drive financial efficiency.

The initiative follows recent developments, including PayPal’s partnership with Fiserv to promote global stablecoin adoption.

PayPal World

Meanwhile, the company recently launched “PayPal World,” a new platform designed to connect major digital wallets and simplify cross-border commerce.

The initiative will debut with interoperability between five key players, including PayPal, Venmo, Tenpay Global, NPCI International (UPI), and Mercado Pago.

According to the firm, this reinforces its commitment to simplified, low-cost digital commerce. Chriss said:

“These innovations don’t just simplify payments—they drive merchant growth, expand consumer choice, and reduce costs. This is the future of inclusive, borderless commerce, and we’re proud to lead it.”

Mentioned in this article