On November 3, 2026, Category Labs announced publication of its technical white paper on private execution domains, shared sequencing, cross-domain messaging and configurable access controls. The incremental news is the specification: Category Labs had introduced the design on October 6, 2026. Our earlier explainer covers that proposal. This update examines how encrypted activity enters a public ordering system, and what a prospective perpetual futures implementation would need to demonstrate. Publication should not be treated as evidence that a confidential perp application has launched or that its liquidation rules have been tested.

Why It Matters

The paper describes designated operators running private domains rooted in Monad; users encrypt domain transactions and wrap them in ordinary network transactions addressed to a hub contract. The hub queues those transactions, Monad supplies their shared ordering, and domain operators pull them for private execution. Public sequencing therefore need not expose the transaction contents. However, operators can read confidential execution, state and transactions in the baseline design, while alternative implementations can restrict operator access too. Access policies govern permitted disclosure, and the domain configuration specifies operators and restrictions that authorized parties can change. For a trader, our interpretation is that privacy requires examining who sees positions, who can change permissions and what evidence supports the chosen implementation. Public ordering should not be mistaken for public visibility into private balances, or for a guarantee of identical operator trust assumptions across domains.

After execution, operators submit attestations alongside state and message roots for the hub to verify; the hub checks message inclusion proofs and replays before routing messages. Cross-domain calls are asynchronous, and messages destined for another private domain are encrypted. In our reading, shared ordering helps coordinate activity but does not establish simultaneous completion of a multi-step trading workflow. A prospective perp builder would need to explain when collateral becomes usable, how pending messages affect margin and how a failed or delayed leg is handled. There is also a privacy boundary: the paper says asset movements on the public network expose transferred amounts and the sending and receiving domains, and describes shielded pools and confidential transactions as next-release protections. Those protections should be treated as planned. An inventory hedge using public liquidity could therefore reveal information even when the originating position stays private; users should examine the actual route before assuming equivalent confidentiality throughout.

For traders and liquidity providers, our proposed diligence starts with liquidation visibility: which authorized actors could observe margin deterioration, obtain reference prices and execute a liquidation? What records could a trader or auditor inspect afterward? For liquidity providers, the parallel question is whether access to inventory and exposure data would be sufficient to assess risk without exposing individual customer positions. These are implementation questions, rather than demonstrated controls in a launched perp product. Timing deserves scrutiny too: the specification lets the hub apply backpressure when a domain processes too slowly. Builders should explain how a proposed margin engine would handle delayed processing, queued collateral updates and asynchronous hedge messages during stress. Our takeaway is to request documented access policies, liquidation procedures, inventory reporting and delay handling before allocating capital. Confidential execution could reduce position exposure, but the risk assessment still depends on who can act, what they can verify and when their actions take effect.

Go deeper

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.