The standard treatment of a token unlock is to read the headline tranche size, divide by circulating supply, and hedge some fraction of a locked allocation against the resulting percentage. It is fast, it is defensible in a meeting, and it is almost always wrong by a factor large enough to matter, because it assumes every recipient of the tranche behaves identically.
They do not, and the difference is observable in advance. A venture tranche unlocking to wallets that have moved every prior tranche to an exchange within a week is a different supply event from a foundation tranche unlocking to a multisig that has never sent to a venue. Treating them as one number throws away the only information the chain gives you for free.
An unlock is a set of decisions, not an event
Start by refusing the aggregate. The vesting contract, or the schedule the project published, defines a set of recipients and a quantity for each. Group those recipients into classes that share an incentive: early investors at one cost basis, later investors at another, team and advisor allocations, foundation or ecosystem reserves, and market maker inventory, which behaves differently again because it is usually a loan with its own return conditions.
Each class gets its own expected sell fraction. The tranche's contribution to real float is the sum of quantity times sell fraction across classes, not the headline. Everything else in this piece is about estimating those fractions honestly and turning them into a hedge you can defend afterwards.
Getting the recipient set before you open any feed
The order matters. You define the recipient set from the vesting contract first, then you watch those specific addresses. The reverse order, scanning a whale feed and hoping the relevant wallets surface, does not work, and the Whale Feed capture shows exactly why.
Two constraints from that screen carry straight into the method. The observation threshold is a floor you choose, and any behaviour below it is invisible rather than absent, so record the threshold you observed at as part of the estimate. And the universe of a generic whale surface is whoever the vendor tracks, which will not automatically include the twelve addresses in a vesting contract you care about. Add them explicitly, watch them individually, and treat any feed that cannot accept a supplied address list as a monitoring tool you cannot use for this job.
Turning prior cliffs into a sell fraction per class
The only sample worth fitting is the prior cliffs on the same schedule, because those share the recipients, the cost bases and the lockup terms. Cross-token averages of what unlocks usually do are a different population wearing the same word.
For each prior cliff and each recipient wallet, record five things. How much arrived. How much left the wallet within the first, fifth and thirtieth day. Where it went, split into venue deposit addresses, a DEX router, another wallet in the same cluster, or a custodian. Whether the wallet had done anything at all before the cliff. And the price path over the window, since a class that sold into a rally tells you less about a cliff arriving into a drawdown.
What you want out of that is a fraction per class with a horizon attached, of the form investors moved roughly seventy percent to venue deposit addresses within five days across the last two cliffs. Two observations is a thin sample and you should say so in the number rather than hiding it, which in practice means carrying a range instead of a point.
From expected float to a hedge ratio
Take a schedule with the following shape, entirely as an illustration of the arithmetic rather than as a description of any real token. A cliff releases 40 million units. Investors hold 22 million of it, team 12 million, ecosystem reserve 6 million. Prior cliffs on this same contract showed investors moving about 70 percent to venue deposits within five days, team about 15 percent, and the ecosystem multisig moving nothing at all and having never sent to a venue.
Expected float addition is 22 times 0.70, plus 12 times 0.15, plus 6 times zero. That is 15.4 plus 1.8, so 17.2 million units against a headline of 40 million. The event you should be hedging is 43 percent of the one the announcement describes. Hedging the headline is not conservative, it is a 2.3 times over-hedge that you pay funding on for the whole window.
Then convert. The hedge is not sized to your position, it is sized to the expected float addition measured against the market's capacity to absorb it, which means against realistic daily traded volume rather than headline volume, at the venues you could actually clear at. A tranche worth two days of real volume is a supply event. A tranche worth two hours of it is a headline. Your own exposure only enters at the end, as the cap on how much of that event you are choosing to insure against.
Because the sell fraction is estimated from a very small sample, hedge a percentile rather than a point estimate. Decide in advance, in writing, that you hedge to the upper end of your range, and state which end and why. That single pre-commitment is what stops the ratio being renegotiated in the week before the cliff by whoever is most anxious.
What the observation layer cannot see
Four gaps, all of which belong in the note rather than in a footnote nobody reads.
- Over the counter sales never touch an observable. A recipient who sold forward to a desk months ago shows zero on-chain movement and has already added the supply. Nothing in any wallet feed will show you this, and it is the single largest source of error in the method.
- Movement to a venue deposit address is not a sale. It is a wallet preparing to be able to sell. The two get conflated constantly, and the honest version of the fraction is moved to a position where selling is possible, which is an upper bound on selling.
- Recipients sometimes buy. A team wallet adding around its own cliff is a real signal and it points the other way, so build the estimate to allow negative contributions rather than flooring the fraction at zero.
- The market may already hold the view. Check perpetual funding and the basis in the weeks before the cliff. If the hedge is already crowded, you are paying to join a trade rather than to insure against one, and the carry cost of that is the whole decision.
What goes in the file
Write it down while you still believe it, because the review happens after the outcome and the outcome contaminates memory. The note carries the recipient set with full addresses and chains, the class assignment for each and the basis for that assignment, the per-cliff observations behind each fraction with dates, the observation threshold you watched at, the resulting expected float with its range, the market capacity figure and where it came from, the hedge ratio you chose with the percentile rule you pre-committed to, and the carry cost you expected to pay.
The question in the review is never whether the hedge made money. It is why you hedged 43 percent when the announcement said 100, and the only acceptable answer is a document written before the cliff that shows the arithmetic and names its own weaknesses. A hedge that was right for reasons you cannot reconstruct is not a repeatable process, and a hedge that was wrong for reasons you documented in advance is.