Every listing row in the exchange ledger carries a Conf% figure, and the column is sortable, which means somebody on your desk is already sorting by it. What almost never exists alongside that is a written statement of the number below which a row is not tradable. Without one, the confidence score functions as a mood indicator: high numbers make people comfortable, low numbers make people hesitate, and nothing about either reaction is recorded or reviewable.
The fix is not complicated but it does require being precise about what the score measures, because the most common failure I see is a desk treating it as a signal-strength number when it is a data-quality number, and those two things call for opposite responses at the margin.
What the column is a probability of
The listings ledger cross-references exchange announcements with on-chain liquidity and attaches a confidence score to each match. So the quantity being scored is the match. Given an announcement naming a symbol on a venue, how confident is the pipeline that the chain, pair and contract attached to that row are the same asset the exchange is talking about.
That is a statement about identity, not about outcome. A row at very high confidence is a row where the ledger is close to certain it has resolved the right asset. It says nothing about whether the listing is significant, whether the venue matters, whether the price has already moved, or whether the position is a good idea. A perfectly resolved match to an asset nobody should trade is a high-confidence row.
This matters because the two interpretations imply different threshold behaviour. If confidence were signal strength, a low score would mean a weak trade and the right response would be a smaller position. Because confidence is identity, a low score means you may be about to trade a different asset than the one in the announcement, and the right response is not a smaller position. It is no position until the identity is resolved by hand.
The screenshot shows the problem in the layout itself. Conf% is rendered as one more numeric column in a row of numeric columns, sitting beside market cap, volume and liquidity. Those are properties of the asset. Conf% is a property of the pipeline's belief about which asset it is. Nothing on screen distinguishes the two, so the distinction has to live in your policy.
Deriving a cutoff from the cost ratio
Do not set the threshold by looking at the distribution and picking a round number that keeps a comfortable quantity of rows. That method optimises for having enough to do. Set it from the relative cost of the two errors.
A false positive is trading a row where the match was wrong. You have bought an asset that is not the one the announcement referenced. The loss is not marked to a bad thesis, it is marked to a wrong instrument, and the recovery path is bad: you are holding something with no catalyst, usually thin, and often on a chain where your exit routing is untested. Worse, the position was sized as though the catalyst applied.
A false negative is skipping a row whose match was actually fine. The cost is the foregone event, which for most listing strategies is a modest expected contribution, plus nothing else. There is no tail.
Write the ratio down explicitly. If your desk's view is that a wrong-instrument trade costs roughly ten times what a missed event costs, then you should be willing to skip on the order of ten legitimate rows to avoid one bad match, and your cutoff belongs high. If it is closer to two, the cutoff comes down. The point of doing this on paper is that the ratio is a judgement your investment committee can debate once, whereas a bare threshold number is a judgement nobody can interrogate.
The verification that promotes a row
A gate with no override is a gate people route around. The threshold needs a documented promotion path, and it should be a genuine verification rather than a second opinion.
- Resolve the contract address independently of the ledger. Go to the venue's own announcement and take whatever identifying detail it publishes. If it publishes a contract, that is the anchor and the check is a string comparison.
- If the venue publishes only a symbol and a project name, resolve through the project's own published channels to an address, and record which source you used. A resolution whose provenance is not recorded is not a verification, it is a guess with more steps.
- Check the chain field explicitly rather than assuming it. An asset deployed on several chains has several addresses, and the announcement may or may not specify which one the venue is crediting.
- Check for a wrapped or bridged version. A wrapped representation is a different instrument with different liquidity and a different exit, and it will happily match on symbol.
- Record the outcome on the row: verified, verified with the address corrected, or could not resolve. The third outcome is a legitimate result and should be common enough that people believe it is available.
Two rules keep this honest. The verification is done by someone who is not the PM asking for the promotion, and the promotion applies to that row only, never to the symbol in general. If the same symbol appears again next week on a different venue, it gets verified again, because the thing that failed was the match, and the match is per row.
Sizing and documentation for promoted rows
A promoted row is not equivalent to a row that cleared the gate on its own, and pretending otherwise loses you the ability to measure whether the promotion process works.
Tag it. The position record should carry the original confidence, the fact of promotion, the verifier, and the source used to resolve the address. That costs about ninety seconds at the time and it is the only way you will ever be able to answer the question an allocator eventually asks, which is whether your manual overrides add value or destroy it. If promoted rows underperform gate-clearing rows over a meaningful sample, the promotion path is a leak and you should raise the threshold rather than defend the process.
On sizing, I would not reduce size on a promoted row. That instinct comes from the signal-strength reading of the column and it is the wrong response. Either the identity is resolved, in which case the asset is the asset and normal sizing applies, or it is not resolved, in which case there is no size that is appropriate. Half a position in the wrong instrument is not risk management.
Moving the threshold without inventing a new one each quarter
The threshold should be versioned and dated like any other risk parameter, and it should move for a stated reason. Two reasons qualify. The first is a change in the cost ratio, which usually means a change in strategy size, because a larger book makes a wrong-instrument position harder to exit and pushes the cutoff up. The second is a measured change in the pipeline, which you can only detect if you have been logging verification outcomes.
That log is the asset here. Every promoted row produces a data point about whether the ledger's score was too low for the row's actual quality, and every gate-clearing row that turned out to be mismatched produces a much more important one in the other direction. A quarter of that logging tells you more about where your cutoff belongs than any amount of reasoning about the distribution, and it converts the threshold from a preference into a documented control with evidence behind it.