New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
BTCJP's early DeFi notes follow more than one kind of token. A user deposits assets, receives a pool token, may place that receipt into another arrangement and later withdraws through the sequence in reverse. The old notes are short, but their changing token labels capture an important accounting idea: one displayed position can depend on several distinct claims. This new guide follows that idea with a simplified hypothetical pool. Its figures are arithmetic examples, not historical market data or return forecasts. Protocol versions differ, so the exercise is a method for reading records rather than instructions to use an archived application.
Name the assets and the receipt separately
A pool deposit changes several records. Assets leave one account and become part of a pool's holdings, while a receipt represents the participant's interest under the pool's rules. Uniswap's v2 documentation describes liquidity tokens and their relationship to deposited liquidity. That is a specific mechanism, not a statement that every protocol uses the same representation. Begin a research note with the network, pool identifier, underlying assets and receipt contract. Reusing one ticker for all four concepts makes later reconciliation unnecessarily difficult, especially when an interface groups them under a convenient product name.
In a hypothetical pool, call the underlying assets A and B and call its receipt R. These are teaching labels, not token recommendations. Record the quantities of A and B submitted, the observed receipt quantity and the transaction linking the events. If the interface shows a fiat value, keep that separate from the asset quantities. A changing price can alter the displayed value without an additional deposit or withdrawal. The notebook needs to preserve what moved and what was issued, not only the headline value visible after the transaction completed.
Calculate the share with its denominator visible
Suppose a simplified hypothetical pool has 100 receipt units outstanding and one participant holds 10. That represents a ten-percent share under the example's proportional rules. If another participant adds liquidity and the system issues additional receipts appropriately, the original participant's fraction of the enlarged total may change even while the value represented by its existing position need not be reduced by that deposit alone. The numerator and denominator must be read together. A receipt balance by itself does not describe the complete pool or the participant's claim on its current holdings.
Write the observed total supply and pool holdings beside the participant's receipt quantity. Then state which block or observation time supplies those values. Mixing a current receipt balance with an older total supply can create an apparent discrepancy that is actually a timing problem. The calculation should be reproducible from one coherent observation. This is a modest requirement, but it prevents several common errors: treating receipt units as units of an underlying asset, ignoring changes in the total and interpreting a locally formatted number as a complete account of ownership in the pool.
The underlying mix can change without a new deposit
Trading can change the pool's holdings of its underlying assets. A proportional claim can therefore refer to a different mix at withdrawal from the mix initially deposited. Fee accumulation can matter too. The participant needs an account of the pool's mechanism rather than an assumption that the receipt is a fixed package containing the original quantities. This distinction is central to interpreting a screenshot taken after activity has occurred. A stable receipt count is not evidence that every quantity represented by the receipt remained unchanged during the same period.
Uniswap's v2 returns discussion also distinguishes fee income from the outcome of simply holding the underlying assets. A research comparison should therefore define its baseline. Is the question how many units can be withdrawn, what their marked value is or how that value compares with a separate holding scenario? These are different calculations. A hypothetical exercise can compare them without predicting which will outperform in a real market. The useful result is a transparent account of quantities, prices, fees and the comparison being made, rather than one unexplained number labelled profit.
Staking the receipt creates another layer to reconcile
The BTCJP liquidity-mining note describes placing an LP receipt into a further reward arrangement. At that point, the wallet's directly visible receipt balance may fall while an application records a position on the participant's behalf. The underlying pool and the reward arrangement are separate systems. To understand the combined position, follow the receipt to its new location and identify the record used to track the participant's interest. An empty receipt balance in the wallet is not, alone, proof that the underlying pool claim has disappeared.
Extend the hypothetical labels: R is deposited into a reward arrangement S. Record the R transfer, the S position and any reward asset separately. A reward claim is not necessarily a withdrawal of R, and withdrawal of R is not necessarily redemption of the underlying A and B. These distinctions can be obscured by interfaces that put claim, withdraw and exit near one another. A laboratory note should explain which record each action changes. That gives a later reader a way to reconcile the sequence without guessing from the button's general English meaning.
Trace the exit in the order the claims unwind
A full exit may require more than reversing one transaction. In the hypothetical example, the participant first recovers R from S, then redeems R according to the pool's rules to receive the relevant underlying assets. Any separately claimable reward is another record again. The actual sequence depends on the implementation; some interfaces can combine actions while others expose them individually. The key is to identify the state transitions and their prerequisites. A convenient combined button does not make the underlying accounting layers cease to exist.
The archived Curve-related note is particularly clear about seeing an LP token before returning to the desired underlying token. Preserve that observation as a historical workflow, not as a current instruction to visit an old URL. A modern test should determine the applicable contracts and current mechanism independently. Then reconcile the quantities at each boundary and record any transaction that failed or remained incomplete. This makes a partial exit understandable: the participant can identify which claim remains held and which action has not yet completed, rather than treating the entire process as one missing balance.
Keep an accounting trail, not only an APY screenshot
A useful pool notebook contains the initial asset quantities, receipt quantity, pool reference, total-supply observation, additional staking record and final withdrawal quantities. Fees and any valuation assumptions belong alongside those observations. An advertised rate can provide context, but it cannot replace this trail. The rate may describe a different observation window or reward unit from the participant's actual experience. Reconciliation starts from the records that changed, not from a percentage copied from the application's front page at the beginning of the experiment.
Read the BTCJP notes as compact records of a period when these layered interfaces were being explored. Their enduring lesson is to follow the receipt. Distinguish underlying assets from pool shares, pool shares from an additional staking position and all of those from rewards. Keep the denominator, observation time and valuation basis visible. This produces an explanation that remains useful when interfaces and incentives change: a position is a set of identifiable claims with an accounting path, not a single attractive number that can be understood independently of the records supporting it.
Technical references
From the recovered archive
- DeFi: Uniswap V2 · captured 2 March 2021
- DeFi: Uniswap, liquidity mining, Liquidity provider rewards · captured 2 March 2021
- liquidity mining: Curve Finance sUSD LP Token (Synthetix) · captured 2 March 2021