Methodology

The board is one table, rebuilt every few minutes from the research engine behind it. Each row is a measurement of one live Pendle points market: points exposure per dollar deployed, TVL and how it moved over the last day, when the season and the market end, the airdrop and TGE dates the programme has published, and each blocker the engine found on that route.

A row measures a route. It is not a view of the project behind it. Each figure on it is also a field in the JSON, though not always under the column's heading — Pts/$ is published as points_per_usd — so anything the page shows can be checked against the payload it was built from.

A dash means not measured, never zero. The distinction holds in the payload too: a field nobody measured is null, and a field that was measured and came out at zero is published as zero. Dates marked with a tilde are estimates rather than dates a programme has published.

Where a row's campaign facts come from is published beside them. Each row carries a list of sources for its campaign — the multiplier, the snapshot date, the TGE date and the airdrop status — each with when the observation was made and, where it has one, the address it can be checked at. An empty list means nobody has recorded a source for that row's campaign, and it is not a claim that none exists. The payload's top-level sources list is a different thing under a similar name: it is collector health, saying which public collectors ran, how they finished and how long ago.

The page states its own age. When data stops landing, a banner says so instead of the numbers pretending to be current.

Rows arrive in score_v1 order, with flagged rows at zero and last. score_v1 is the row's ranking total, and it can be reproduced from the payload: each input it reads is a published field in the same row, so the order rebuilds from what is published. That order can change again.

The total is the sum of the contributions published beside it as score_factors. Exposure is the dollar-days-of-exposure contribution. Certainty is the airdrop-status contribution. Timing is the soonest-deadline contribution, the tightest of its clocks, because the first deadline that bites is the one that matters. Crowding is the dilution-relief contribution, which falls as capital flows into the pool. Integrity is the no-blocker contribution.

On any row that is not flagged, the contributions sum to score_v1. That is a consistency property between two published numbers and nothing more: it cannot tell you a weight is right, only that the breakdown adds up to the total shown. A contribution whose input is missing prints as a dash and adds nothing, which is a different claim from one that was measured and came out small.

Flagged rows are not ranked — they get zero and sit at the foot. A row carrying any danger flag keeps its full breakdown, so the zero explains itself.

The weights were set rather than fitted to how any market turned out, and the function that applies them is named in the payload as score_version. A change to a weight, a factor or a threshold is published as a new version, not made silently to the order. The version and the payload's own shape can move apart.

It ranks; it does not say what a market will pay. Its heaviest term compares exposure per dollar across programmes whose emission rates are different unknowns. Between two markets of the same farm the unknown cancels and the comparison is real. Between two farms it divides by two different unknowns, and the order makes that comparison anyway.

The same is true across the two kinds of Pts/$ figure. A figure with a reported multiplier and a dagger figure without one are the same expression in different units, and the order ranks them together. So read the order as one way of laying out the table, not as a like-for-like comparison between programmes. Sort any column to replace it, or rebuild a ranking from the published fields for the comparison you are making.

The API documentation — every published field, the ranking's inputs and its breakdown among them.

Pts/$ is points exposure per dollar deployed: a market's points multiplier divided by the share of the underlying that one YT costs. A YT costs a fraction of the underlying it is entitled to, so a dollar of YT is exposure to more than a dollar of underlying, and the column measures how much more.

A figure marked with a dagger has no reported multiplier behind it, so it is that price leverage alone — how much exposure a dollar buys, not how many points. Compare a dagger figure only with another dagger figure.

Pts/$ is not an APY, and no points emission rate exists anywhere in this data, so nothing here is per day. It cannot be turned into a value per point either. Compare it only between markets of the same farm: two programmes' points are different things sharing a name.

Carry is the other side of that number. A YT decays to zero by maturity, so Carry is what one year of holding costs at today's price, annualised from the days left and stated per dollar of underlying notional. It is gross: no strategy relief is netted off it. It also excludes gas and slippage, which depend on your size and not on the market.

Break-even is the same cost read from the rewards side: the yearly rate at which rewards must accrue, on the underlying notional, for the position to break even. It is the gross carry divided by the points multiplier, so the two are separate numbers. They coincide only where no multiplier was reported or the reported one leaves the division unchanged. Break-even is a required accrual rate and never a price per point.

The payload publishes the underlying yield a YT holder is entitled to beside the carry, on the same basis, and none of it is netted from Carry. The difference between the two is the net annual cost of the position. Do not subtract the yield from Break-even instead: that hurdle is already divided by the multiplier, so taking the raw rate off it overstates the relief by exactly the multiplier.

Inside one day of expiry too little of a year is left to annualise. The board withholds Carry and Break-even there and prints a dash, which means not measured, never zero. A market that could not be priced gets the same dash for a different reason.

How to read Pts/$ — the exposure figure, worked through.

The cost of carrying a YT — Carry and Break-even, worked through.

A blocker can rest on a campaign field whose default reads exactly like a finding. The airdrop status is such a field. It defaults to none, so a campaign nobody has researched reads identically to one researched and found to have none. A status of none is a statement about the record, not about the programme, and this site does not read it as a programme having no airdrop.

Where a blocker rests on a field like that and nobody has recorded a source for it, the board still flags the row but does not publish the sentence that would explain the flag, because that sentence would present a default as a finding. A row in that state is flagged on a field nobody has recorded — not on a finding.

The JSON shows the same thing without the page. The flags list names each code that fired, flags_text carries one sentence per code minus the withheld ones, and the row's sources list shows what is backed. An empty flags_text is therefore not an all-clear.

The status hubs list the rows filed under each airdrop status that has a hub, so the rows behind a status can be read there directly rather than counted on this page. Unknown, this site's own value for a market with no campaign linked, has no hub, so a row carrying it is on none of them.

The board also marks a market that matures before its programme's season ends. What that does to points is not recorded, and the site does not guess. Where a market matures before its season ends, nothing on record says whether points still count — check the programme.

The airdrop status hubs — the rows filed under each recorded status.

The order is not advice, not a rating of any project and not a forecast. It is a set of measurements of published fields put in a stated order, and it says nothing about what a market will pay.

This site does not say what a point is worth. Valuing a point needs three facts about the same programme: how many tokens it will distribute, what one of those tokens costs, and how many points exist in total. The site publishes exposure and cost and leaves the valuation to you.

Points from two programmes cannot be compared either. A point is counted in its own programme's units, so one project's point and another's are different things with the same name, and no figure here converts between them.

It does not say whether a position will clear its hurdle. No points emission rate exists anywhere in this data, so nothing here turns a points count into a rate, and Break-even stays a hurdle rather than a forecast.

And it is not a wallet connection or a place with accounts. Nothing is behind a login. What it publishes is a set of measurements, each one a field in the JSON, documented field by field in the API documentation. Some are also columns on the board and some are not: the underlying yield is in the JSON and not on the board.