Nadine Chakar runs digital assets at DTCC, the clearinghouse that settles more securities value than any institution on earth. In a July 20 post on X, she said even DTCC can’t do that job in real time: it nets roughly 98% of the value it clears every year, because there isn’t enough money “intergalactically” to settle four quadrillion dollars gross, in real time, every single day. It’s a clean, quotable number, and it reads like a closing argument. If the largest clearinghouse on the planet says real-time gross settlement doesn’t add up, the logic seems to extend cleanly to real-time settlement generally: netting is the only thing that scales, and anyone promising instant finality hasn’t done the math.
That’s the reading worth pushing back on. The math is right. The conclusion being drawn from it isn’t. Chakar is describing what happens when a fixed set of institutions trade the same securities back and forth all day. She isn’t describing what happens when someone pays for a coffee. Conflating the two is how “netting versus real time” ends up treated as one settlement debate, when it’s actually two different problems wearing the same name.
What DTCC is actually solving
DTCC’s netting works because its counterparties are known, few, and constantly trading with each other. A relatively small set of banks and broker-dealers exchange securities all day, and by day’s end, most of what they owe each other cancels out. Only the net difference has to move. That’s what 98% netting efficiency means in practice: for every $100 in gross trading activity, roughly $2 actually settles. Force that same activity through real-time gross settlement, where every trade settles individually the instant it happens, and the liquidity requirement explodes, because the offsetting disappears. That’s the four-quadrillion-dollar problem, and it’s real. It’s also specific to a world where a small number of parties transact repeatedly with each other, and the netting has somewhere to net against. 
Retail payments don’t have that structure. A freelancer waiting on an invoice, a small business waiting for a card batch to settle, a family sending money across a border, none of them have an ongoing bilateral position with the other side to offset. There’s no repeated counterparty, no netting partner, nothing to compress. So retail rails don’t net, they queue. ACH takes one to three business days. Card settlement runs on a batch cycle that lands days later. A wire clears same-day only if it beats the cutoff, and cross-border transfers stack fees and float on top of all of it. None of that delay is netting happening quietly in the background. It’s processing time, dressed up as if it were doing something clever, and someone pays for it: the merchant who can’t reinvest incoming funds for three days, the gig worker bridging a cash-flow gap between payouts, the family paying twice for the privilege of waiting.
Lightning nets too. It just doesn’t make the user wait for it.
Lightning solves this by running a netting architecture at a different layer. Two parties open a channel and can transact against each other thousands of times, each payment updating a shared balance, without touching the base chain once. When the channel eventually closes, or splices, only the final state gets broadcast on-chain. Thousands of payments collapse into a single settlement, the same move DTCC makes when it nets bilateral securities trades down to one net transfer. The mechanism is nearly identical. What’s different is where finality actually lives.
On DTCC’s rails, the netting cycle and the settlement moment are the same event, so you wait for the net because the net is what settles you. On Lightning, the two are decoupled. A payment resolves the moment the receiving node’s hash-locked contract is satisfied, in about two seconds, regardless of whether the channel closes that day, that month, or six months from now. The netting happens on its own schedule, invisibly, whenever it’s economical to touch the base chain. The user was never waiting on it, because the user’s finality never depended on it. This isn’t hypothetical at this point. Lightning crossed $1 billion in routed volume in a single month for the first time in November 2025, and at the individual transaction level, one enterprise Lightning integration processed 237,000 transactions worth $6.35 million in a 30-day window at an average settlement time of 1.86 seconds, a workload that on legacy retail rails would have generated 237,000 individual settlement events or sat in a batch queue. Lightning did neither. It netted in the background and paid the user in real time.
The obvious objection, and where it actually bites
The fair pushback is that Lightning’s netting has its own scaling wall: channel capacity, liquidity locked on both sides of every relationship, and the routing problem of finding a path with enough balance to move a given payment. That’s a real, well-documented constraint, not a hand-wave. But it’s a liquidity-engineering problem, not an accounting impossibility. It’s why the current wave of Lightning development, ephemeral anchors, package relay, better splicing, is aimed almost entirely at making channel liquidity cheaper to manage and faster to rebalance. Every one of those upgrades chips away at the actual bottleneck.
There’s no equivalent fix waiting for DTCC’s constraint, because DTCC’s constraint isn’t an engineering problem. Gross-settling four quadrillion dollars a year isn’t hard because the technology is immature. It’s hard because the liquidity required doesn’t exist and never will, at any level of engineering sophistication. That’s a structural ceiling. Lightning’s liquidity constraint is a moving target that keeps getting better, which is a different category of problem entirely. It’s also worth being straightforward that Lightning isn’t trying to replace what DTCC does. Institutional securities settlement among a closed set of counterparties and retail payments among strangers are different problems, and nobody serious is proposing Lightning nets Treasury trades.
The math was never the disagreement
Chakar’s math is a useful reminder that gross-settling everything, everywhere, in real time, was never a serious goal, not for securities and not for payments. But the lesson people keep drawing from it, that instant finality is therefore a fantasy, only holds if netting and speed have to be opposites. They don’t. Lightning has been quietly proving that for years: net in the background, off the critical path for the end user, on whatever schedule makes economic sense, and let the person on the other end of the payment feel none of it.
The real settlement debate was never gross versus net. It’s whether the person paying has to wait for the netting to happen before they get their money’s worth. On one rail, they still do. On the other, that question stopped being relevant a while ago.
