Shadow swap

Project Co-builder: Goodness Kolapo

ShadowSwap

• Problems Solved The Privacy Crisis in Cross-Chain DeFi: -Current cross-chain bridges expose every transaction detail on-chain: who’s swapping, how much, and where funds are going. This creates:

• Surveillance Risk: Governments, analytics firms, and bad actors can track your entire financial history

• MEV Exploitation: Bots front-run large swaps, extracting value from users

• Security Threats: Visible wealth makes users targets for phishing, hacking, and physical attacks / robbery.

• Financial Censorship: Transparent transactions enable blacklisting and freezing of funds.

What ShadowSwap Enables:

1. True Financial Privacy Across Chains

• Swap STRK ↔ ZEC without revealing your identity, transaction amounts, or linking deposits to withdrawals
• Break chain analysis by mixing Starknet’s transparent L2 with Zcash’s shielded pools
• Use stealth addresses so even your counterparty can’t identify you

2. Protection from MEV & Front-Running

• Hidden transaction amounts prevent bots from profiting off your trades
• Batch processing in anonymity pools eliminates timing-based exploitation
• No more watching your large swap get sandwiched by malicious actors

3. Financial Freedom in Oppressive Regimes

• Activists, journalists, and dissidents can move funds cross-chain without government surveillance
• No KYC requirements—access DeFi as a human right, not a privilege
• Censorship-resistant: fully decentralized with no single point of failure

4. Safer Private DeFi on Starknet

• Unlocks privacy-preserving lending, trading, and yield farming on Starknet L2
• Low transaction costs (Starknet scalability) + strong privacy (Zcash shielded pools)
• Users control disclosure—reveal transaction details for compliance when needed, hide them when desired ============================

Zcash HTLC Builder Problems Solved: The Complexity Barrier in Privacy Development Building atomic swaps on Zcash requires:

• Deep understanding of UTXO models, Bitcoin scripting, and Zcash consensus rules
• Manual construction of hash time-locked contracts (500+ lines of cryptographic code)
• Handling Sapling/Orchard shielded pool integration
• Managing transaction signing, witness generation, and script validation
• Preventing fund loss from bugs in consensus rule implementation

Result: Only elite cryptographers could build privacy protocols. Innovation stalled. What Zcash HTLC Builder Enables

1. Democratizes Privacy Protocol Development.

// Before: 500+ lines of error-prone cryptographic code
// After: 10 lines with built-in safety
let htlc = HTLCBuilder::new()
    .hash_lock(hash)
    .timelock(block_height)
    .recipient(shielded_address)
    .build()?;

• Developers without expert-level crypto knowledge can build atomic swaps
• Type-safe API prevents common bugs that cause fund loss
• Abstracts Bitcoin 0.29 transaction complexity into simple function calls.

2. Advanced Infrastructure.

• PostgreSQL persistence: Track HTLC state across application restarts
• Block explorer integration: Query UTXOs without running a $10K+ full node
• CLI tool: Test HTLCs in minutes, not days of debugging Automatic error handling: Meaningful messages instead of cryptic consensus failures

3. Makes Cross-Chain Privacy Accessible

• Shielded pool support: Build privacy-preserving bridges (like ShadowSwap) without manual Sapling/Orchard integration
• Trustless atomic swaps: Both chains settle or neither does—no centralized escrow needed
• Time-lock safety: Automatic refunds if counterparty disappears (no fund loss)

4. Eliminates Security Risks

• Zero unsafe code: No memory corruption or undefined behavior
• Battle-tested primitives: Uses official zcash_primitives and Bitcoin 0.29 libraries
• Comprehensive test suite: Catches consensus violations before deployment
• ZIP-300 compliant: Follows Zcash standards for proper HTLC implementation

For Protocol Developers:

• Build trustless cross-chain bridges (Starknet ↔ Zcash, Ethereum ↔ Zcash)
• Create privacy-preserving DEX aggregators Implement submarine swaps for Lightning-style privacy layers

For DeFi Projects:

• Add private cross-chain liquidity to existing platforms
• Enable shielded lending/borrowing with atomic liquidations
• Build privacy-first payment processors

For Researchers:

• Prototype novel HTLC designs without reimplementing Zcash primitives
• Test cross-chain privacy mechanisms in sandbox environments
• Benchmark performance across different anonymity set sizes

Impact: From Months to Minutes of integration.

ShadowSwap - Challenges & Solutions

1. Starknet-Zcash Cryptographic Incompatibility

Problem:

• Starknet uses Poseidon hashing (STARK-friendly) while Zcash uses SHA256. Cross-chain proof verification seemed impossible without trusted intermediaries.

Solution:

• Implemented a dual-hash commitment scheme—Poseidon for Starknet Merkle trees, SHA256 for HTLC preimages. The HTLC secret serves as the bridge, verifiable on both chains without breaking native cryptographic assumptions.

2. Poor Zcash Tooling Problem:

• No production-ready libraries for building HTLCs on Zcash.

The ecosystem had:

• No shielded pool HTLC examples
• Sparse documentation on transparent HTLC construction
• Zero Rust libraries for atomic swap primitives

Days of Searching:

• Scoured GitHub for 3+ days, found only abandoned repos and incomplete prototypes
• Tried adapting Bitcoin HTLC libraries → failed due to Zcash consensus rule differences (Overwinter/Sapling/NU5)
• Attempted manual script construction → hit cryptic RPC errors with no stack traces

Solution:

• Built Zcash HTLC Builder from scratch using Bitcoin 0.29 + official zcash_primitives. Became the tooling we couldn’t find.

3. Merkle Tree State Synchronization Problem:

• Starknet’s anonymity pool required efficient Merkle tree updates. With 10K+ deposits, on-chain insertions cost 500K+ gas per operation.

Solution:

• Implemented off-chain Merkle tree computation with on-chain root verification
• Used sparse Merkle trees (only store non-zero leaves)
• Batch insertions: 100 deposits → single root update (99% gas savings).

4. Nullifier Double-Spend Prevention Problem:

• Without proper nullifier tracking, malicious users could withdraw from anonymity pool multiple times using the same deposit.

Solution:

• Stored nullifiers in on-chain mapping (nullifier → spent status)
• Used Poseidon hash(secret, leaf_index) as nullifier
• Added nullifier to withdrawal proof requirements (enforced by smart contract).

5. Shielded Address Validation Hell Problem:

• Zcash has 4 address types (t-addr, zs-addr Sapling, zu-addr Orchard, zec-addr legacy). Library crashed on:
• Wrong network prefix (testnet vs mainnet)
• Invalid checksums
• Mixed address types in same transaction

Solution:

• Added comprehensive address parsing with zcash_address crate
• Network validation at config level (reject mainnet addresses on testnet).

6. The Testnet Wallet Problem (48 Hours of Frustration) Problem:

• Needed to test HTLC transactions on Zcash testnet. Could not find a single working testnet wallet.

The Search:

• Official Zcash wallets: Only support mainnet.
• Zcash Full Node: Requires syncing 50GB+ blockchain (3+ days on our internet)
• Web wallets: All defunct or abandoned (zecwallet returned 404)
• Mobile wallets: None with testnet toggle

Attempted Workarounds:

• Tried running zcashd full node → 72+ hour sync time, kept crashing and slow sync.

Had to test HTLC creation. No wallet. No testnet coins. Library code ready but untestable.

Final Solution:

• Built testnet wallet functionality into the library itself

// Added key generation + raw transaction signing
let privkey = client.generate_privkey();
let address = client.derive_address(&privkey)?;

// Fund via testnet faucet (manual browser step)
// Then use library's signing directly - no wallet needed
let tx = client.create_htlc(...).await?;

Additional Hacks:

• Created CLI commands for key management (zcash-htlc-cli keygen)
• Added address derivation from private keys
• Built transaction broadcasting directly via RPC (bypassed wallet entirely)

Why This Matters:

• Exposed critical ecosystem gap: Testnet tooling practically non-existent.
• Inspired self-sufficient Zcash htlc builder library: Developers don’t need external wallets anymore (when tests are finally completed and officially released). -Improved security: Users can test with their keys, no wallet import needed.

Ironic Win: The lack of testnet wallets forced us to build lower-level primitives that made the library more powerful. Now developers can:

• Generate keys programmatically
• Sign transactions in code
• Integrate HTLCs without wallet dependencies