01
Shield
Deposit supported assets into a shielded vault. A unique commitment is added to the private pool.
CROSS-CHAIN PRIVACY PROTOCOL
Cross-Chain Privacy.Zero Traces.
Shield, move, and claim assets across supported networks with a privacy-first architecture built around zero-knowledge proofs and relayer-assisted claims. Designed to reduce direct public links between deposits and withdrawals.
Zero-knowledge architectureFresh-address claimsCross-chain design
Bridge assets
FromToken
$0.00
ToToken
Live quote unavailable
Recipient
RouteEthereum → Solana
Network feeShown after integration
Wallet connection, live quotes and transaction execution are not enabled in this frontend preview.
Zero-KnowledgeProof-based privacy model
Multi-chainDesigned for cross-chain flows
Relayer-assistedDestination claim architecture
Fresh-address claimsReduce direct public links
NETWORK DESIGN◆ ethereum≋ solana◉ polygon⬡ arbitrum● base
How It Works
Private transfers
in three steps.
A simple flow for users. A considered privacy architecture underneath. Each step has a distinct role in the intended transfer journey.
02
Prove
Generate a zero-knowledge proof locally to prove ownership without revealing the secret witness.
03
Claim
Request withdrawal to a fresh destination address through a relayer-assisted claim flow.
Under The Hood
One transfer,
four moving parts.
A conceptual view of how a private cross-chain transfer could move between components. Final architecture will be documented in the specifications.
⬡
Source chain
The user deposits a supported asset into a shielded vault contract on the source network.
◈
Shielded pool
A commitment joins the private pool. The direct link back to the depositor is not published.
⌘
Proof & relayer
A zero-knowledge proof is generated locally, then a relayer submits the claim on the destination.
↗
Fresh address
The destination verifies the proof and nullifier, then releases funds to a new address.
Protocol Architecture
Privacy by design.
Clear trust boundaries.
The protocol concept separates deposit commitments, local proof generation and destination claim verification.
Shielded vaults
Source-chain deposits create commitments that can be included in a Merkle tree for later proof generation.
Local ZK proving
The intended client-side prover constructs a proof without sending the private witness to a service.
Relayer & verification
A relayer can submit a claim while destination contracts or programs verify proof validity and nullifier status.
Network Design
Built for
multiple ecosystems.
Network support shown here is illustrative. Live routes should be announced only after contracts and verification are published.
Ethereum
EVM networkSolana
Solana networkArbitrum
EVM networkBase
EVM networkPolygon
EVM networkNetwork names are design examples, not a claim of deployed or supported routes.
Use Cases
Where private
transfers help.
Situations where separating public address history from a transfer can matter. Examples are illustrative.
Treasury movements
Rebalance funds across chains without publishing a direct line between a treasury and its destinations.
Contributor payouts
Pay teams on their preferred network while limiting how much payment history is linked on-chain.
Personal wallet hygiene
Move assets to a fresh address on another chain instead of reusing a long-lived, widely known one.
DAO and community funds
Support grants and distributions where recipients may not want their full wallet history exposed.
Cross-chain portfolio moves
Shift positions between ecosystems with a flow designed around proofs rather than public address links.
Merchant settlement
Receive cross-chain payments at fresh addresses to keep business and personal activity separate.
Use cases are illustrative. Always follow the laws and regulations that apply to you.
Security Model
Privacy claims need verifiable foundations.
Security depends on proof circuits, contract implementation, cross-chain message verification, nullifier handling and operational assumptions. No audit or live deployment is claimed by this website.
Why It's Different
How it differs
from a standard bridge.
A conceptual comparison of design goals. Actual guarantees depend on the final implementation and independent audits.
Topic
Typical public bridge
Chrysalis Nexus design
Deposit and withdrawal link
Publicly traceable on-chain
Designed to reduce the direct link
Receiving address
Often the same or a linked address
A fresh destination address
Ownership
Revealed by the transaction signer
Shown with a zero-knowledge proof
Claim submission
Recipient pays destination gas
Relayer-assisted claim flow
Verification
Bridge-specific trust model
Proof and nullifier checked on the destination
For Builders
Designed for integration.
Implementation guides should document the supported networks, proof system, contract interfaces and relayer requirements as these components become available.
Proof system
Document circuit design, public inputs, verification keys and reproducible proof generation.
Chain adapters
Specify per-chain vaults, asset support, messaging trust assumptions and destination verification.
Relayer interface
Define claim submission, fee handling, monitoring and failure recovery before production use.
Roadmap
Where this
is heading.
An illustrative roadmap. Milestones and order are placeholders until they are confirmed and published.
01
Concept & design
Protocol concept, threat model and interface design.
Planned02
Circuits & contracts
Proof circuits and vault contracts specified and implemented.
Planned03
Testnet
Public testing of deposits, proofs and relayer claims.
Planned04
Independent audit
Third-party review with a published report.
Planned05
Mainnet
Gradual launch of verified routes.
PlannedDocumentation
Understand the system.
Core documentation areas for the protocol. Replace these summaries with verified specifications and live links before launch.
FAQ
Questions, clearly answered.
Can I transfer assets right now?
No. This is a frontend preview. Wallet connections, live routes and on-chain transfers are not active.
Does privacy mean perfectly untraceable?
No absolute anonymity guarantee is made. Privacy depends on protocol implementation, usage patterns and the chain-specific environment.
Has the protocol been audited?
This website does not claim an audit. Any audit status should be supported by a public report from an identified auditor.
What is a relayer?
A relayer submits the claim transaction on the destination chain on the user's behalf, so a fresh address does not need to be funded from a linked wallet.
What is a nullifier?
A unique value revealed when a claim is made so the same deposit cannot be claimed twice, without revealing which deposit it came from.
Where is the proof generated?
The intended design generates the zero-knowledge proof locally, so the secret witness never leaves the user's device.
Are there fees?
Fee details are not published in this preview. Network and any relayer fees should be shown before confirmation once integration is enabled.
How can privacy claims be verified?
Claims should be backed by open specifications, public circuits and independent audits. Until those are published, treat this site as a design preview.
Chrysalis Nexus
Private cross-chain transfers,
by design.
Explore the bridge interface and the protocol concept. Wallet connection and live routes are not enabled in this preview.