← Back to Pulse
Monad logoResearchMonadBlockchainInformational

Category Labs publishes Monad Private Settlement white paper

Private Settlement Domains would combine confidential execution with Monad’s public transaction ordering. The paper details the first-version design, operator trust and the limits of cross-domain privacy.

BitCtrl Editorial•Research and Operations•Nov 4, 2026•5 min read
Lavender paper rooms with operator workstations connect through a shared teal route carrying folded envelopes.

Category Labs published the technical white paper for Monad Private Settlement Domains on 3 November 2026. It expands on the private-settlement initiative introduced in October, describing how permissioned execution environments connect through the public Monad network. The update is a research publication; the announcement does not establish a public-network rollout. Announcement.

A Private Settlement Domain, or PSD, is an execution environment run by operators selected by its creator. Its transactions and state are private, while Monad supplies transaction ordering, settlement of state commitments and message routing between domains. The design uses a hub contract on Monad and a spoke contract inside each PSD, without requiring a change to the Monad protocol. White paper, introduction and section 5.1.

What happens to a private transaction

A user signs a transaction for the destination domain. The wallet encrypts it and puts it inside an ordinary Monad transaction addressed to the hub. The paper calls this outer transaction a courier. It pays for the public-chain work and funds execution inside the domain; its payer can be different from the person signing the inner transaction.

The encrypted transaction hides its sender, recipient, call data, nonce and signature. Its destination domain and gas limit remain visible. That distinction is useful: the public chain can order and charge for work without executing the private payload itself. It does not mean every observable detail of the submission disappears. Section 5.2.1.

Domain operators then decrypt and execute transactions in the order established by Monad. They do not run a separate consensus protocol to choose that order. In the first version described, each Monad block containing transactions for a particular domain produces one corresponding domain block. The hub limits admitted work and stops accepting new transactions when a domain falls too far behind.

After execution, operators submit an attestation over two cryptographic commitments: one to the updated state and one to outgoing messages. The hub checks that attestation against the domain’s configured rules. This is where transaction ordering and execution correctness meet: Monad supplies the order, while the domain’s attestation mechanism determines how its reported results are trusted. Sections 5.2.2–5.2.4.

The paper’s first-version design: Monad orders transactions; domain operators decrypt, execute and attest to the results. Operators can see private state.
The paper’s first-version design: Monad orders transactions; domain operators decrypt, execute and attest to the results. Operators can see private state.

Contracts communicate through messages

Separate execution environments cannot behave exactly like contracts making ordinary calls within one Ethereum Virtual Machine (EVM) transaction. A contract sends a cross-domain message through its hub or spoke, and any response arrives in a separate message. The calls are asynchronous.

For messages leaving a private domain, the hub checks an inclusion proof against a message commitment previously accepted with the domain’s execution results. Hub and spoke contracts also prevent successful delivery of the same message twice. Messages between private domains are encrypted for their destination; messages addressed to contracts on public Monad are plaintext. Section 5.3.

This gives applications a common communication path, but builders still need to account for separate execution steps. The paper describes atomic token transfers and shows how more complex atomic operations can use coordination and locking contracts. Shared sequencing alone does not turn every cross-domain workflow into a single synchronous transaction. Introduction and section 7.

Privacy depends on the route and the operator model

The first-version attestation mechanism is multisignature approval by domain operators. Those operators can see the domain’s full state. The paper explicitly notes that one rogue operator can compromise its privacy; correctness and continued operation also depend on the committee and its signing threshold. Public sequencing does not remove those trust assumptions. Sections 6.1 and 8.

The paper explores zero-knowledge virtual machines (zkVMs), which could prove correct execution, and trusted execution environments (TEEs), which could isolate data inside protected hardware. These come with different costs and assumptions. Section 8 places hub verification of those proofs and hardware attestations in future work. Running a client inside a TEE is already possible, the authors say, but the first-version hub does not verify that the submitted result was computed there.

There is also a public-chain boundary. When tokens move through domain bridges on Monad, transfer amounts and the participating bridge addresses are visible. The planned confidential-transfer mechanism would address that exposure. Encrypted messages between domains should therefore not be described as making all cross-domain asset movement confidential. Sections 6.2–6.3 and 8.

Access controls reach inside contract execution

Restricting the interface apps use to query a domain, its RPC endpoint, is insufficient if a permitted user can deploy a contract that reads information indirectly. The design addresses both routes: authenticated RPC access and policies enforced when contracts execute.

Contract owners can attach policy contracts that decide whether a call is allowed. The paper’s ERC-20 example lets an account read its own balance and authorize additional readers. It also specifies controls for transaction receipts and logs, which could otherwise disclose information even when direct storage reads are restricted. These controls affect how wallets, applications and monitoring tools interact with a domain. Section 5.4.

What remains to be developed

The detailed first-version limits matter more than the broader possibilities outlined in the introduction. Section 8 says domain operator identities and the public encryption key cannot yet be changed. It also lists recovery mechanisms and a jurisdiction-aware data availability layer as future work. If every operator disappears, the paper warns that the domain’s state and managed funds become inaccessible.

Treasury management, institutional trading and asset management are among the paper’s application examples. They illustrate potential uses rather than named customer deployments. The conclusion also makes clear that privacy and access-control features do not themselves establish regulatory compliance. Sections 3, 8 and 9.

The white paper gives builders a more concrete design to assess: what Monad orders, what domain operators execute, what crosses the public boundary and which controls still need implementation. Deployment evidence and operational measurements remain separate questions from the publication of that design.

Sources

Key Takeaways
  • Monad sequences encrypted domain transactions; selected domain operators execute them privately.
  • The first version uses multisignature attestations, and domain operators can see the full private state.
  • Cross-domain calls are asynchronous; public token-bridge transfers still expose amounts and participating domains.
  • zkVM and TEE verification, confidential transfers, key changes and recovery mechanisms remain planned work.
monadresearchinfrastructuresecuritybuilders