Sui Spheres Overview.

Added: 2026-05-15

[00:00:00]data privacy and coordination work here at Miston Labs. Uh I'm joined by a couple of friends from the research team at Miston. Uh Yakamo who's been driving product thinking on this and Marcus who's leading the engineering work. Um we wanted to do a quick conversation on something we have been building internally what we are calling SUI spheres. Uh at a high level spheres are controlled execution environments on top of SUI. Uh so they allow a defined set of participants uh institutions, teams, services to run uh you know shared workflows with uh controlled participation uh role-based visibility uh and uh different execution assumptions than public networks. So that includes things like uh performance, cost models um and even how users authenticate and interact with the system. So at the same time these environments aren't isolated they can connect uh out to the broader SUI network when needed uh you know especially for things like liquidity settlement or auditability.

[00:01:06]So the goal is not to replace the broader sui network uh but to extend it with a new way to run multi-party systems. Uh so maybe Gakmo we can start with you know why we felt the need to build something like this.

[00:01:19]>> Yeah. So what we keep running into is that real world systems don't just need shared infrastructure. They need controlled coordination. And you can see this in most enterprise or institutional workflows for example where you have multiple independent parties that are sensitive data or like positions and pricing or have often regulatory constraints around who can see and do what. So it's not just enough to share state. you need to control participation, access, and interaction.

[00:01:53]Today, you're usually forced into a trade-off where on the one hand, you could use a fully public system which gives you openness, composibility, but comes with the constraints around visibility and cost and how users interact. Or on the other hand, you could build something private where you get full control over participants and performance, but you lose the interoperability and end up in a silo. So what's missing is a way to get the benefits of both, not just confidentiality, but also predictable performance, flexible cost models, and a more practical onboarding.

[00:02:31]And this is the gap we're really trying to address.

[00:02:36]>> Yeah. And from a systems perspective, those constraints show up pretty quickly. If you take something like a multi-party financial workflow or even an enterprise system, you often need faster interaction cycles than a public network, tighter control over who can submit and execute transactions, and the ability to abstract things like gas or key management.

[00:03:00]trying to layer all of that directly onto a public execution model becomes complicated or even impossible um both technically and from a developer experience standpoint. So instead we introduce an environment where those assumptions are different by design.

[00:03:20]>> That's actually a good point. Uh you know a lot of this sounds like you know things people try to do on public networks today. Um but uh you know why not just extend the plot network then to handle that Marcus?

[00:03:33]>> That's a good question. Uh you can push public systems pretty far. Uh we've seen that in practice but there are still fundamental trade-offs. Um the existing SUI network is optimized for open participation, global decentralization, global ordering of transactions and shared system state across everyone. But once you start introducing things like selective visibility, restricted participation and different performance or cost expectations, you're effectively working against some of these assumptions.

[00:04:08]So rather than trying to bend the public layer to fit every use case, we decided to create a separate execution environment where these things are first class and importantly this gives you flexibility over time. uh you can run workflows inside a sphere with constraints that you need whether that's visibility, cost or on boarding and then decide how and when to interact with the other spheres or the broader SU network.

[00:04:40]So instead of choosing up front between public and private, you can move between them based on what actually creates value for you.

[00:04:49]>> That's an important point. You can move between them, you know. Uh so so let's make it a bit more concrete like what are the kinds of systems uh you know folks think where this actually makes a difference. Yakamo >> yeah so the strongest cases are where you have multiple independent parties that are coordinating over shared logic but with different constraints.

[00:05:11]One example are financial workflows where things like lending, collateral management or structured products are commonplace. Um, and you have, you know, multiple institutions that share a fixed set of contracts but have different positions, pricing and exposure and these are represented in different views. So, u such a situation is very hard to model cleanly in a fully public system.

[00:05:41]And then there are cases where the constraints are more operational than financial. For example, workflows between counterparties where contracts, pricing or um exposure data can't be fully shared. Uh platforms that connect multiple businesses or providers where each participants uh each participant needs visibility into their own activity but not others. or even agent-based systems where different agents operate on shared state with restricted access.

[00:06:14]In all of these you need coordination across participants but not uniform visibility or access and often you also want better control over performance and more predictable costs. That's where something like spheres become becomes very useful.

[00:06:32]>> Yeah. And then and then there are cases where you don't really need this. If you have a single tenant system or something that never needs to interact outside, you probably don't need a shared environment at all. Uh on the other hand, if it's a fully open and permissionless system, then the brother network is already a better fit. So this really sits in that middle position where you have multi-party systems but with constraints.

[00:07:01]Yeah, that middle ground is really the interesting part and just to be clear uh you know this is still early uh you know we are working with a small set of design partners and a lot of this is evolving as we go uh but we are starting to see enough signal that it made sense to share with everyone like what we are building. So if you are working on something where uh multiple parties need to coordinate you know you have constraints around visibility performance or on boarding uh but you still want to connect to a broader ecosystem uh like sui so we would love to chat uh anything from you Kakamo towards the end >> yeah especially if you've tried building something like this and already run into the tradeoffs >> and uh we're very much building this with partners. So early input is really valuable.

[00:07:54]>> Awesome. Thank you both. Uh and yeah, please feel free to reach out to us.

[00:07:58]We're excited to explore this with more teams. Thank you. All right.