Operator-blind multilateral compression: how it's built, and three things I'd like criticism on

I built CompressRail during Encode’s Build on Canton hackathon and it has been running against my own DevNet validator since July, so I’d rather post the architecture here and get it shot at than keep polishing it alone.

The problem. Multilateral compression releases initial margin trapped in offsetting derivatives trades, but to find the offsetting cycle every participant has to hand its whole book to a central operator that then sees everyone’s positions. Large dealers accept that; much of the mid-tier and buy-side does not, and stays out. The blocker is privacy, not computation.

The design. The operator coordinates a cycle without ever seeing a position, a notional or a rate, and two layers enforce that together:

• No operator party is a signatory or observer on a position-bearing contract, so projection alone keeps BilateralTrade out of its view.
• Every economic field is written on-ledger only as authenticated-encryption ciphertext, with the content key wrapped per counterparty (and per auditor where disclosed). The operator holds no key.

Matching runs outside the operator party. Each participant reads its own projection, verifies post-cycle risk on its own node and authorises only its own legs. The CompressionCycle contract carries cycle coordination and teardown references but no economic terms, and the whole rebalance commits in one transaction — every leg or none. A participant can grant its regulator a decryption scope for one trade, recorded on-ledger, and nothing beyond it.

What is actually live. Real party allocation, encrypted trades, matching, per-node risk checks and atomic execute against DevNet through the global synchronizer (JSON Ledger API 3.5.4). The privacy claim is measured rather than asserted: every cell of the privacy matrix is read from that party’s own projection, and there is a control that acts as the operator and genuinely attempts to decrypt a participant’s book against the live ledger. It fails, because the operator’s own projection holds zero bilateral trades. An end-to-end suite runs against the same public endpoint the demo uses.

Stated boundary. The operator does see cycle topology — which parties net with whom — never the terms behind it. It runs on a single participant node today, with demo-grade keys, and it is not audited.

Three things I’d genuinely like criticism on:

1. Multi-node. The obvious next step is a cycle across separate participant nodes, one per counterparty. For those who have done this in anger: what actually bites — party hosting and onboarding, synchronizer connectivity, or operational overhead per participant? Is a NaaS provider per counterparty the sane path for a pilot, or does that recreate a trust problem I am trying to remove?

2. Teardown authorisation. Today teardown is authorised by each participant on its own legs, with the cycle contract referencing the trades. I also modelled an explicit nomination choice but did not put it in the live flow. Is there a cleaner Daml pattern for multi-party teardown authorisation where no party — including the coordinator — learns the other side’s terms?

3. External signing. Would adopting external signing / interactive submission materially strengthen the “operator holds no participant key” property, or is projection plus application-layer encryption already the right boundary for this shape of workflow?

Demo: https://demo.compressrail.com (seeds a book and runs a cycle, no signup)
Docs: https://docs.compressrail.com
Code: https://github.com/LevCey/CompressRail
3-minute walkthrough: https://youtu.be/8XmG6ss5XuY

Happy to be told that part of this is wrong — that is the point of posting it.

Hi @LeventLabs! I will try to be helpful based on my understanding of the problem. Given the project’s early stage, I will aim to start with feedback/questions from the value prop:

1. Economic terms, privacy & trust in the CompressionCycle

The operator sees cycle topology — which parties net with whom — but never the terms behind it.

The CompressionCycle contract carries cycle coordination and teardown references but no economic terms

Here, cycle coordination and matching are unclear to me regarding economic terms and responsibility. I would expect trust & operation to depend heavily on the CompressionCycle rules for such setup to be effective. I assume this is intended for trades of the same asset, right?

“The blocker is privacy, not computation.”

In any case, my bottom line is that I would expect more detail on how computation runs and the privacy trade-offs vs. how it works today in TradFi, to understand the possible business model and benefits for the parties involved. Based on the statement, I understand this would facilitate business that dont happen today, so I would aim to polish that market validation thesis really well. This should help to confirm that privacy IS the real blocker for such flow.

2. What about partial offsets?

“the whole rebalance commits in one transaction — every leg or none.”

With small trade volume to start, I would expect that cycles rarely net to zero. It wasn’t clear to me what the solution for this is.

–

And answering your questions more explicitly:

Multi-node. Agree that this is an important step to actually show the solution working between parties that each run their own node. I would also suspect that sharing the same node recreates the privacy problem.

External signing. I would expect this to be completely necessary if parties share the same node. If they dont, I dont see why external signing would benefit the flow.

Hope this feedback and answer sparks some useful ideas! Best of luck on your journey with CompressRail, and congrats on the hackathon.

Thanks @tomimor — this is exactly the kind of reply I was hoping for.

Partial offsets. This is the case the matcher actually solves, and I should have made that clearer in the post. It tears up the nominated set and rebuilds each party’s net position with a minimal set of replacement legs: per risk factor it pairs the net-long parties against the net-short ones, so every party’s net risk is preserved. Zero replacement legs is the
special case where the set happens to net to zero, which is what the demo ring shows. A partial offset simply produces fewer legs than you started with. “Every leg or none” refers to atomicity — the teardown and the replacements commit in one transaction — not to a requirement that the cycle nets to zero.

Same asset? Not necessarily. Risk is a vector of factors and netting happens per factor, so the nominated set doesn’t have to be a single instrument.

How the computation runs. Fair criticism. Matching runs outside the operator party, but in this build it runs over cleartext on the participant side. It is a deterministic stand-in for the per-node computation a production system would do, and production risk models (SIMM, SA-CCR, CRIF) are out of scope for now. That gap is real and I would rather name it than
leave it implied.

Market validation. Agreed — and you are the second person from the ecosystem to tell me this. Getting two or three counterparties with genuinely offsetting exposure into one cycle is the next piece of work, and it isn’t a coding problem.

External signing. That answers my question, thank you. If parties run their own nodes, I’ll leave it out.

Multi-node is the immediate next step: one node per counterparty.