Introducing Sui Spheres

Introducing Sui Spheres

Sui Spheres are controlled execution environments for multi-party workflows, with selective visibility, flexible performance, and the ability to connect to the broader Sui network.

Main takeaways

  • Most institutional workflows can't run publicly, but fully private systems create silos. Sui Spheres offers a middle ground, where controlled environments allow known participants to coordinate with role-based visibility, predictable performance, and flexible costs, without giving up interoperability.
  • Spheres treat selective visibility and restricted participation as first-class design choices while staying connected to the broader Sui ecosystem when it matters.
  • We're working with early partners across financial infrastructure, private markets, and multi-party systems. If you're building in this space, get in touch.

A new way for institutions to build, coordinate, and scale

Teams want the benefits of shared infrastructure — programmable coordination, real-time state, global interoperability — but many of their workflows cannot operate in a fully public environment. They require control over who participates, what information is visible, and how systems are operated, along with more predictable performance and cost characteristics than a shared public network can always provide.

This tension has defined how institutions have approached blockchain so far. Many have stayed on the sidelines while others have built isolated systems. Both have produced limited adoption and fragmented ecosystems.

Today, we’re providing a look at Sui Spheres, a new way to run controlled, multi-party workflows with selective visibility, while preserving the ability to connect to a broader ecosystem when desired.

This thinking is early and evolving. We’re working closely with a small set of design partners and learning in real time. But the direction is clear.

A new model for coordination

Sui Spheres are controlled execution environments where known participants can coordinate, transact, and run shared workflows without exposing everything publicly.

They are designed for situations where multiple parties need to interact on shared infrastructure, but not all information should be visible to everyone. Participation is governed, visibility is intentional, and workflows can be executed with the control of traditional systems — including more predictable performance and flexible cost models — without sacrificing programmability.

Inside a Sphere, coordination happens privately and efficiently. Different participants can see different parts of the same system depending on their role and permissions. Outside the Sphere, selected outcomes can be made visible or interoperable depending on what the use case requires. This opens up workflows that didn’t fit cleanly into existing models, from financial infrastructure to enterprise systems to emerging multi-party applications.

Why not just extend the public network?

A reasonable question is whether these goals could be achieved by extending the existing Sui network. The Sui network is optimized for open participation, global decentralization, and shared state across all participants — properties that make it powerful, but ones that selective visibility, restricted participation, and different performance expectations work against by design. Rather than bending the public layer to fit every use case, Spheres creates a separate execution environment where those constraints are first-class choices, not workarounds.

Why this matters now

The next wave of adoption is not just about new tokens or DeFi primitives. It’s about coordination across organizations, systems, and markets.

Across industries, the requirements are converging. Teams need confidentiality by default, clear control over participation, predictable performance, and flexibility in how costs are structured — rather than being tightly coupled to public network gas dynamics. How users onboard and authenticate also matters; key management needs to be practical, not an obstacle.  At the same time, they don’t want to give up what makes shared infrastructure powerful.

Sui Spheres let teams operate in controlled environments with clearly defined participation and visibility, without choosing upfront between public or private. Teams can move between them based on what actually creates value, and let systems evolve as business needs change. 

The use cases where this matters most share a common structure: multiple independent parties coordinating over shared logic, but with different constraints on what each can see or do. We’re already seeing interest from teams building financial infrastructure, private markets, and multi-party systems that require both coordination and confidentiality. Financial workflows are a natural fit, as lending, collateral management, and structured products often require multiple institutions to run shared contracts with different views of positions, pricing, or exposure. The same pattern applies to platforms connecting multiple businesses or service providers, where each participant needs visibility into their own activity but not others', as well as to emerging agent-based systems where different agents operate on shared state with restricted access. These are areas where fully public systems don’t often fit, and fully private systems don’t scale. Sui Spheres create a middle ground where both can coexist.

Spheres aren’t a fit for every use case. Single-tenant systems that don't need to interact with other parties don't require a shared environment, and fully open, permissionless workflows are already well-served by the public Sui network. Spheres are designed specifically for the middle ground: multi-party systems with real constraints around visibility, participation, and performance.

Built on Sui, for the real world

Sui was designed for safety, composability, and scale, with a data model that maps naturally to real-world assets and workflows. Sui Spheres build on that foundation to support environments that demand greater control over visibility, participation, performance, and cost.

Control and coordination need not be at odds. Confidentiality shouldn’t come at the cost of programmability. Private workflows should be able to connect to a broader system when it matters.

We’re early in our process. Most of what we’ve learned comes from a handful of deep partnerships, and the design is still taking shape. But the need is real, the conversations are happening, and we’re ready to go further.

If you’re building something that requires controlled environments, selective disclosure, or hybrid private-public workflows, get in touch with us.