Every crypto risk pack I have seen cuts the book by asset, by chain, and sometimes by sector. Very few cut it by the regulator standing behind the venue where each position can actually be sold. That omission is not cosmetic. The position sheet records what you own; the exposure that matters in a delisting event is where you are able to leave, and those two are not the same map.
The concentration is easy to miss because it hides behind apparent diversity. A book of twenty names spread across five venues looks diversified on a venue cut. Roll it up by the regulatory home of the operating entity behind each venue and it can collapse into two buckets, with most of the tradable depth in one of them.
The exposure that does not show up on a position report
Liquidity for a mid-cap token does not distribute evenly across the venues that list it. It concentrates, usually on one book, and the rest of the listings are decoration you cannot exit through in size. So the relevant question is not how many venues list the name. It is what fraction of the depth you would actually use sits under a single policy regime.
The delistings stream shows you what a single-regime event looks like when it fires. On my capture the stream was displaying 100 of 100 rows, and every visible row carried a Binance chip with a type of ANNOUNCEMENTS_DELISTING. The names ran SYS, PHB, MLN, FARM, ATA, AI, AEUR and XLM, with dates clustered on 05/27/26 and 05/22/26. That is nine pairs retired by one venue in two batches inside a week.
Nothing about that is scandalous. Venues prune books constantly and most of these are ordinary housekeeping. The point is the shape. One decision maker, one policy review, many rows. If your book held four of those names and your depth in all four was on that venue, you did not have four independent exposures that week. You had one, and it resolved on a date you did not choose.
The ledger gives you venue, and you supply jurisdiction
Be clear about the boundary here, because it determines how much work this is. The Exchange Listings Ledger carries Symbol, Name, Pair, Exchange, Type, Chain, MCap, Volume, Liquidity, Conf%, Date, DEX and Trade. There is no jurisdiction column, no entity column, and nothing that ranks or groups venues by regime. The filter row above the table offers All Chains, All Exchanges and All Types, so you can slice by venue but not by who supervises it.
So the mapping table is yours to build and maintain. Four columns are enough to start. The venue brand as it appears on the row. The legal entity that actually faces your account, taken from your own account agreement rather than from the marketing site. The jurisdiction that entity operates under, sourced from that venue's own terms and entity disclosures. And the date you last checked, because entity structures change and nobody sends you a note.
Two traps live in that second column. The first is that a brand is not an entity. The same brand routinely serves different legal entities to clients in different regions, and the one on your agreement is the one whose policy binds your withdrawal. The second is that spot and derivatives frequently sit in different entities under the same brand. The listings ledger makes that visible in a small way, since the Exchange chips distinguish MEXC Futures and Asterdex Futures from Hyperliquid Spot and Kraken, and those chips are your prompt to check whether one row and another actually face the same counterparty.
Rolling up on depth rather than on notional
Run the roll-up twice, because the two versions answer different questions and a desk needs both.
The notional roll-up answers how much of the book is exposed. Sum position value by jurisdiction bucket and express it as a percentage of NAV. This is the number that goes in the risk pack, and it is the easy one.
The depth roll-up answers how much of the book can actually leave, and it is the one that binds. For each position, take the venue where you would realistically liquidate, attribute that position's full value to that venue's jurisdiction, and then express the bucket as a share of the portfolio you could exit inside your target window. A name that trades on four venues but has one usable book is one hundred percent concentrated for this purpose, no matter how the venue count looks.
Here the ledger's own gaps matter operationally. On the delisting rows in my capture, MCap, Liquidity and Conf% were dashes and only Volume carried a figure, and the spread on that figure was enormous, from 112.90 M on the XLM row down to 86.51 on the FARM row and 5.91 on the AI row. The consequence is that the announcement row will not tell you how deep the book was before the notice landed. Your depth estimate has to be standing data you were already collecting, refreshed on a schedule, because the day you need it is the day it stops being measurable.
Writing a limit that actually binds
A concentration clause that says the desk will monitor jurisdictional exposure does nothing. Three properties make one bind.
- It is measured on the depth roll-up, not the notional one, and it is computed at a stated frequency with the calculation stored. Monthly measurement on a book that turns over weekly is theatre.
- It has a number and a consequence. A form that works is a cap on the share of exitable NAV in any single jurisdiction bucket, with a breach triggering no new adds in that bucket and a reduction over a defined number of sessions. Pick the number to fit your mandate. What matters is that the breach path is written before the breach.
- It names who can override and what the override costs. Overrides are legitimate and frequent. Undocumented ones are what a review destroys you over.
The sizing consequence is worth stating in advance so it is not a surprise. If the limit binds, the marginal name in a crowded bucket has to be smaller than the same name would be in an empty bucket, which means jurisdiction becomes an input to position sizing rather than a report you read afterwards. Desks resist this because it feels like a constraint on stock selection. It is a constraint on liquidation, which is the only kind of constraint that shows up in a bad week.
Four things that break the map
The first is treating on-chain liquidity as diversification. The DEX column on the ledger flags rows with an on-chain route, and that route genuinely does sit outside any venue's policy. It also has its own failure modes and its own depth ceiling, and it is only diversification to the extent you can route real size through it. Test that with an actual simulated exit before you count it.
The second is counting a perp as an exit for spot on the same venue. It is a hedge, not a liquidation, it does not remove the balance, and it usually faces the same entity that just changed policy.
The third is assuming different jurisdictions imply independent decisions. Venues copy each other's listing standards and respond to the same headlines, so policy correlation runs well above jurisdictional correlation. Your jurisdiction map is a lower bound on the concentration, not a measure of it. If you want the real number, look at whether the same names have historically been retired within days of each other across supposedly independent venues.
The fourth is letting the map go stale. Put a review date on every row and treat an unchecked entity older than a quarter as unmapped, which means it consumes the most concentrated bucket until someone proves otherwise. That is a conservative default and it is the only one that survives a year of neglect.