Table of Contents
Researcher
Related Projects
When building a Web3 app, there comes a point where you need to implement user-to-user communication: guild chat, customer support, DAO discussions, trade negotiations, and so on. But trying to solve this onchain leaves you with few good options. Most teams end up falling back on external services like Telegram or Discord, or plugging in a centralized messaging API. The downsides are clear: these approaches aren't tied to wallet identity, they're disconnected from onchain activity, and access control lives outside the rest of the app's logic.
Source: Sui
Sui's Messaging SDK is a project aimed at closing this gap. The idea is to offer encrypted messaging natively on top of Sui's own stack: identity, access control, and storage. First unveiled as an alpha in September 2025, the SDK went through months of feedback and architectural rework before its beta was deployed yesterday (March 31, 2026) on the Sui and Walrus mainnets.
This beta is not a simple version bump. The fundamental question the alpha ran into, "Should every message be processed as an onchain transaction?", got a different answer, and the entire architecture was redesigned accordingly.
1. What the Alpha Attempted, and Where It Hit a Wall
The alpha stored messages directly onchain on Sui, saved attachments to Walrus, and implemented end-to-end encryption via Seal. The API reference makes this structure explicit. Sending a message meant building and signing a Sui transaction, as shown below.
Creating a communication channel worked the same way. As the code below shows, it followed a two-step flow: create the channel as an onchain transaction, then attach an encryption key through a separate transaction.
This approach offered strong verifiability. Since every message existed as a Sui object, it was possible to prove onchain who sent what and when, and to program message-based logic through smart contracts. Membership was managed through onchain objects called MemberCap and CreatorCap, with permission checks enforced at the protocol level.
Sui shipped a working demo app called chatty.wal.app, which helped attract developer interest. But developers who actually used the alpha quickly ran into scalability limits. Sui's own blog addressed this directly:
Does every message need to be a transaction?
How do you deliver real-time chat without overwhelming the chain?
How do you keep costs predictable for apps that scale to millions of messages?
How do you support cross-device recovery without centralized backups?
Consider a game guild chat generating dozens of messages per second. Processing each one as an onchain transaction is impractical in terms of both cost and latency. These questions ultimately expose the core tradeoff of Web3 messaging: fully onchain messaging is verifiable but slow and expensive; fully offchain messaging is fast but no different from existing centralized services.
2. Beta Architecture: What Goes onchain and What Doesn't
The beta's answer is neither "everything onchain" nor "everything offchain," but a separation of responsibilities. Three components each handle a distinct role.
Groups SDK (onchain, Sui): Manages channel creation, membership, permissions, and configuration. Channel state lives onchain, making it verifiable and enforceable via smart contracts who has access to which channel. The key point is that what's managed here is not the messages themselves, but membership and permissions. The alpha's
MemberCap/CreatorCapmodel falls under this component.Backend Relayer (offchain): This is where the biggest change happened in the beta. It handles real-time message exchange. Instead of writing individual messages as transactions, the relayer pulls membership data from a Sui full node via gRPC, validates it, and delivers messages. Unlike the alpha, where
sendMessagebuilt a Sui transaction, the beta delegates this to the relayer. The relayer can be run as a standard service or executed inside a TEE (Trusted Execution Environment) using Nautilus. Messages are periodically backed up to Walrus.Messaging SDK (Integration Layer): The interface developers work with directly. It abstracts away the permission groups and the relayer while handling Seal encryption, attachment storage via Walrus, and message recovery.
In one sentence: in the beta, membership is onchain, messages are offchain, and backups and attachments are managed through decentralized storage.
3. Encryption Model: Protecting Plaintext from the Relayer
A notable aspect of the beta's encryption model is that, although much of message delivery passes through an offchain relayer, the relayer cannot see message contents.
The alpha's message types reveal the encryption structure:
All messages and attachments are encrypted with Seal before leaving the client. The relayer only handles ciphertext. Attachments are encrypted client-side and stored on Walrus; messages are periodically archived to Walrus as well. Decryption rights are governed by channel membership, and since that membership is managed onchain (via the Groups SDK), access control itself remains verifiable.
What this means in practice is that message security holds even without trusting the relayer. If the relayer is compromised or acts maliciously, message contents stay protected. Running the relayer inside a TEE adds metadata-level protection on top of that.
One caveat: in the alpha, messages themselves were onchain Sui objects, so even the fact that a given message existed was provable onchain. In the beta, this property is replaced by periodic archiving to Walrus. Per-message real-time onchain proof is gone, but decentralized storage and availability guarantees at the archive level remain intact. This is the tradeoff paid for scalability.
4. The Direction: Programmable Messaging
What this SDK ultimately aims for is not a chat UI but a programmable communication infrastructure. The fact that the Groups SDK can be used independently reinforces this direction. Since channel membership and permissions are managed through Sui smart contracts, even adding a single member comes with onchain permission verification.
Only an address holding a CreatorCap can add members, and each added member receives a MemberCap. Because all of these are Sui objects, "who is a member of this channel" is verifiable onchain by anyone. Building on this, the following scenarios become possible at the code level:
Token-gated channels accessible only to holders of a specific NFT
Discussion channels that are automatically created or dissolved based on governance vote outcomes
AI agents communicating with other agents or users inside encrypted channels
Message flows triggered by onchain events (trade confirmations, liquidation alerts, etc.)
Cross-app coordination between protocols
In existing Telegram- or Discord-based communication, access control is managed at the application level through API keys or bot permissions. On Sui, access control is tied to onchain state and enforced by smart contracts, allowing messaging logic to operate on the same verifiable layer as the app's business logic.
5. How to Read This
The transition from alpha to beta of the Messaging SDK shows that Web3 messaging as a category is still searching for its optimal design. Acknowledging the limits that the alpha's naive approach of putting everything onchain hit in real-world use, and redesigning around a hybrid model, was an honest engineering call.
The pattern the beta puts forward, "membership onchain, messages offchain, storage decentralized," could become a practical design baseline for Web3 messaging. It's the product of wrestling with where to draw the line between the ideal of fully onchain messaging and the reality of real-time communication. Whether that line is drawn in the right place will be validated as production apps are built on top of it.
One open question is whether message delivery availability is dependent on relayer operations. Self-hosting and TEE execution are supported, but in most apps, someone still has to run the relayer. And the fact that Walrus archiving is periodic means that if the relayer goes down between archiving cycles, messages from that window could be lost. These are points worth watching as future updates come through.
