NettedX

Poster

NettedX is an on-chain settlement system that nets obligations before settling them atomically. Settling trade by trade is safe but capital-hungry, because it discards the multilateral netting that makes today's volumes settleable — netting that SIFMA cites as removing around 98% of the cash that actually has to change hands in US equity markets. The difficulty is that multilateral netting has always required a central party to compute it — which is exactly what atomic settlement set out to remove. NettedX separates the two: a contract computes the net without ever holding assets.

Inspiration

Banks and market infrastructures are already building tokenised asset platforms, and the motivation is largely post-trade cost. Institutions each maintain their own ledger, so every transaction has to be reconciled across them; the BIS has cited an estimate of USD 17–24 billion spent annually on trade processing. Reduced reconciliation is the benefit most consistently identified by the FSB, the BIS and the OECD alike.

The BIS and the Swiss National Bank settle tokenised securities with central bank money in Project Helvetia, now a live pilot using real wholesale CBDC. The Monetary Authority of Singapore runs Project Guardian with more than forty institutions. SIFMA coordinated the Regulated Settlement Network proof of concept, settling tokenised deposits, wholesale central bank money and Treasury securities on a shared permissioned ledger.

But that saving only materialises if settlement moves on-chain too. A tokenised platform whose settlement still runs through legacy systems leaves two ledgers to reconcile — precisely the cost it was built to remove.

The default answer for on-chain settlement is atomic settlement. Settlement's oldest problem is principal risk: you deliver the security and the counterparty fails to pay. The traditional fix is delivery-versus-payment, where delivery happens if and only if payment happens — and conventionally that conditionality is enforced by institutions, with a custodian holding the securities and a clearing house forcing both legs together. Atomic settlement replaces that institutional guarantee with a technical one.

But settling trade by trade quietly throws away netting. According to SIFMA's analysis, netting reduces the cash that actually has to change hands by roughly 98%. Remove it and every participant must fully fund every trade.

And multilateral netting has always been computed by a central party — the very thing atomic settlement removes. The two properties pull against each other, and that structural conflict is the problem NettedX exists to solve.

What it does

The settlement cycle has four phases.

Collect. Trades accumulate over a fixed window of blocks. The contract records obligations and updates net positions as each trade arrives — no assets move.

Freeze. The batch stops taking new trades and its net positions become final, so every participant can query exactly what they owe and what they will receive. The chain keeps recording — trades submitted from this point simply belong to the next batch, which begins accumulating straight away.

Fund. A short funding period follows, in which participants bring their net obligations into position.

Settle. An operator triggers settlement. Balances and authorisations are checked, anyone who cannot perform is excluded and the remaining positions recomputed — repeating until the remaining set is viable, bounded by a fixed round cap so the loop cannot exhaust the block gas limit. Every surviving transfer then executes in a single transaction — all of it, or none. Excluded trades roll into the next batch and net against new trades.

Batches overlap, so settlement still occurs every ten blocks even though each batch takes fourteen from opening to settlement. Separating freeze from settle is what makes the deadline usable: a funding period is only worth having if you already know the number you have to fund.

The conflict resolves because computation and trust are separable. The contract computes the net, but holds no assets, takes no positions, and never becomes anyone's counterparty. Participants keep custody throughout — they authorise transfers rather than depositing. DvP remains enforced by atomicity, not by an intermediary.

The numbers

Three participants, three matched trades, one window. Bonds at 100 cash each, fixed at match time.

A buys 10 bonds from B — A owes 1,000 cash, B owes 10 bonds
B buys 5 bonds from A — B owes 500 cash, A owes 5 bonds
A buys 3 bonds from C — A owes 300 cash, C owes 3 bonds

Netted: A owes 800 cash and receives 8 bonds; B receives 500 cash and delivers 5 bonds; C receives 300 cash and delivers 3 bonds. The positions for each asset sum to zero, which the contract asserts on every window.

Gross, those trades move 1,800 in cash and 18 bonds. Netted, 800 and 8.

The effect on funding is sharper still:

A — gross: 1,300 cash and 5 bonds. Netted: 800 cash only
B — gross: 500 cash and 10 bonds. Netted: 5 bonds only
C — gross: 3 bonds. Netted: 3 bonds, unchanged

A and B each had to fund both sides of the market; now they fund one. Three trades already cut what moves by more than half, and the effect compounds with participant count. At market scale, that is where the 98% comes from.

Netting is also what makes atomic settlement computationally possible. Settlement must fit inside one transaction, so it cannot exceed a block's gas limit. Obligations are aggregated into a single bilateral edge per counterparty pair and asset as trades arrive, so settlement cost tracks the number of relationships between participants rather than the number of trades — a busy window between the same parties collapses into the same handful of transfers as a quiet one.

Liquidity support

When a participant is short, a liquidity buffer lends them the difference — and the borrow is composed into the settlement transaction itself. Today a treasury desk must estimate its shortfall before the settlement cutoff, arrange funding, and fail if the estimate is wrong. Here the system detects the shortfall and covers it in the same atomic execution, drawing on a facility the participant arranged once, in advance — so the size and timing of any particular shortfall never have to be predicted.

Atomicity also makes the lending safe: if any leg fails, the loan unwinds with it, so the buffer has no exposure between disbursement and use. Repayment is a separate, later transaction, with interest accruing per block — a fixed rate in the prototype.

Handling failure

No real settlement system guarantees 100% success. Failures to deliver occur daily in US equity markets, which is why the SEC publishes fails-to-deliver data and specific regulations exist to govern them. A central counterparty guarantees financial performance, not timely delivery.

Exclusion has a consequence worth stating plainly. Suppose a participant owes 100 and is owed 20 by a third party. Their net obligation is 80, so 80 is what they funded — and if that third party is excluded, their obligation becomes 100 and they are short too. Exclusion cascades. The liquidity buffer limits it by lending against residual gaps, which netting has already shrunk. We do not eliminate it, because that requires a party absorbing shortfalls with its own capital.

NettedX targets a permissioned network, where participants are licensed institutions rather than anonymous addresses. That gives deterministic finality, predictable block production, and legal accountability alongside the technical guarantees — and it closes an attack that public chains cannot: a participant who submits trades and refuses to fund them is a known institution, identified and removed under the participation agreement.

Who it is for

Settlement operations at banks and market infrastructures — the people who monitor windows, manage intraday funding, and handle failed settlements. NettedX takes already-matched trades as input; order books, matching and price discovery are outside its scope. Because prices are fixed at match time, no price feed is required.

How we built it

The architecture separates responsibilities across a small set of contracts: two ERC-20 tokens for the cash and securities legs, a netting contract that records obligations and computes net positions, a settlement contract that executes transfers atomically behind a fixed interface, and an optional liquidity buffer. The netting contract is implemented, including the window state machine and the exclusion loop; settlement sits behind an interface so the two can be built and tested independently.

Three decisions shaped the implementation. Authorisation rather than custody — participants approve the settlement contract for a capped amount per asset, so transfers move directly between their own addresses and the contract never becomes a custodian. Aggregation at submission — obligations collapse into one bilateral edge per counterparty pair and asset as they arrive, so the work at settlement never grows with trade volume. Blocks rather than wall-clock time — block height is the unit in which trades are actually ordered, and if block production stalls the window extends with it rather than closing during an interval in which nobody could trade. Participants still see seconds; the contract reasons in blocks.

Contracts are Solidity with OpenZeppelin, tested and deployed with Foundry. The backend is Python with FastAPI. The front end is Vue 3 with Vite, using Pinia for state and TDesign for components. Our demo collects for ten blocks, freezes on the eleventh, allows two blocks for funding, and settles on the fourteenth — around fourteen seconds at one-second blocks. That is short enough to be visible in a live demonstration, not proposed as a production value. A real deployment would size both the window and the funding period to the time institutions actually need to move money.

Challenges we ran into

Netting and atomicity are genuinely in conflict. Recognising this took longer than solving it — the fix, once seen, was a single distinction between computing a number and being trusted with assets.

Excluding a defaulter changes everyone else's position. Our first design reverted the entire batch if any participant fell short — which let one unfunded party block every other settlement at almost no cost. Excluding the defaulter looked like the obvious fix until we worked the arithmetic: a participant whose obligation was reduced by an incoming payment becomes short the moment that payment is removed. We settled on iterative exclusion with the buffer lending against residual gaps, and on being explicit about how far that gets us.

Atomicity imposes a hard ceiling on scale. The gas limit cannot be worked around by splitting the work across transactions — splitting it is what breaks the guarantee. This reframed netting for us. We had treated it as a liquidity mechanism; it turned out to be a scalability one as well.

The window length cannot be adjusted mid-flight. We initially treated it as a tuning parameter and considered varying it with trade volume. That is wrong in both directions — shortening it strips participants of time they were relying on, extending it strands prepared capital, and if an announced deadline cannot be trusted the only safe response is to hold full funds at all times, which destroys the benefit the system exists to provide.

Accomplishments that we're proud of

We identified a conflict in the default approach to on-chain settlement and designed a mechanism that resolves it. Most discussion of tokenised settlement treats atomicity as an unambiguous improvement and leaves its capital cost unmentioned.

We are equally proud of what the design refuses to claim. It would have been easy to describe a system that always settles successfully, and far less useful.

What we learned

Most of the hard problems in settlement are about failure — the happy path is short, and everything difficult lives on the other side. Existing infrastructure encodes reasons we had to rediscover. T+N exists to give participants a funding window with an announced deadline, and central counterparties exist to stop defaults cascading. And being explicit about limits is more persuasive than claiming completeness: a simplification we could describe alongside what production would require reads as a scope decision, while one we could only describe as absent reads as a gap.

What's next for NettedX

Fails charges — pricing failure so that borrowing liquidity and failing to settle both carry a cost, as NSCC does with a daily charge on failed positions.

Cascade handling — iterating toward the largest viable settling set rather than the first, the problem central bank RTGS systems address through gridlock resolution.

Buffer funding, rate and sizing — the prototype uses a fixed rate and a pre-funded buffer. In production the rate would anchor to a benchmark, and the capital would more plausibly come from institutions without settlement obligations of their own — money market funds, custodians, or treasury desks long that day — since capital committed by a participant is capital they cannot use to meet their own net position. Facility size would follow the principle that sizes CCP resources against the default of the largest participants.

A production cash leg — tokenised commercial bank deposits or wholesale central bank money rather than a mock token, which is what Helvetia and RSN actually tested. The settlement logic is indifferent to which is used; it requires only a transferable on-chain claim.

Cross-network settlement — where the window unit would have to change, since block height is local to a chain and time is the only shared reference across networks.