You deposit two tokens into a decentralized exchange pool, approve a contract, and receive liquidity-provider tokens in return. The interface displays an attractive annualized yield. Yet when you later withdraw, the amount of one asset is lower than expected, the transaction costs more than planned, or the quoted trade executes at a noticeably worse price. None of these outcomes necessarily means the protocol malfunctioned. They reflect different mechanisms that are often compressed into one misleading word: “yield.” Liquidity mining and yield farming can compensate users for supplying capital, but the return is inseparable from market risk, execution risk, smart-contract risk, and changing incentives. Slippage protection reduces one category of loss; it does not guarantee a profitable position. A useful mental model is to treat DeFi yield as compensation for making capital available under uncertainty, not as interest detached from risk. The first myth: a high APY is the same as a high return Liquidity mining usually means supplying assets to a protocol, commonly a decentralized exchange or lending market, and receiving rewards for doing so. In an automated market maker, liquidity providers place assets into a pool governed by a pricing formula rather than by a traditional order book. Traders pay fees, and the protocol may distribute additional tokens to attract liquidity. Yield farming is the broader practice of moving capital among protocols or positions to pursue rewards. A farmer might provide liquidity, stake the resulting receipt token, borrow against collateral, or deposit assets into another contract. Each additional step can increase the nominal yield, but it also adds another dependency. The displayed APY may therefore combine trading fees, token emissions, compounding assumptions, and volatile reward prices. The non-obvious point is that yield is not a single cash flow. Trading fees may be generated by real user activity, while token incentives may be funded by newly issued supply. Those sources behave differently. Fees can decline when volume falls. Emissions can lose value when recipients sell rewards or when incentives move to a competing pool. A high quoted APY may be economically rational compensation for a fragile position, rather than evidence of an unusually efficient opportunity. Impermanent loss is not simply a temporary inconvenience In a two-asset liquidity pool, the protocol generally rebalances the quantities held as prices change. If one asset rises sharply relative to the other, arbitrageurs trade against the pool until its internal price matches the wider market. The liquidity provider ends up holding a different mix of assets than the original deposit would have produced. This creates what is commonly called impermanent loss: the value difference between remaining in the pool and holding the original assets outside it, measured under a chosen price scenario. The term can be misleading. The loss is not guaranteed to reverse merely because time passes. It can diminish if relative prices return toward their previous relationship, but it can become effectively realized when liquidity is withdrawn or when the provider sells the resulting assets. Fees and incentives may offset this effect. Whether they do depends on volume, pool design, volatility, fee rates, reward-token value, and the duration of the position. A stablecoin pool has a different risk profile from a volatile asset pair, but even a pool marketed as stable can experience losses when assets lose their intended price relationship or when a contract fails. Slippage protection controls execution, not economics Slippage is the difference between an expected execution price and the price actually received. It arises because a trade changes the pool’s reserves, because other transactions are processed first, or because market conditions move while the transaction waits for confirmation. On-chain execution makes this timing visible: a quote is prepared off-chain or at a particular block state, but settlement occurs later. A slippage tolerance sets a boundary for the transaction. If the final output falls below the permitted minimum, the transaction should revert rather than execute at an unacceptable rate. This is valuable protection, especially in thin pools or during volatile markets. However, it is not a price guarantee. A tolerance set too tightly can cause repeated failures and wasted gas; one set too loosely can accept a poor execution. There is also a subtle distinction between price impact and adverse execution. Price impact is caused by the size of the user’s own trade relative to available liquidity. Slippage can additionally reflect intervening transactions, latency, or extractive ordering. Splitting a large trade, using a deeper pool, or choosing a better route may reduce price impact. Slippage protection limits the worst permitted result, but it does not make an illiquid market deep. Why transaction simulation matters before farming Yield-farming workflows often involve more than one transaction: approving a token, depositing assets, accepting a position, staking a receipt token, harvesting rewards, and later withdrawing. A wallet that merely displays a contract address leaves the user to infer the economic effect from raw calldata. That is a weak basis for a decision involving multiple permissions and assets. Transaction simulation improves the review process by estimating balance changes and showing contract interactions before signing. For a DeFi user, the important question is not only “Is this transaction going to succeed?” but also “What will I own afterward, which permissions am I granting, and what can change if the transaction is executed?” Simulation cannot predict every future state, and its result depends on the accuracy of the simulated environment. Still, it can expose mismatched tokens, unexpected transfers, or a deposit that does not produce the asset the user expected. Pre-transaction risk scanning adds a different layer. It may flag interactions associated with previously compromised contracts or suspicious addresses, but a warning system is not a substitute for protocol analysis. A legitimate new contract may have limited history, while a familiar contract can still contain an economic design that is unsuitable for a particular user. Security tooling helps with observable transaction risk; it cannot eliminate governance, oracle, liquidity, or market risk. For users managing positions across Ethereum and other EVM-compatible networks, rabby is designed around this