Three primitives, everything else is a combination
Swapping, lending and providing liquidity. A swap exchanges one token for another against a
pool rather than an order book. Lending deposits an asset for others to borrow against
collateral. Providing liquidity supplies the pool a swap trades against, in return for a share
of its fees.
Everything with a more elaborate name is these three arranged differently, sometimes several
layers deep. That layering is genuinely powerful and it is also where risk compounds, because
a product built on three protocols inherits the failure modes of all three.
-
Swap
Trade against a pool holding both assets. The price comes from the ratio in the pool, so a large trade moves it. That movement is slippage, and it is the cost that scales with size.
-
Lend
Deposit an asset, earn interest from borrowers who post collateral worth more than they take. If collateral falls below a threshold it is liquidated automatically, which is what keeps the system solvent.
-
Provide liquidity
Supply both sides of a pool and earn a share of trading fees. You also take on impermanent loss, and whether the fees cover it depends entirely on how much the two assets move relative to each other.
Reading a yield figure
Ask where the money comes from. Fees from real usage are sustainable and usually modest.
Interest from borrowers is real and varies with demand. Newly minted tokens distributed to
participants are dilution, and a figure built mostly from them describes an emission schedule
rather than a return.
The tell is size. A double-digit yield on a stablecoin, in a world where conventional rates
are much lower, is not a market inefficiency somebody left lying around. It is either
compensation for a risk that has not yet materialised, or it is token issuance, and both have
a way of resolving suddenly.
The three failure modes
- Contract bugs: funds drained through the code
- Oracle manipulation: the price feed is attacked, not the contract
- Governance capture: whoever can upgrade, can take
Signals worth checking
- Who holds the upgrade key, and is it a multisig
- Whether there is a timelock before changes take effect
- Which oracle is used and how many sources it aggregates
- Whether deployed code matches the audited version
The step where users actually get hurt
Most individual losses in this area do not come from a protocol failing. They come from the
approval step: before a contract can move your tokens, your wallet grants it permission, and
that permission persists until you revoke it. A malicious contract approved once, usually through a link that imitated a real interface, can wait, then empty the balance in a single
transaction months later.
The defence is procedural rather than technical. Reach interfaces through addresses you have
recorded yourself, grant approvals for specific amounts where the wallet allows it, and review
standing approvals occasionally the way you would review direct debits. It is unglamorous, and
it removes the failure mode that produces most of the individual-scale losses.
Impermanent loss, which is badly named
Supplying two assets to a pool earns a share of trading fees, and the headline yield usually
quotes those fees alone. Sitting against them is an effect that the standard name actively
obscures. As the price of one asset moves relative to the other, the pool rebalances by selling
the one going up and buying the one going down, so a depositor ends up holding less of the
winner than if they had simply kept both.
Impermanent describes the fact that the gap closes if the price returns to where it started.
It does not, in any sense, mean small or temporary. Withdraw while the prices have diverged and
the loss is realised in full, and for a volatile pair it can exceed everything the fees paid.
The consequence is that a pool yield is not comparable to an interest rate, though it is almost
always presented next to one. An interest rate is the return. A pool yield is one side of a
position whose other side depends on where two prices go. Pools of two assets that track each
other closely reduce the effect sharply, which is why stable pairs pay less and why the
difference between the two figures is doing more work than it appears to.
What decentralised actually describes
Rarely the whole system. A protocol can have permissionless usage and a single key controlling
upgrades, an open interface and a front end hosted by one company, on-chain settlement and an
off-chain price feed run by a foundation. Each of those is a point where somebody specific can
act.
This is not hypocrisy; building otherwise is genuinely hard. It does mean the label carries
much less information than it appears to, and that the useful question is always
“decentralised in which respect, and who is left holding the keys”.





Be the first to comment