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

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

Excerpt (1194 of 5620 characters). Read the whole post on the forum ↗

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?

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…

Excerpt (1196 of 1541 characters). Read the whole post on the forum ↗

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.

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…

Excerpt (1196 of 1571 characters). Read the whole post on the forum ↗

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.

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?

This makes sense. Keeping the Orchard Action circuit untouched and binding a separate audit proof to the public cmx seems like a much cleaner direction for v0.1.

I’m inclined to adopt output-only auditability initially. The audit circuit would recompute the Sinsemilla note commitment, constrain its extracted commitment to the Action’s cmx, and prove the threshold ElGamal ciphertext is consistent with the same output witness.

At consensus, we’d require a valid matching audit proof and ciphertext for every applicable output, with the proof, ciphertext, action, and committee key epoch bound together so nothing can be substituted or replayed.

That also gives us a way to version the audit circuit independently while tracking upstream Orchard/ZSA changes.

Agreed on deferring sender-side/nullifier linkage. I’d rather define a narrower, enforceable v0.1 disclosure guarantee than claim full transaction traceability without proving it.

One detail I’d like to test early is the additional proving and verification overhead from recomputing Sinsemilla for every output. Thanks for pointing us toward a cleaner boundary.

Great catch. This is an important constraint I hadn’t addressed sufficiently in the original design. You’re right that Hub → VeilRoute → Osmosis would produce a different IBC denom trace from Hub → Osmosis, so we can’t simply treat the resulting ATOM vouchers as fungible. For v0.1, I’m leaning toward preserving the complete IBC denom provenance and restricting deposits/withdrawals to explicitly registered asset paths. The shielded pool would track assets by their actual IBC denomination identity, rather than treating everything with the same base denom as equivalent. For canonical destination assets, one possible route is to unwind back through the originating chain and then forward to the destination over its canonical IBC channel. That introduces extra hops and publicly observable routing metadata, so we’d need to evaluate the UX and privacy implications carefully. I wouldn’t introduce automatic denom unification or liquidity-based conversion in v0.1. Longer term, I think this raises a broader design question: should VeilRoute be primarily a private settlement layer with explicit asset provenance, rather than trying to act as a fully transparent-to-the-user cross-chain…

Excerpt (1199 of 1431 characters). Read the whole post on the forum ↗