Research

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 […]

A high-frequency trader and a government agency need very different things from the same network. Cubane lets each profile choose its privacy level at every layer, and gives retail users a way to refuse plaintext at the door. One policy does not fit Every confidential-compute system faces the same tension. Encryption, proofs and access control cost time. The more of them a transaction carries, the longer it takes to reach finality. The simplest response is to choose one global policy, encrypt and prove everything, and accept the resulting latency floor for every user. Cubane does not do that. The pipeline is compositional. Each layer offers a short menu of privacy levels, and a participant’s profile selects one option from each menu. A market maker on datacentre hardware and a clerk on a government workstation use the same pipeline but take different paths through it. This article looks at four profiles (HFT, government, enterprise and retail), what each one trades at each layer, and the one gap the matrix exposed. It ends with the mechanism we designed to close that gap. Where the cost lives Not every layer forces a trade. Admission is effectively free for everyone. Ordering, routing and consensus cost about the same whether a payload is public or encrypted, because they operate on hashes, identifiers and proofs rather than contents. The quorum that finalises a high-frequency batch is the same quorum that finalises a confidential disbursement. The cost concentrates in a few places: whether execution runs homomorphically, whether a zero-knowledge proof is generated, whether data-availability blobs are encrypted under an access policy, and whether work is delegated to specialised workers. These are the knobs that the profiles turn.Choice points along the pipeline 01 Ingress and admissionLane selection. Plaintext at the wire for all profiles; senders may encrypt contents beforehand. 02 Capacity grantOpen lanes need none; permissioned topics require a signed capacity grant. 03 Ordering and schedulingSame deterministic function for everyone. Operates on hashes, so payload type does not matter. 04 ExecutionLocal plaintext execution, or delegated FHE execution over ciphertext. 05 ProofsNone, overlapped proofs of correctness, or mandatory proofs of the state transition. 06 State Transition UnitPlaintext or ABE-encrypted availability commitment; placeholder or real proof. 07 Explorer and availabilityFull public fields, redacted fields, or ABE-gated blobs. HFT: speed first High-frequency participants value latency above confidentiality. They submit through the priority lane, often in large batches, and keep payloads in plaintext. Execution runs locally, with homomorphic hooks off. Where a proof of correctness is needed, it is delegated to GPU and proving workers and overlapped with the following tick so it stays off the critical path. The compromise is explicit. HFT accepts that its transaction graph is visible. The bet is that the advantage of being first outweighs the cost of visible order flow. Because ordering is computed rather than chosen, that visibility cannot be exploited by a block producer reordering around it. Government: privacy first Government participants handle sensitive or classified payloads. Latency is tolerated; leakage is not. A whitelisted sender enters the priority lane with a capacity grant scoped to a specific topic. The payload is encrypted under an attribute-based policy before it is submitted. Ordering is unaffected, since it works on hashes. Execution is delegated to workers capable of FHE, and the state transition is accompanied by a real zero-knowledge proof. Availability blobs are ABE-encrypted, so only holders of the right attributes, typically a threshold of authorised auditors, can read them. Addresses in the explorer are redacted, and aggregate queries draw down a differential-privacy budget. Government also holds control-plane powers that other profiles do not: it can pause a disputed tick pending review. The cost is a higher latency floor and no access to the cheapest paths. The gain is that payload and address graph remain hidden. Enterprise: a negotiated middle Enterprise participants want government-grade privacy for some workloads and HFT-grade speed for others, under a written service-level agreement. They submit through a dedicated enterprise lane, consuming an SLA ticket per batch. The SLA tier decides which hooks fire. Sensitive workloads, such as confidential KYC comparisons, run under FHE with mandatory proofs and ABE-protected availability. High-throughput workloads run locally. The delegation router can fall back to local execution if specialist workers are saturated, and a dispute and timelock path is available for challenging bad proofs. Where government accepts the latency floor unconditionally, enterprise negotiates it into a contract. Privacy becomes a tier choice rather than an absolute. Retail: cost first Retail participants are cost-sensitive and usually on phones or laptops that cannot run FHE locally. They use the standard lane, execute locally, and do not pay for proofs or encryption. The only privacy lever they have by default is redaction of public fields in the explorer: masking, hashing, removing or adding noise to values before display. Retail ends up with fast, cheap transactions for the same reason HFT does, keeping the pipeline mostly plaintext, but with a different motive. HFT avoids encryption because it costs milliseconds. Retail avoids it because it costs gas. HFT avoids encryption because it costs milliseconds. Retail avoids it because it costs gas. Four profiles, side by side Layer HFT Government Enterprise Retail Lane Priority Priority, whitelisted Enterprise SLA Standard Execution Local, plaintext Delegated FHE FHE or local, per tier Local, plaintext Proofs Correctness proof, overlapped State-transition proof Mandatory None Availability Plaintext blob ABE-encrypted blob ABE per tier Plaintext, redacted fields Explorer Public fields Redacted, ABE-gated Redacted, ABE-gated Redacted public fields Control plane None Pause, dispute, upgrade Dispute, timelock None The gap Laying the four profiles side by side revealed one missing capability. Retail users have no way to say: I do not want to receive plaintext, publicly visible transactions from anyone else. The standard lane is a commons. Anyone may send a plaintext transaction to anyone, and the recipient’s activity becomes visible as a result. Redaction does not solve this. It is a presentation-layer transform, applied when data is displayed, not a cryptographic guarantee about what was sent. What retail needed […]