[Discussion] VeilRoute: An IBC-Native Confidential Routing Chain with Threshold-Governed Disclosure

Conversation
1

Hey Cosmonauts,

I’ve been exploring an idea for a privacy-focused Cosmos SDK chain and wanted to bring it here before going too far into implementation.

The idea is called VeilRoute — a sovereign Cosmos blockchain that acts as a confidential settlement and asset-routing layer between IBC-connected chains.

The problem I’m interested in is relatively simple:

Cosmos has interoperability through IBC, but what if applications could route assets through a common privacy layer without publicly exposing every internal transfer, amount, balance, or ownership relationship?

I’m not proposing changes to the Cosmos Hub or requesting governance funding. This is an early architectural discussion to get technical feedback from people working on Cosmos SDK, IBC, ZK systems, and interchain security.

1. The idea

Imagine a user moving ATOM from Cosmos Hub to Osmosis.

Today, the public source and destination transactions are observable, along with the relevant IBC packet information.

With VeilRoute, the proposed flow would be:

Cosmos Hub / Other IBC Chain
              |
         IBC Deposit
              |
              v
       +---------------+
       |   VeilRoute   |
       |               |
       | Shielded Pool |
       | ZK Validation |
       | Private Notes |
       | Audit Records |
       +---------------+
              |
         IBC Withdrawal
              |
              v
      Destination IBC Chain

Users would deposit an IBC asset, shield it into a private note-based pool, make confidential internal transfers, and eventually withdraw it to another IBC-connected chain.

Internally, validators would verify zero-knowledge proofs without knowing the private transfer amounts or recipients.

One important limitation: VeilRoute would not make public-chain deposits and withdrawals invisible. Timing, amounts, asset types, and IBC metadata could still allow an observer to correlate transactions.

The initial objective is confidential internal settlement, not a claim of perfect cross-chain anonymity.

2. Why another privacy chain?

I’m aware that Cosmos already has serious privacy-focused work, particularly Penumbra and Namada.

I’m not trying to reinvent their cryptography.

What I’m interested in exploring is a routing-focused system that combines:

  • IBC-native asset deposits and withdrawals.
  • A common shielded settlement layer.
  • Reusable SDKs for wallets and Cosmos applications.
  • Public verification of private state transitions.
  • Threshold-controlled disclosure of selected transaction records.

The last point is a significant architectural difference I’d like to discuss.

3. Threshold-governed visibility

Instead of allowing one chain operator to inspect all transactions, VeilRoute would use a distributed disclosure committee.

For example, five independent committee members with a three-member decryption threshold.

The intended properties are:

  • Validators cannot see ordinary private transaction details.
  • Individual committee members cannot decrypt audit records.
  • A threshold of authorized committee members can reveal defined transaction information.
  • Committee members do not possess users’ spending keys.
  • Disclosure requests and approvals can be recorded publicly.

The audit ciphertext must be cryptographically bound to the same private witnesses used in the transaction proof. Otherwise, a malicious user could submit a valid private transfer alongside a misleading audit record.

I recognize that threshold disclosure introduces a meaningful trust assumption. Three colluding members could potentially decrypt information outside an officially approved workflow. An on-chain approval log alone cannot cryptographically prevent that.

The question is whether this privacy/accountability trade-off is useful for certain interchain applications, institutional use cases, or compliance-sensitive environments.

4. Tentative architecture

I’m considering a Cosmos SDK appchain with the following components:

Component Responsibility
x/shielded Note commitments, nullifiers, ZK proof verification
x/gateway IBC asset deposits and custody accounting
x/withdrawal Proof-authorized exits, packet tracking, failure recovery
x/disclosure Audit ciphertext commitments, threshold key epochs and approval records
x/assetregistry Accepted assets, IBC denominations and route policies

The cryptographic client and proving components would be written in Rust, while consensus-critical state transitions would be integrated into the Cosmos SDK application.

I would prefer adopting an existing reviewed shielded protocol rather than building new note commitments, circuits or proving systems from scratch.

5. What v0.1 could look like

For an initial proof of concept, I’d keep the scope deliberately limited:

  1. One supported IBC test asset.
  2. Deposits into a shielded pool.
  3. Private transfers using note commitments and nullifiers.
  4. Client-side proof generation.
  5. Proof-authorized public withdrawals.
  6. Three-of-five threshold disclosure for proof-bound audit records.
  7. Asset-conservation, double-spend and IBC timeout/recovery tests.

The goal would be a working research devnet, not an unaudited production launch.

6. Open design questions

This is where I’d particularly appreciate feedback.

1. Should VeilRoute be a sovereign chain at all?

Would this architecture benefit from its own consensus and state machine, or would building on an existing privacy chain with IBC functionality

1 Like
2

Nice write up, and good call keeping v0.1 a research devnet on a reviewed shielded protocol. Two custody things I’d pin down early.

On an IBC timeout or error ack the withdrawal needs a refund path, and if it lands on a transparent address it leaks the link you’re hiding; committing to a refund note in the withdrawal proof avoids that.

And with amounts hidden, a per denom deposits-minus-withdrawals counter in x/gateway (like Zcash’s ZIP 209) caps a circuit bug at draining the pool instead of minting assets.

Which shielded protocol are you leaning towards?

1 Like
3

Thanks, these are both excellent points.

Agreed on the refund path. I’m leaning toward committing to an owner-controlled shielded refund note as part of the withdrawal proof, so an IBC timeout/error acknowledgment can restore funds without exposing a transparent refund address. We’d need to ensure that successful acknowledgments and refunds are mutually exclusive and that recovery can only be claimed once.

The ZIP 209-style accounting suggestion also makes sense. I think x/gateway should maintain consensus-enforced, per-denom public value balances, including pending withdrawals and IBC refunds. That gives us an independent backing constraint even if a proof/circuit bug creates invalid shielded value internally. It doesn’t eliminate the risk of draining legitimate pool assets, but it limits the damage.

On the shielded protocol, I’m currently leaning toward Penumbra’s multi-asset shielded pool as the starting point, primarily because of its existing Cosmos/IBC architecture, note commitments, nullifier model, and Rust implementation.

I’d also like to evaluate Zcash Orchard’s proof and value-conservation design before committing.

The main research question is whether we can extend an existing shielded protocol with threshold-encrypted audit records that are cryptographically bound to the same transaction witnesses, without compromising the existing privacy and soundness properties.

Have you worked with Penumbra’s cryptographic stack, or do you think Orchard would be a better foundation for that extension?

1 Like
4

Glad the refund note fits. From a review point of view, the biggest difference for your extension is the proof system. Penumbra’s circuits are Groth16 on BLS12-377, so adding the audit ciphertext constraint means new circuits and a new setup ceremony for them.

Orchard is Halo 2 with no trusted setup, so changing the circuit is cheaper, but it’s single asset today and you’d be building on the Zcash Shielded Assets work (ZIP 226/227) to get multiple denoms.

Either way I’d pick a disclosure scheme that’s native to the proof’s curve, like ElGamal on decaf377 for Penumbra or on Pallas for Orchard. Proving the ciphertext matches the witness stays cheap that way, and threshold ElGamal with a DKG gives you the 3 of 5 committee without a trusted dealer.

5

That’s a really useful distinction, especially the setup implications of extending Penumbra’s Groth16 circuits.

I’m reconsidering my initial Penumbra preference. Its existing multi-asset architecture and Cosmos integration are attractive, but since threshold-auditable encryption is central to VeilRoute, the ability to iterate on the circuit without repeated trusted setup ceremonies makes Orchard/Halo 2 worth prioritizing for the initial cryptographic PoC.

I like the curve-native ElGamal approach too. The first experiment could focus on proving that a threshold-encrypted audit record is consistent with the same note values and recipients used in a valid shielded transfer, while ensuring the committee has no spending authority.

For now, I’m thinking:

  • Penumbra: reference architecture for multi-asset shielded accounting and Cosmos integration.

  • Orchard/Halo 2: primary candidate for prototyping audit-consistency constraints.

  • ZIP 226/227: evaluate as the multi-asset extension, including their maturity and implementation status.

  • Threshold ElGamal + DKG: candidate disclosure design, with independently held shares and proof-verifiable decryption.

One thing I’m particularly interested in is whether we should implement audit encryption constraints directly inside the existing spend/output circuit or use a separate proof tied cryptographically to the same commitments.

Do you think modifying Orchard’s Action circuit is the cleaner approach, or would a separate audit-consistency proof reduce the maintenance and security risks?

6

I’d keep the Action circuit untouched and use a separate proof. Every output already exposes cmx, and the note commitment is binding, so a second circuit that takes cmx as a public input, opens it to the same note (address, value, rho, psi and rcm), and proves the ElGamal ciphertext encrypts those is tied to the same note without touching the reviewed circuit.

You pay for recomputing the Sinsemilla commitment, but you can version the audit circuit with the committee key epochs and rebase on upstream Orchard or ZSA changes without re-reviewing a forked Action.

Two things to watch: consensus has to reject any action whose cmx has no matching audit proof, and binding the sender side means proving the nullifier derivation too, so I’d keep v0.1 to outputs.

7

Hi! Thanks for the writeup!

One question. IBC has path dependency requirements for asset transfers today. So in your example above, ATOM sent from the Cosmos Hub > Osmosis will not be fungible with ATOM sent from Cosmos Hub > VeilRoute > Osmosis.

How would you plan to navigate that?