Privacy vs speed: four profiles, one pipeline

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

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 was a boundary they could declare, enforced before a transaction enters the network.

Declaring a privacy preference

The Retail Privacy Preference is an opt-in, per-participant, on-chain declaration of the minimum privacy level the network must enforce on transactions sent to that participant. It is receiver-side. It does not change how anyone encrypts their own outgoing transactions; it changes what the network will deliver to someone who has raised their boundary.

There are four levels. Accept-all is the default and behaves exactly as the network does today. Reject-plaintext requires senders to apply a named redaction policy. Require-encrypted requires the payload to be encrypted under a named ABE policy or carried as FHE ciphertext. Require-ZK-proof adds a verified proof of correctness against a named circuit.The privacy gradient

0

Accept allDefault. Any transaction, plaintext included, is delivered.

1

Reject plaintextSenders must apply the recipient’s named redaction policy.

2

Require encryptedPayload under the named ABE policy, or carried as FHE ciphertext.

3

Require ZK proofEncrypted, plus a verified proof against the named circuit.Preference types

type PrivacyLevel uint8

const (
    AcceptAll        PrivacyLevel = iota // default
    RejectPlaintext                      // sender must redact per policy
    RequireEncrypted                     // ABE policy or FHE ciphertext
    RequireZKProof                       // encrypted + verified proof
)

type PrivacyPreference struct {
    Participant          [32]byte
    Level                PrivacyLevel
    RedactionPolicyID    string
    ABEPolicyID          string
    ZKCircuitName        string
    ExpiresAt            time.Time   // zero = no expiry
    DeclarationSignature []byte
}

Enforced at the door

The preference is stored in a participant registry next to the participant’s declared device class, because device capability determines which levels a participant can honestly use. Declaring a preference is a single signed transaction; the registry emits an event so indexers and wallets can see it.

Enforcement happens at JetRay admission, in a new step that runs after peer and capacity checks. If the recipient has declared anything other than accept-all, the admission controller checks the transaction’s metadata against the declared policy. A transaction that does not meet it is rejected before it enters any lane.

Rejections are explicit. The sender receives a message naming the recipient, the requirement and the policy to apply, for example that plaintext is not accepted and the transaction should be redacted under a given policy. To avoid wasted submissions, wallets can query the recipient’s declared preference in advance, or call a pre-flight check that runs only the preference step and returns the same error a real submission would.Preference check at admission

01Sender submitsA transaction addressed to a recipient

02Preference lookupJetRay reads the recipient’s declared level

03Policy checkMetadata compared with the named redaction, ABE or circuit policy

04Reject or admitRejected with the requirement named, or admitted to its laneAdmission step

if pref, ok := registry.Preference(req.Recipient); ok && pref.Level != AcceptAll {
    if err := enforcePreference(req, pref); err != nil {
        return Reject("privacy_preference", err)
        // "Recipient 0x... has declared a privacy preference:
        //  plaintext transactions are not accepted.
        //  Please redact your transaction per policy <id>."
    }
}

What changes downstream

Most of the pipeline is unaffected. Capacity grants filter quantity, not content. Ordering and routing operate on hashes and identifiers. Consensus never sees a rejected transaction because the check runs before it.

The higher levels do change execution. Require-encrypted enables FHE hooks for the recipient’s workloads and implies ABE-encrypted availability blobs. Require-ZK-proof makes a verified proof mandatory before the State Transition Unit is sealed. There is one place where the mechanism crosses from receiver to sender: a recipient who requires encryption causes the sender’s lane to be delegated to FHE-capable workers, overriding the sender’s default of local execution.

In the explorer, a recipient who rejects plaintext will never appear as the recipient of a plaintext transaction, because none will be admitted. The preference itself is an on-chain record and is public.

Moving along the gradient

A participant can move one step at a time. Reject-plaintext is the cheapest upgrade, because redaction is a hash or mask transform rather than cryptography. Require-encrypted requires holding a matching ABE key or appointing a delegate. Require-ZK-proof is the most expensive and is expected to be rare for retail. Each step, up or down, is a single transaction, and an expiry date allows a temporary boundary, for instance during a sensitive payment, without a second transaction to revert it.

The mechanism closes the only gap in the matrix by reusing primitives the network already has: redaction, attribute-based encryption and zero-knowledge proofs. Retail users can move toward stronger privacy without changing lanes, changing devices or buying an SLA, and the rest of the network does not slow down to accommodate them.