Opened 02-03-2026 by nlok5923, last activity 28d ago
Proposal file:
This proposal enables canton participant to bring assets from public chains to canton network privately, Post deployment users would be able to bridge their public chain liquidity privately and get access to CC and USDCx token on Canton network privately.
/proposals/Showing automated messages too. Hide bot messages
Showing 1 to 2 of 2, oldest first.
Thank you for the submission and for contributing a proposal focused on privacy-preserving cross-chain bridging into Canton.
This proposal addresses a meaningful and differentiated problem: cross-chain identity linkage at the bridge layer.
That said, several areas would benefit from clarification:
Bridges and privacy layers introduce complex trust and failure modes.
It would be important to clarify:
The institutional motivation is clearly articulated, but it would help to clarify:
The proposal includes:
It would be helpful to:
It would help to clarify:
It would be useful to define:
Overall, this is a high-potential proposal addressing a real institutional concern. Clarifying security assumptions, demand, and phased scope would be critical for evaluating feasibility and ecosystem fit.
The Canton Foundation Dev Fund is moving to Dev Fund 2.0
Thanks for making and opening a PR for your proposal. The Developer Fund is transitioning, which shifts toward RFP-scoped proposal system and clearer problem & adoption requirement framing.
Full details on Dev Fund 2.0: https://github.com/canton-foundation/canton-dev-fund/blob/main/2026-2028-strategic-roadmap.md#requests-for-proposals
To keep your proposal PR active, please update it by within the next 10 days with:
Proposals not updated by then will get their PRs closed and will not be considered for the next Dev Fund cycle.
Author: Encrypt.trade
Status: Draft
Created: 2026-03-02
encrypt.trade is building a privacy-enabled cross-chain bridge that allows institutions to move assets from Solana and EVM chains onto Canton Network without exposing their source chain identity breaking the cross-chain address linkage that currently makes institutional entry into Canton publicly traceable.
We have already demonstrated this capability in production. encrypt.trade was the first team to enable private bridging to ZCash from Solana in 2025, processing $15M+ in volume see announcement. In February 2026, we shipped encrypt.trade v2, bringing institutional-grade UX to private bridging for the first time.
Our privacy stack is built on top of Predicate for on-chain policy enforcement, ensuring all private transfers remain compliant.
This proposal funds the integration of that same architecture with Canton delivering critical infrastructure that removes a direct blocker to institutional adoption of the network.
Canton Network is purpose-built for institutional finance. Its configurable privacy model is a compelling differentiator but that privacy begins only after assets arrive on Canton.
The bridging transaction itself is public. Anyone can observe that address A on Solana sent assets, and address B on Canton received them permanently linking the two identities across chains.
For institutions managing client funds, proprietary positions, or sensitive treasury operations, this linkage is unacceptable. It prevents serious institutional participants from using Canton as a destination chain without exposing their broader on-chain footprint.
encrypt.trade solves this. We are building a production-ready, open-source, compliance-enforced privacy bridge between Solana and Canton Network.
Any institution, application, or user can use it to move assets onto Canton privately. Any Canton ecosystem developer can build on top of it as a reference implementation.
encrypt.trade operates as a two-leg privacy system. The first leg enforces compliance and breaks the on-chain identity linkage at the source chain. The second leg handles private delivery of the desired Canton token to the user's party. All compliance enforcement happens at the source chain entry point no additional compliance infrastructure is required within Canton.
Step 1: Source chain compliance check
Before any bridge intent is processed, the user's source Solana address is screened through Predicate's on-chain compliance infrastructure. Predicate integrates TRM Labs, Elliptic, and Chainalysis at configurable risk severity thresholds. This check occurs at the smart contract level not at the API or UI layer. A bad actor cannot bypass it by interacting with the protocol directly or circumventing the frontend.
User submits bridge intent with Solana source address
↓
Predicate screens address:
TRM Labs → risk score check
Elliptic → fund classification
Chainalysis → sanctions + exposure check
↓
Flagged? → Bridge request rejected. No ephemeral address generated.
No funds enter the system.
Clean? → Proceed to Step 2.
Operators can configure which risk thresholds are accepted and which are denied. New compliance providers can be added without changes to the core protocol. This gives institutions blockchain-certified proof that every counterparty initiating a transfer through the protocol has been cleared at the point of entry.
Step 2: Encrypted intent and ephemeral address generation
Once the source address clears compliance, the server generates a Turnkey-controlled ephemeral address unique to this order. The ephemeral address is policy-bound, it is authorised only for the wrapping/deposting operation and nothing else. The user sends funds to this ephemeral address, not to any bridge directly.
This is the first privacy layer: the user's source Solana address is linked only to the ephemeral address, never to their Canton destination party. The Canton party ID is encrypted and is transmitted server-side only it never appears in any on-chain data structure.
Step 3: Privacy Pool routing with randomised time delay
Once funds arrive at the ephemeral address, a randomised time delay is introduced before it gets wrapped/deposited into the Privacy Pool. This prevents timing correlation an external observer cannot link a deposit event to any downstream Canton activity by timestamp.
The Privacy Pool is the core unlinkability mechanism. Deposits and withdrawals are structurally disconnected: assets enter from the ephemeral address and exit to a separate Solving Pool address. No on-chain link exists between the two.
Step 4: Cross-chain settlement and Canton delivery
Delivery routing splits based on the user's desired Canton output token.
Path A: USDCx delivery
Solving Pool (Solana)
↓
Cross Chain Bridge (Solana → Ethereum USDC)
↓
Solving Pool (Ethereum)
↓
Circle xReserve depositToRemote()
↓
USDCx Holding → User's Canton Party
Bridge routes USDC from the Solving Pool on Solana to Ethereum via its solver network. The Solving Pool on Ethereum then calls depositToRemote() on Circle's xReserve contract xReserve mints a corresponding USDCx Holding on Canton and delivers it directly to the user's Canton party.
USDCx is a CIP-56 compliant Canton-native token backed 1:1 by USDC locked in xReserve on Ethereum. Holdings and transfers are private by default not publicly visible to uninvolved Canton participants.
Path B: CC delivery
Solving Pool (Solana)
↓
CC Bridge (directly bridges CC to user's Canton party)
↓
CC Holding → User's Canton Party
For users requesting Canton Coin, encrypt.trade routes through a dedicated bridge provider that natively supports CC token delivery to Canton.
The Solving Pool on Solana initiates the bridge, which delivers CC directly to the user's Canton party. CC's Amulet package is pre-installed on all 600+ Canton validators — making it the universally receivable token regardless of which participant node the user operates on.
Technology stack:
Privacy infrastructure for bridges not another bridge
Encrypt.trade is not building a Solana-Canton bridge. Existing bridge providers solve the transport problem. Encrypt.trade solves the bridge privacy problem and does so in a way that is composable with Canton's full token ecosystem.
Today, any institution bridging into Canton exposes their on-chain identity in the process regardless of which transport layer they use. The source address, destination party, and amount are all observable. Encrypt.trade removes this exposure entirely. Our architecture sits on top of existing infrastructure Bridge provider for cross-chain transport, xReserve for USDCx minting, a dedicated CC bridge for CC delivery — and adds the privacy and compliance layer that none of these provide individually.
Compliance-first at the source chain the right model for Canton
Compliance enforcement in encrypt.trade happens at the earliest possible point: before any funds enter the system, before bridging is even initiated. If a source address is flagged by Predicate's multi-provider compliance screening, the bridge request is rejected entirely. No funds move. No footprint is created.
This is the correct model for Canton's institutional base. A single contaminated source of funds entering a shared protocol can create regulatory exposure for every participant downstream. The enforcement at the source chain level ensures bad actors are excluded at the point of entry, protecting the integrity of every transfer processed through the protocol.
This approach also simplifies the Canton-side architecture: because compliance is fully resolved before assets approach Canton, no additional compliance infrastructure is required within Canton's internal operations. Assets land on Canton as standard CIP-56 Holdings with no encrypt.trade-specific contract layer required.
Two-token delivery covering the full Canton validator base
Canton's package vetting architecture means participant nodes must explicitly approve Daml packages for each token they wish to hold. Not all 600+ Canton validators have vetted every CIP-56 token. Encrypt.trade's delivery model accounts for this directly:
Together, USDCx and CC cover the full Canton validator base at launch. As Canton's token ecosystem matures and more nodes vet additional CIP-56 packages, encrypt.trade's delivery surface expands naturally in later milestones.
Fully permissionless USDCx path
The USDCx delivery path Bridge (which ever is supported) from Solana to Ethereum, followed by xReserve depositToRemote() — requires no partnership agreement, no third-party approval, and no solver integration beyond existing cross-chain infrastructure. Any address holding USDC on Ethereum can call depositToRemote(). This means encrypt.trade can launch the USDCx path without dependency on any external party's business development timeline.
Complementary to Canton's native privacy, not duplicative
Canton's configurable privacy governs activity within the network. Encrypt.trade addresses the orthogonal problem of cross-chain identity linkage at the entry point. Once assets land on Canton, they behave as standard CIP-56 Holdings governed entirely by Canton's native privacy model. The two systems compose together to deliver end-to-end privacy that neither achieves alone.
No new trust assumptions introduced on Canton
Encrypt.trade's privacy and compliance layers operate entirely at the bridge entry point on the source chain side. No encrypt.trade infrastructure is required within Canton's internal consensus, synchronisation, or smart contract execution. No changes to Canton's protocol are needed. Existing Canton applications and users are unaffected.
No backward compatibility impact. encrypt.trade's privacy bridge operates as an external protocol layer on top of existing Canton bridge infrastructure. It introduces no changes to Canton's protocol, DAML contracts, consensus mechanism, or existing integrations. Existing Canton applications and users are unaffected.
Milestone 1: Integration Scoping and Technical Design (2 Weeks)
Deliverables:
Milestone 2: Testnet Integration, USDCx and CC Private Bridge Live (2-3 Weeks)
Deliverables:
Milestone 3: Mainnet Launch, USDCx and CC Live (4-5 Weeks)
Deliverables:
Milestone 4: Multi-Token Expansion — cbBTC, frxUSD, and Beyond (Optional)
Deliverables:
The Tech & Ops Committee will evaluate completion based on:
Milestone 1: Integration Scoping and Technical Design
Milestone 1 is considered complete when:
Milestone 2: Testnet Integration, USDCx and CC Private Bridge Live
Milestone 2 is considered complete when:
Milestone 3: Mainnet Launch — USDCx and CC Live
Milestone 3 is considered complete when:
Total Funding Request: 572,000 CC (~$100,000 at reference price of $0.1748/CC)
Milestone 1 — Integration Scoping & Technical Design: 85,900 CC (~$15,000)
Milestone 2 — Testnet Integration: 286,000 CC (~$35,000)
Milestone 3 — Mainnet Launch & Open Documentation: 200,100 CC (~$50,000)
Project duration is under 6 months (estimated 8–10 weeks). Should the project timeline extend beyond 6 months due to Committee-requested scope changes or bridge availability delays, any remaining milestones will be renegotiated to account for significant USD/CC price volatility.
Upon release, encrypt.trade will collaborate with the Canton Foundation on:
Canton's institutional value proposition is undermined at the bridge layer. Institutions considering Canton as a settlement or DeFi infrastructure layer face a fundamental problem today: the act of moving assets onto Canton is publicly visible, permanently linking their Solana or EVM identity to their Canton identity.
For institutions that require strict separation of on-chain identities across networks, whether for regulatory, competitive, or operational reasons, this is a blocker, not a minor inconvenience.
The impact is concrete. The institutions most active on Canton today, Broadridge running $350B+ in daily repo settlements, Goldman Sachs DAP settling tokenized securities, DTCC tokenizing U.S. Treasuries, JPMorgan issuing JPM Coin natively on Canton, all have one thing in common: they cannot afford to have their cross-chain movements publicly traceable. A fund moving collateral from Solana into a Canton repo application does not want that transfer visible on-chain. A treasury desk bridging assets into Canton Swap does not want to signal its position to the market before the trade is complete. These institutions are willing to use Canton. They are not willing to be exposed in the process.
The cross-chain linkage problem is one that Canton's internal privacy model was not designed to solve, and it remains unsolved today. Even as bridge infrastructure matures, the identity linkage problem persists, it requires a dedicated privacy layer, not a better bridge. Funding both together delivers what institutions actually need: the ability to move assets into Canton without exposing who they are or where they came from.
encrypt.trade solves this. We have been building in the privacy space long enough to know what production-grade systems actually require, not just the cryptography, but the UX, the compliance layer, the edge cases, and the operational discipline to keep it running at scale. In February 2026, we shipped encrypt.trade v2, a significant UX overhaul that makes private bridging accessible to institutional users without requiring them to understand the underlying mechanics. Private bridging that only works if you're a developer is not a real product. v2 closes that gap.
The architecture itself has already been proven in production. We were the first team to enable private bridging to ZCash from Solana in 2025, processing $15M+ in volume. That track record matters, it means the Canton integration is not a research project, it is an extension of a system we have already built, shipped, and scaled. Bringing this to Canton removes a direct blocker to institutional adoption, expands Canton's addressable market, and ensures that the privacy Canton offers internally is accessible from the moment an institution first enters the network.
Why a privacy wrapper on top of the bridge, rather than modifying the bridge itself?
Modifying any underlying bridge would require coordination with external teams and introduce delays and dependencies outside our control. A privacy wrapper is composable, deployable independently, and reusable across multiple bridge providers — which is exactly the kind of shared infrastructure the Canton Development Fund is designed to support. It also means the Canton ecosystem benefits from this privacy layer regardless of which bridge ultimately wins adoption.
Why Predicate for compliance?
Predicate provides programmable, on-chain policy enforcement that is already designed for the institutional DeFi context. Rather than building a bespoke compliance layer, integrating Predicate gives institutions configurable access control rules they can audit and customize, aligned with Canton's own compliance-first positioning.
Rishabh Gupta — CEO & Co-Founder
Nitanshu Lokhande — CTO & Co-Founder
Track record:
Rebuilt from the recorded board moves (complete history). get_dev_fund_lifecycle(number) gives the same in the MCP.