Private pools and private actions

Private transfers run today. Private swaps are next, and they are the piece that turns a private balance into something you can actually use. This page and Compliance are what comes after that.

Separate pools for institutions

Every note carries a pool identifier today, and every account is already keyed by it, even though only one pool exists.

Opening a second one means a pool with its own admitted tokens, its own fee schedule and its own membership rules — so a fund can hold shielded positions under a policy its auditors accept, instead of sharing one pool with everybody. The trade-off is real: a smaller pool is a smaller crowd to hide in, so more pools is not automatically better.

Private actions

This one is a direction, not a design.

A private action is a computation another program hands to us: it runs off chain, on inputs nobody else can read, and settles on Solana. We built Bonsol, a Solana co-processor with callbacks, so the shape is not new ground for us. And Sombra's nodes already do the two hard parts: prove something off chain, then settle the result on Solana.

Pointing that at other programs' private computations is the open question. It would mean a Solana program sends inputs that only the prover can read, our nodes verify the result, and the program gets a callback — with the option to pay out of a shielded balance in the same round. Confidential inputs and a private payout, together, is the part nobody has.

What it could serve, if it works: order matching that settles privately instead of just matching privately, credit checks that never hand over the underlying data, solvency proofs that do not publish the book.

If any of this matters to what you are building, the FAQ says where to reach us.