An exchange publishes an announcement. It contains a symbol, usually a project name, a venue, a pair, and a date. What it very often does not contain is the one field your execution stack requires, which is the address of the contract you are supposed to buy. Every listing feed in existence has to close that gap, and the way it closes it is the single largest source of silent error in listing strategies.
The listings ledger cross-references announcements with on-chain liquidity and attaches a confidence score to each match, which is the right architecture: it makes the resolution explicit and gives you a number to gate on. But a score is a summary of a process, and a desk that trades listing events needs to understand the process well enough to redo it by hand when the score is low and to disbelieve it when the score is high for the wrong reason.
Why a symbol is not an identifier
Ticker symbols in equities are governed. Somebody issues them, they are unique within a venue, and there is an authoritative mapping to a security identifier. None of that is true of token symbols. A symbol is a string field set by whoever deployed the contract, there is no registry, and there is no cost to choosing one that is already in use.
That means the symbol in an announcement is a label with an unknown number of referents. Resolution is the work of reducing that unknown number to one, and the reason it is hard is that the announcement is usually written for humans who already know which project is meant, so it omits precisely the disambiguating detail a machine needs.
The view above is the one worth working from when you are auditing resolution rather than trading. Running all three streams together means an announcement, a live listing and a delisting for the same underlying asset land in the same table, and if the resolution is inconsistent across those rows you will see it. If you only ever look at one stream, you will not.
The five ways a symbol resolves to the wrong asset
These are worth enumerating because they need different fixes, and a pipeline that treats them as one problem will handle at most two of them.
- Straight collision. Two unrelated projects deployed contracts using the same symbol. Neither is fraudulent, and the more generic the symbol, the more likely this is. Resolution has to come from something other than the symbol string.
- Deliberate impersonation. A contract deployed to share the symbol of a project that is about to be listed, specifically so that automated matching and search find it. This one is adversarial and it targets exactly the moment your desk is in a hurry.
- Empty or wrong chain field. A multi-chain asset has an address on each chain and they are different instruments with different pools. An announcement that does not name the chain, or a ledger row where the chain field is blank, leaves the resolution genuinely undetermined rather than merely uncertain.
- Wrapped and bridged representations. The canonical asset and its bridged version on another chain share a name and usually a symbol. They have separate liquidity, separate exit routes, and separate risk. A match to the wrong one is not a small error.
- Redeployment. The project migrated to a new contract. Both addresses exist, the old one may still have a pool, and a matcher working from historical data will find the stale one first because it has more history attached.
Note what these have in common. In all five cases the wrong answer looks correct in every field you would casually check. Symbol matches, name matches, there is a pool, there is volume. The error is only visible if you go to a source that the matcher did not use.
A resolution order that terminates
The procedure below is ordered by the authority of the source, and it is written to terminate rather than to keep looking until something plausible appears. Terminating is the important property, because an unbounded search always finds a candidate.
First, the venue's own announcement. If the exchange publishes a contract address, that is the anchor and resolution is a string comparison, done. This is the only step that produces certainty and it is worth checking every time even though it frequently fails.
Second, the venue's asset page or deposit instructions for the listed asset. A venue that takes deposits has to tell depositors which network and which contract, and that information is often available even when the announcement itself is vague. It is the venue's own statement about which instrument it means.
Third, the project's own published channel, treating the project as authoritative about its own contract. Record which channel you used. A resolution whose source is unrecorded is not a resolution, it is a recollection.
Fourth, and only if the three above fail, an on-chain reconciliation. Deployment date consistent with the project's history, liquidity concentrated where you would expect, and a holder distribution that is not obviously fresh. This step produces a candidate, not an answer, and it should be tagged as such.
If you reach the end of the fourth step without a single surviving candidate, the correct outcome is unresolved, and unresolved means untradable. Desks that do not permit an unresolved outcome are not eliminating the error, they are pushing it into an analyst's judgement under time pressure and then not recording that it happened.
What the resolution record has to contain
The output of this work is not an address. It is a record, and the record is what makes the trade defensible afterwards. Six fields, and none of them are optional.
The address itself and the chain, together, because neither is meaningful alone. The source that produced them, named specifically rather than as a category. The timestamp of the resolution, since projects migrate and an address that was correct last quarter may not be now. The identity of the person or process that did it. The confidence figure the ledger carried on the row at the time, which is the input you are overriding or confirming. And the outcome class: resolved from venue, resolved from project, resolved on chain, or unresolved.
That last field is what lets you audit the pipeline later. If a disproportionate share of your losing listing trades resolved on chain rather than from the venue, you have learned something specific and actionable about where your process is weak, and you can raise the bar for that class without touching anything else.
Making the work compound instead of repeating
Every resolution you perform is an asset you will otherwise throw away. Keep an internal alias table mapping symbol and chain to the resolved address, with the resolution record attached, and check it before starting the procedure.
Two constraints keep the table from becoming a liability. Entries expire, because redeployment is real and a stale alias is worse than no alias. And a hit in the table shortens the procedure without skipping it: you still confirm the venue is talking about the same chain, because the table tells you what the asset was last time and not what this particular announcement means.
The other thing worth capturing is the collision set. When you resolve a symbol and discover three other contracts sharing it, record all four. The next time that symbol appears, the useful knowledge is not which one you picked, it is that the symbol is contested at all, which should raise the standard of proof before anyone sizes a position on it.