Sinks

Destroying supply and parking supply are different claims

Two things get called sinks and they behave nothing alike under pressure. A destructive sink removes tokens permanently: the supply is gone and no holder decision can bring it back. A custodial sink parks tokens somewhere they cannot trade, which is reversible by definition, because the person who locked them can usually unlock them. Both reduce the tradable float today. Only one reduces it tomorrow.

That difference is the whole risk profile. A locked position is a claim on future float held by someone whose reasons for holding it are their own. When those reasons change, the tokens come back, and they tend to come back in the conditions where you least want more supply. Treating a lockup as though it were a burn is a common accounting error in token models and it flatters the numbers in exactly one direction.

So the first question about any sink is not how much it absorbs. It is whether absorption is permanent, and who gets to decide.

Why the sink side is the hard half

Faucet design is arithmetic. You choose a curve, a set of buckets and a decay rate, and the model produces the emission you asked for. Sink design does not work that way, because a sink is a behaviour rather than a parameter. Something has to be worth doing in the token, by someone with an alternative, at a price they accept, repeatedly.

The game industry hit this decades before crypto did. Virtual-economy work defines sinks as mechanisms that permanently remove wealth from circulation, and the design literature is largely a catalogue of ways studios have tried to make removal voluntary and still get take-up.¹ EVE Online's in-house economist has described the sink and faucet model as standard practice across online games, which tells you it is an operating discipline rather than a theory.²

Where crypto diverges is that a game studio can add a sink in a patch and observe it within a week. A protocol adds a sink by shipping a mechanism, changing user behaviour, and waiting. A sink bolted on after launch, fighting habits users already formed, rarely gets the depth to matter. Design it in, or accept that the emission has no counterparty.

Sort your sinks by who decides

The useful classification is not flow against stock. It is whether the sink fires because someone had to use the protocol, or because someone chose to take a position. A required sink absorbs supply as a byproduct of activity you already wanted. An optional sink absorbs supply only while the incentive to participate holds, which means it is strongest in the conditions where you need it least.

Run your own mechanisms through this grid before you argue about rates. Most models that look sink-rich turn out to be concentrated in the bottom-right quadrant, where every unit of absorption depends on a holder continuing to choose it.

The deflation claim, stated the way the evidence supports it

Here is the sentence that appears in almost every deck: the burn makes the token deflationary, therefore the price goes up. Two separate claims are stacked there and only the first half of the first one is established. EIP-1559 specifies that a block's base fee per gas is burned rather than paid to the block producer, so a mechanical, protocol-level reduction in supply is real and formally documented.³ That is where the citable part stops.

Whether supply actually falls net of issuance is conditional rather than fixed. Ethereum's own design can sit net-positive or net-negative depending on how much the network is being used, which is precisely why a live dashboard exists to answer the question continuously instead of a fixed figure appearing in the spec.⁴ Anyone quoting a permanent deflation rate is quoting a snapshot.

The second claim, that a burn is therefore price-positive, has no source in this cluster we would put our name to. A burn changes one side of an equation while demand does whatever demand does. We are not aware of a study establishing a causal price effect from burning alone, and any founder told otherwise should ask to see it. Treat burn-as-bullish as folklore. Treat burn-as-supply-mechanism as fact.

Both sink types fail in the same week

Usage-triggered sinks depend on activity. If transactions fall, burn volume falls with them, and the absorption weakens exactly when scheduled vesting keeps delivering supply on time regardless. The sink is procyclical, and nobody designs it that way on purpose; it just is.

Position-based sinks depend on conviction. If price falls hard, some stakers exit, the lockup unwinds, and the float grows at the worst possible moment. So the two sink categories that look like a diversified defence are correlated in the one scenario you built them for. This is not an argument against either. It is an argument for stress-testing the sink side against a demand drawdown rather than a demand base case, and for knowing which of your sinks survives it.

You will also hear that adding a sink solves a velocity problem. That inference is a practitioner shortcut rather than a demonstrated result, and the velocity framework underneath it has named critics in the literature. Say what the sink does mechanically and let the velocity argument stand on its own page.

Governance voting is not a sink

The most common thing we find in place of a sink is governance. A token confers votes, votes are described as utility, and the model implies that this holds supply somewhere. It does not. Voting does not remove tokens from the tradable float with any reliability, it costs nothing to skip, and turnout in most token systems tells you exactly how much demand it generates.

The uncomfortable version of this finding is that a governance token with no fee routing, no collateral requirement and no access lockup has no sink at all. It has a faucet schedule and a story. Teams usually discover this while auditing circulating supply and realising there is no point in the design where anyone must acquire the token to get something done.

The fix is not a bigger burn announcement. It is finding the point in the product where the token is genuinely load-bearing, which is a business question rather than a mechanism question, and sometimes the honest answer is that the point does not exist yet.