Back to projects
Barter Swap icon

Barter Swap

Cross-Chain Escrow Based Bridge

$3,000
Total awarded
Barter Swap
Anuj
Builder
Node.js Go REST API Docker SQLite Rust TypeScript

Awards

The problem it solves

This project enables atomic swaps between Mina and Zcash bridging a programmable smart contract chain with the most private cryptocurrency that doesn’t support smart contracts.

Privacy-First Escrow for Zcash

Zcash lacks programmable logic for escrow. Traditional solutions require wrapped tokens with trusted custodians or centralized exchanges that destroy privacy. This system uses ephemeral escrow instances that preserve Zcash’s shielded architecture: sealed keys per-trade (each swap gets a dedicated instance starting at port 9000), lightwalletd-only detection (escrow addresses never touch zcashd), and minimal metadata leakage (only encrypted memo fields on-chain).

The middleware coordinates atomically: both MINA deposit (on-chain zkApp verification) and ZEC funding (off-chain shielded note detection) must succeed before locking. No bridges, no wrapped tokens, no custody risk.

Mina + Zcash: The Perfect Privacy-Programmability Alliance

Mina is the world’s most advanced ZK-native blockchain the entire chain is a single ~22KB recursive proof. This makes it uniquely positioned to handle privacy-preserving cross-chain logic that other platforms can’t match.

For Mina users: Finally access real privacy without centralized exchanges. Trade MINA → ZEC and hold funds in Zcash’s battle-tested shielded pools. Mina’s zkApps provide programmable guarantees, Zcash provides transaction privacy together they offer what neither can alone.

For Zcash users: Access Mina’s rich zkApp ecosystem (DeFi, NFTs, identity protocols) without abandoning privacy. Exit to shielded ZEC anytime via swaps. This is Zcash’s gateway to programmable smart contracts while maintaining shielded transactions.

This lets Mina spread its wings into privacy-enabled value transfer not just privacy in computation (zkApps already do this), but privacy in cross-chain swaps. Mina proves it can bridge transparency and opacity better than any EVM chain.

POC Simplifications vs. Production Potential

The current POC uses shortcuts for rapid testing: unified operator token across all trades, simple sequential port allocation, and a single middleware instance. Production-ready architecture would enable per-trade cryptographic API keys, distributed middleware (anyone can run the polling coordinator), multi-signature operator controls, and enhanced memo encryption schemes.

With proper implementation, this could become the leading escrow service for Zcash offering smart contract guarantees (timeouts, refunds, conditional claims) to a chain that fundamentally can’t support them natively.

Beyond Mina: Blockchain-Agnostic Design

While built with love for Mina’s zero-knowledge architecture, the middleware is fundamentally blockchain-agnostic. Any chain exposing queryable endpoints or RPCs can integrate. Replace the Mina client with Ethereum RPC, Solana JSON-RPC, or Bitcoin electrum servers the escrowdv2 ZEC side remains unchanged. This is a privacy-preserving escrow protocol, not a Mina-only bridge.

Challenges we ran into

The single biggest time sink was zcashd and lightwalletd syncing. Before I could even start testing atomic swaps, I had to wait hours for initial blockchain sync. This wasn’t a one-time setup either — every configuration change, every parameter tweak meant restarting services and praying they’d sync correctly. Most of my development time wasn’t spent writing code; it was spent figuring out what works and what doesn’t through endless docker exec and curl trial-and-error sessions.

The documentation around Zcash RPC is sparse and scattered. Simple questions like “do I use account numbers or addresses in z_sendmany?” required reading through GitHub issues from 2019. The AllowRevealedAmounts privacy policy error? Only discovered after multiple failed transactions and diving into zcashd source code. Every curl command in CURL.md represents hours of debugging.

Then came the worst possible timing: during the final days of the hackathon, lightwalletd completely corrupted. The database became unreadable, the service refused to start, and there was no way to recover it. I had to nuke everything and rebuild from scratch — full blockchain resync, full wallet rescan, hours of waiting while the submission deadline approached. This meant re-testing the entire escrowdv2 funding verification flow when I should have been polishing features.

Mina Compilation Delays

On the Mina side, the challenge wasn’t infrastructure — it was compilation speed. Every single change to the smart contract or offchain state required 2-3 minutes of recompilation before I could even know if my fix worked. Debugging became agonizingly slow: write one line, wait 3 minutes, see it fail, repeat. This isn’t a Mina flaw (ZK circuits are complex), but it turns rapid iteration into a patience test.

The offchain state settlement proofs added another 5-6 minutes per test cycle. When you’re hunting a bug that requires multiple contract calls to reproduce, you’re looking at 15+ minute feedback loops. Traditional smart contract development gives you sub-second compilation; zkApps demand planning every change carefully because you won’t know if it works until you’ve waited long enough to make coffee.

The Breaking Point

There was a moment — somewhere around 3 AM during the final 48 hours — where everything failed simultaneously. Middleware couldn’t connect to escrowdv2. Port allocation was throwing collisions despite the allocator showing free ports. ZEC transactions were getting mined but escrowdv2 wasn’t detecting them. Mina settlement proofs were timing out. The logs made no sense. Every fix broke something else.

I genuinely considered scrapping the entire integration and submitting a simplified mock version. The circular debugging was maddening: fix the port allocator, breaks the API key flow. Fix the API keys, now lightwalletd can’t find the notes. Fix the memo encoding, now zcashd rejects the privacy policy. It felt like playing whack-a-mole with a system that actively resisted coherence.

The solutions however came from a pretty popular term “KISS”: unified operator token (no per-trade key generation), sequential port allocation (no hash-based logic), and accepting that the POC doesn’t need production-grade complexity. Once I stopped fighting the architecture and embraced “make it work first, optimize later,” the pieces finally clicked. But those dark hours of everything failing taught me more about distributed system debugging than any tutorial ever could.

Finally, there’s still a lot to be done, things to be fixed, but I am pretty happy with what I have with me right at this moment. And no one can take that from me.

Bonsoir Elliot.