Who sees what: visibility across the Cubane pipeline

Calling a transaction private tells you very little. The useful question is who can see which field, at which layer. A walk through the ten stages of the pipeline, the actors at each one, and the asymmetries that make the design work.

Private is not a binary

When people describe a blockchain transaction as private, they usually mean something narrow: the amount is hidden from the public, or the sender is pseudonymous. That leaves most of the real questions unanswered. Can the validator who executed it read it? Can the node that generated the proof? Can an auditor? Can the recipient’s counterparties infer it from timing or queue position?

A more useful way to reason about privacy is as a matrix. Rows are the stages a transaction passes through. Columns are the participants and infrastructure actors who touch it. Each cell says exactly what that actor can observe at that stage. This article walks through that matrix for Cubane’s pipeline.

A vocabulary for visibility

To keep the matrix precise, every cell uses one of eight terms. Full plaintext means the actor sees the field unredacted and unencrypted. Ciphertext only means the actor holds encrypted data and cannot decrypt it. ABE-gated means decryption requires a threshold of attributes under an attribute-based policy. Redacted means a policy has masked, hashed, removed or noised the field.

Proof only means the actor sees a zero-knowledge proof and its public outputs, but not the witness behind it. Hash commitment means the actor sees only a digest, such as a pool hash or an STU hash. Metadata only means the actor sees envelope fields like lane, gas and size, but not the payload. Nothing means exactly that.

The posture differs by profile. HFT and retail transact largely in public. Government and enterprise transact under ABE and, for sensitive workloads, FHE. The interesting part is how those postures play out stage by stage.Ten stages, and who sees what

01

Ingress and admissionValidator operators see admitted transactions; senders encrypt sensitive contents beforehand. Public sees nothing.

02

Capacity grantThe grant service sees grants in full; owners see their topics; others see a hash.

03

Ordering and schedulingThe engine sees the full conflict graph; users see the frozen pool hash for their tick.

04

Cube routingCube members receive only their slice. Membership is published after finality.

05

ExecutionCube members see plaintext or ciphertext depending on the workload. Public sees roots later.

06

Proof networkProving nodes see the witness for their assignment; permission gates never do.

07

State Transition UnitThe attesting cube sees all 13 fields; they become public after finality.

08

Consensus and finalityAll validators see vote tallies; anchors and checkpoints are public.

09

Public explorerEveryone sees redacted public fields; auditors with attributes see ABE-gated fields.

10

Data availabilityEveryone can verify availability; reading a gated blob needs the attributes.

At the door: ingress and capacity

When a transaction arrives at JetRay, the full payload is present, together with envelope metadata such as lane, SLA ticket, peer identity and reputation. No privacy transform has yet been applied by the network. This is the broadest point of exposure to validator operators, and it is the last point at which the general validator set sees admitted transactions before routing narrows the audience.

That is why sensitive profiles encrypt before they submit. A government sender’s payload arrives already encrypted under an attribute-based policy, so what the operator sees is the envelope and a ciphertext. HFT and retail payloads arrive in plaintext by choice.

Users see their own transactions in full, and nothing of anyone else’s payload. A priority-lane participant can infer from lane occupancy that other transactions exist, without seeing what they contain. Capacity grants for permissioned topics are visible in full to the topic owner; others see only a hash commitment. Retail and HFT, who use open lanes, never touch this layer at all.

Ordering: the first hash

At the tick boundary, the pool is frozen and replaced, for outside observers, by a hash. This is the first stage at which a commitment stands in for the plaintext pool. Users can see the frozen pool hash for their own tick and their own position in it, and nothing of other ticks.

The ordering engine, running inside the validator process, necessarily sees the full ordered list, the read and write sets and the conflict graph, because it cannot schedule parallel execution without them. For government and enterprise users, other senders’ read and write sets in the same tick are redacted, since regulated counterparties often share a tick and their state access must not leak to each other.

Execution: the cube boundary

Transactions are routed to eight-node cubes: one leader, four member nodes and three transaction inspector nodes, drawn by verifiable lottery. Each cube receives only the slice of transactions routed to it, and non-selected validators see only the cube assignment, not the contents.

Inside the cube, visibility depends on the workload. For HFT and retail transactions, the leader and member nodes see the plaintext of their slice. For government and enterprise FHE workloads, they see ciphertext and a plaintext envelope. Inspector nodes see the vote tally and the execution hash or ciphertext, rather than the full working set.

This is the core confidentiality guarantee of the design. The unit that executes and attests a confidential transaction does not need to decrypt it to do so. Government and enterprise users themselves see their own results as ciphertext and proof outputs; only the result the circuit reveals, such as a boolean match, becomes readable.

The execution unit that attests a confidential transaction never needs to decrypt it.

The audience narrows

01

Validator setAdmitted transactions at ingress; sensitive payloads already encrypted.

02

Ordering engineFull ordered list, read and write sets, conflict graph.

03

Assigned cubeOnly the slice routed to it, plaintext or ciphertext.

04

Proof nodeThe witness for its own assignment, nothing else.

05

PublicCommitments, proofs and redacted fields after finality.

The proof network has two roles

The proof generation network separates two jobs that are often combined. Proof-generating nodes produce zero-knowledge proofs and, for FHE workloads, the associated proof material. To do that they must see the witness, but only for the lanes they are assigned.

Permission-gate nodes decide whether a proof or availability blob may be released to a given requester. They evaluate the attribute policy against the requester’s attributes and see the result, granted or denied. They never see a witness. Separating the two means the actors who decide who may read data are not the actors who hold it.

After execution: STU and finality

Execution output is packaged into a State Transition Unit with 13 bound fields. The attesting cube sees all of them. Before finality, users see the STU hash and execution hash for their own transactions; government and enterprise users can see the full STU for their own transactions, including the proof and availability commitment.

After finality, the STU becomes the primary public artefact of the pipeline. Its identifiers, prior and new state roots, ordered transaction root, execution hash, circuit hash, availability commitment and proof are all published, and the proof is verifiable by anyone. Consensus adds anchors, checkpoints and vote counts to the public record. For government and enterprise users, dispute state is visible too, since both can open disputes.

The explorer and the availability layer

The public explorer reads only finalised data and applies redaction policies before serving any record. Every visitor, whatever their profile, sees the same redacted public view. The only privileged view is the auditor’s, where private fields protected by an attribute policy can be decrypted by an auditor holding a sufficient threshold of attributes. That privilege comes from the auditor’s attributes, not the sender’s profile.

The availability layer follows the same principle. Every blob is bound to a KZG commitment that anyone can check. For public transactions, the blob can be retrieved. For ABE-gated transactions, the locator is marked as redacted for unauthorised viewers and the blob remains ciphertext. The availability layer guarantees availability, not readability.

The actors, in one view

Viewed by actor rather than by stage, the pattern is consistent. Senders and recipients see their own transactions in full, plus ABE decryption where they hold the attributes, and nothing of others’. Cube members see their own slice, in plaintext or ciphertext depending on the workload, and nothing outside it. Proof generators see witnesses only for their assignments. Permission gates see policy results only. Explorer visitors see redacted public fields. Auditors see those plus whatever their attributes unlock. Governance roles see pause, dispute and upgrade state in addition to the public view.Visibility by actor

Five asymmetries

First, everyone sees their own plaintext. The differences between profiles lie entirely in what others see of your transactions.

Second, cube members see plaintext for HFT and retail transactions but ciphertext for government and enterprise FHE workloads. The execution unit can attest without reading.

Third, permission-gate nodes never see a witness. Release decisions are separated from proof generation.

Fourth, the explorer is an equaliser. Every profile gets the same redacted view, and the only privileged view depends on an auditor’s attributes.

Fifth, capacity grants are invisible to retail and HFT but central for government and enterprise. They are what make a priority lane permissioned rather than merely priced.

Reading the matrix as a designer

For anyone building on Cubane, the matrix is a design tool. It shows where data is exposed by default, where a policy changes that exposure, and what each change costs in the companion analysis of privacy and speed. A workload that only needs its amounts hidden from the public may need nothing beyond redaction. A workload that must hide its contents from the validators executing it needs FHE. A workload whose results must be checkable by regulators without being readable by them needs proofs and attribute-gated availability.

Privacy, described this way, stops being a label and becomes a set of specific, checkable statements about who sees what, where. That is the standard we hold the protocol to.