Demand sink

The term is ours, not the literature's

Worth saying up front, because pedigree gets invented in this field constantly: demand sink is a practitioner compound. No academic source we have found uses it as a term of art. What is well documented is the older faucet and sink vocabulary out of virtual-economy design, which token designers carried across in the late 2010s. Demand sink is an extension of that vocabulary, built to name a distinction the original pair does not make.

The distinction is worth the coinage. Faucets and sinks are supply-side accounting: what came in, what went out. That framing can be fully satisfied by a mechanism nobody was ever required to touch. A demand sink is a claim about compulsion, and compulsion is what survives a bad quarter.

Removing supply and compelling acquisition are separate jobs

Consider a treasury that buys tokens on the open market and destroys them. Supply falls, so the mechanism is a sink by any definition. Nobody was compelled to do anything. The protocol funded the purchase from its own balance, and if the balance stops funding it, the absorption stops with it. That is a sink with no demand sink attached.

Now consider a network where an operator cannot register a node without posting tokens as a bond. Every new operator has to go to market and buy. Supply gets locked, which makes it a sink, and acquisition is forced, which makes it a demand sink. The two properties travel together here, but they do not have to, and modelling them as one number is where most token models start overstating themselves.

The practical consequence is in how you forecast. Sink volume can be modelled from protocol cash flow. Demand-sink volume has to be modelled from participant counts and their obligations, because it scales with how many people are doing the thing, not with how much money the treasury has.

Which asset does the mechanism actually require?

This is where most demand-sink claims quietly fall over, and it is the single most useful question on this page. A mechanism can be genuinely mandatory and still generate no demand for your token, because the asset it requires is something else.

MakerDAO is the clean illustration. Minting DAI requires collateral to be locked in the protocol's core accounting module, and that requirement is structural rather than optional: no lock, no DAI.¹ It is a real, enforced, usage-triggered lock. It is also a demand sink for collateral assets, not for MKR. Anyone citing it as evidence that the governance token has structural demand has read the mechanism one layer too shallow.

Aave's Safety Module is the contrasting case. Staked AAVE sits as a backstop for shortfall events and is subject to slashing, so the required asset and the native token are the same thing.² That is what a demand sink on the native token looks like when it is real: a role the protocol needs filled, an asset it specifies, and a consequence for the holder if the thing they are insuring goes wrong.

So run the question on your own design. Name the mechanism, name the asset it demands, and check whether they match. If your answer requires the phrase and the token could be used for that, you have found a preference, not a requirement.

Strength is measured by what happens when the price moves

An inelastic demand sink keeps pulling buyers in as price rises, because the activity it gates is worth more to them than the token costs. An operator under contract to deliver service still has to post the bond. A borrower still has to over-collateralise. The cost went up and the requirement did not move.

An elastic one collapses on the way up and on the way down. Liquidity mining is the standard example: participants are there for a return, and they leave when the return stops clearing their opportunity cost. Framing that as demand for the token confuses a rented balance sheet with a resident one.

There is a real argument in the literature that this, and not velocity, is the actual problem with most payment-style tokens. Kevin Xu's critique makes the case directly: for many proprietary tokens the deeper issue is that nobody has a structural reason to hold, which is a demand-design failure rather than a velocity failure.³ We think that framing is right, and it puts the burden where it belongs, on the mechanism rather than on the holding period.

Demand for the service is not demand for the token

A protocol can grow beautifully and pass none of that growth to its token. Users pay in stablecoins, the front end abstracts the token away, and volume climbs while the only people acquiring the token are speculators and the team's market maker. Nothing is broken in the product. The connection was simply never built.

This is the point where tokenomics stops being a mechanism exercise and becomes a business question. If the underlying business does not create something people must transact with, hold against, or be bonded into, no demand sink can be retrofitted that users will not route around. The token is infrastructure for the business. It does not substitute for one, and across the 100+ projects the firm has worked on, the models that fail this test fail it at the product layer rather than at the contract layer.

Where the answer is that no such point exists, the correct output of a design engagement is sometimes that the token should be smaller in the architecture than the deck assumed, or absent from it.

The sentence we make teams write

One sentence, filled in with no adjectives: on a given day, this named party must acquire this many tokens in order to do this specific thing, and cannot do it otherwise. If every blank fills in, you have a demand sink and you can size it by counting parties. If the last clause fails, because the thing can be done another way, you have an incentive, and incentives are priced by whoever you are competing with for that capital.

Then estimate it the boring way. Number of parties, obligation per party, frequency of the obligation, and the rate at which parties leave. That gives you a demand figure you can defend in a diligence call, and it is a different order of evidence from a chart with an arrow on it.