Identify the recipient before comparing revenue
In crypto discussions, revenue can mean a user's expense, an infrastructure operator's receipts, an application's earnings or tokens removed from supply. These quantities are not interchangeable. A useful comparison first chooses the recipient, unit and measurement period. Otherwise, a table can silently compare network fees on one platform with trading fees on another.
Keep three separate entries in mind: paid for a service, received by a named participant, and removed from supply. When a fee is split between two destinations, both shares are already included in the original payment. Adding the payment and its components together creates double counting, even if every underlying number is accurate.
A holder should ask a further question: did my own balance increase? A reduction in total supply and a payment to a wallet are different events. The former can happen while the wallet's token count remains unchanged. The latter needs an identifiable distribution rule, eligibility conditions and a measurable amount.
Ethereum separates burning from validator receipts
Ethereum burns the execution base fee and pays the priority tip to the validator including the transaction. The user's charge depends on gas consumed and the applicable rates. Treating all gas payments as validator revenue, or as cash distributed to ETH holders, therefore misstates the mechanism.
Burning alone does not establish a net supply reduction over an arbitrary period; issuance also matters. Nor does a quantity of destroyed tokens establish a particular holder's return. A protocol operation and the price that a market assigns to its consequences are separate questions.
An L2 user's bill is not Ethereum's data bill
EIP-4844 specifies a distinct fee market for blobs used to make rollup data available. The blob fee adjusts with demand and is burned. Cheap data availability during periods of low demand is not a permanent promise of free service.
An L2 comparison must distinguish what an end user pays from what data publication costs. The difference is not automatically net profit: other expenses still need to be identified. A statement that activity increased does not establish how either payment stream changed.
This distinction also prevents moving a number between accounting layers. An application charge, an execution fee and a data-availability payment may be associated with one user action while purchasing different services. Calling all three Ethereum revenue would need a justification that the shared activity alone cannot provide.
Solana routes base fees and priority fees differently
Solana's documentation specifies a base fee of 5,000 lamports per signature, split equally between burning and the validator. The priority fee goes entirely to the validator. The half-burned rule consequently cannot be applied to the whole payment when a priority component is present.
This routing does not amount to a direct payout to every SOL holder. Operator receipts, staking participation and passive token ownership are different categories. Evaluating a particular participant requires checking their actual arrangement rather than substituting an aggregate network revenue figure for their income.
Hyperliquid buybacks are not holder dividends
Hyperliquid's fee documentation identifies HLP, the assistance fund and market deployers as destinations for trading fees. The assistance fund automatically converts its receipts into HYPE. The documentation describes HYPE in that fund as burned, removing it from both circulating and total supply.
The token purchase is a distinct step, unlike burning a base fee already paid in the native asset. But simply holding HYPE does not credit a wallet with a proportional share of the fund's receipts. Describing a buyback as a holder payout skips that distinction.
Even an observed purchase amount cannot fix the future price. Such a prediction would require assumptions about opposing sales and demand from other participants. A verifiable buyback mechanism is not a guarantee of appreciation.
HIP-3 economics depend on market settings
For builder-deployed perpetual markets under HIP-3, the current API documentation includes a configurable fee scale through setFeeScale. The allocation depends on parameters. An illustration that assumes every payment always follows one fixed fifty-fifty split is not sufficient.
A market deployer also configures and operates elements such as oracle inputs. The base protocol's economics and those of a particular market operator should therefore be examined separately. They are not merely alternative labels for the same recipient.
For any summary table, ask whether the deployer component is reported separately, whether it is already included in the total and which settings applied during the measurement period. Without these details, even a comparison within one protocol can mix unlike arrangements.
Use consistent accounting, not implied yields
Consider an invented example, not actual figures for these networks. Users pay 100 units in a day; an operator receives 60 and 40 are destroyed. The aggregate fee is 100, not 140 or 200. Meanwhile, a token owner with no distribution entitlement has not received those 40 units in their account.
Now suppose the number of operations doubles while the average charge falls to one third of its former value. Total fees fall to two thirds of the original level. This arithmetic is not a forecast for Ethereum, Solana or Hyperliquid. It demonstrates why a rising activity counter alone cannot prove rising revenue.
Before comparing totals, check which operations are included, who receives the payments and how refunds or other participants' shares are treated. Use matching time windows. Examine native-token amounts separately from their value in a chosen reporting currency: exchange-rate changes can move the money figure without changing the underlying token flow.
Finally, do not turn one unusual day into a recurring annual payment without stating that assumption. A mechanically annualized number answers what would happen if the day repeated, not whether repetition is likely. It also cannot grant a holder rights that the protocol never assigned.
A strong comparison ends with an auditable payment route, not a declared winner. Users care about the cost of their intended action. Operators need receipts and expenses. Holders need to understand their actual rights and risks. One network activity metric cannot replace those three separate analyses.
