# We just did a fully trustless shielded ZEC to EVM atomic swap with no new signing primitives! And yes, it is programmable **URL:** \ **Category:** General\ **Created:** [September 26, 2026, 7:55am UTC](https://forum.zcashcommunity.com/t/we-just-did-a-fully-trustless-shielded-zec-to-evm-atomic-swap-with-no-new-signing-primitives-and-yes-it-is-programmable/57827 "2026-09-26T07:55:42Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![strahncryptography](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/strahncryptography/32/46464_2.png) [@strahncryptography](https://forum.zcashcommunity.com/u/strahncryptography)\ **Post date:** [September 26, 2026, 7:55am UTC](https://forum.zcashcommunity.com/t/we-just-did-a-fully-trustless-shielded-zec-to-evm-atomic-swap-with-no-new-signing-primitives-and-yes-it-is-programmable/57827/1 "2026-09-26T07:55:42Z")
Hello everyone! As I might have indicated (non-discreetly) here before, we had been working for several weeks on a new paradigm for trustless cross-chain swaps between Zcash and Ethereum, especially shielded. The main issue was, as always, that there’s no scripting! And adaptor signatures can be frontrun and have no inherent concept of finality, yada, yada. So, we realised, and as we shared with @daira , that due to Zcash utilising a Segregated Witness based scheme (v5 ZIP-244, and more recently, ZIP 229 for Ironwood), the transaction ID itself can be predicted, and more crucially, reliably manipulated in advance to “commit” to a transaction’s intent without the transaction actually needing to happen. I have simplified a lot, but basically, after that happens, validating the transaction happened is simply a matter of SPV (we also published a paper on it which will be live soon, where we give several theorems about its security; I’ll post a rough draft soon if it’s wanted). As such, we were curious: is such a bridge possible to be built where this transaction prediction primitive could be utilised as some sort of a trustless bridge mechanism? The answer being, yes! We have deployed the Skyhook bridge contract at Ethereum Sepolia testnet: [Address: 0x027D2aDC...AD2078c6F | Etherscan Sepolia](https://sepolia.etherscan.io/address/0x027D2aDCEce9f71F76A8807f654902cAD2078c6F) We performed the first atomic swap, as follows: - Party A requested an atomic swap, advertising their pk\_d (public key) and g\_d (diversifier) to be paid at, with an order of 10,000 zatoshis for 5,000 szabo, which is an atrocious rate, but oh well: [Sepolia Transaction Hash: 0x576495882f... | Etherscan Sepolia](https://sepolia.etherscan.io/tx/0x576495882ff12fef032accda8485308aabb7f46bd993a9cf35e5050706db5d2e) - Party B (it’s the same address as party A here, but you get it) offered a proposal: they will resolve the swap for the rate as-is, without subtracting a fee: [Sepolia Transaction Hash: 0xb76aedb798... | Etherscan Sepolia](https://sepolia.etherscan.io/tx/0xb76aedb79804fd46e580a4c8b64261285235caace148c414d9328c71bfe58e00) - Party A accepted the proposal from the pool of… well, proposal: [Sepolia Transaction Hash: 0xc0c7394fd0... | Etherscan Sepolia](https://sepolia.etherscan.io/tx/0xc0c7394fd0340347fbce364da83cd1d4a26f08b1fc05c32821444fc10ba7b35c) , paying 5,000 szabo to the contract to be locked. Now, at this stage, look closely at the logs of the transaction: ![image](https://global.discourse-cdn.com/zcash/original/3X/6/e/6e022e9924ed2b22d16aa397d360a219de18b9f3.png) The proposal ID of `0xAD6268BBB8501254F9E4AEA5B3F52E43C9727D9B48D91560840537DC90083C34` is generated as a Keccak hash of the proposal details, and as such, the contract, using the arcane powers of a segregated witness, generates the transaction ID it HOPES that will exist on the chain at some point: ![image](https://global.discourse-cdn.com/zcash/original/3X/b/f/bf391991846d2372c7037ae436cfae865f74a055.png) “txid: 0x97814ade349cb35110912872e0818892943a2f148a307b120c82a3c1476a86f6” For people who work with Zcash/Bitcoin, that’s a little-endian representation. If we swap the bytes from the back to the front (such that 86f6 at the end becomes f686 in the beginning), also known as a LE-\>BE conversion or `reverse32`, we get `0xf6866a47c1a3820c127b308a142f3a94928881e07228911051b39c34de4a8197` And when we look it up on the Zcash testnet… what do we see? ![image](https://global.discourse-cdn.com/zcash/original/3X/c/5/c58d98a960868aedac8828e6a06fdd70d666fad8.jpeg) > **[Zcash Transaction f6866a47c1...4a8197 | CipherScan](https://testnet.cipherscan.app/tx/f6866a47c1a3820c127b308a142f3a94928881e07228911051b39c34de4a8197)** > > Shielded Zcash transaction in block #4,395,155 with 667 confirmations. Transparent transaction. VOILA! The transaction is here already, and it **doesn’t reveal the sender or the encrypted ciphertext!** Crucially, this is a bog-standard transaction made by a bog-standard light wallet, only it presets the psi, rho and rcm. Now, we take the block in question, `0000100c77347a67dec5dfcd0284dbe75fa978fd33b33dc45f0535492b82aacf`, and present it to the chain, again, trustlessly. This is a job done by oracles, but for illustrative purposes, we submitted it to Ethereum: [Sepolia Transaction Hash: 0x22291933ab... | Etherscan Sepolia](https://sepolia.etherscan.io/tx/0x22291933ab9a70b4c30fbf96e5abeab4839e4b90a02e0f40b6160a4f43ddeba5) ![image](https://global.discourse-cdn.com/zcash/original/3X/3/d/3d993c53a87860da9988ad97bf6f79cbabd36477.png) Ethereum has now trustlessly validated the block’s existence and verified its Equihash solution, proving the block is real. Of course, in a real scenario, we will have finality mechanisms, several of which we outlined in our paper, and will talk about later in this thread. Remember the 5,000 szabo we locked earlier? All party B has to do is present a Merkle proof that a submitted block contains the transaction that satisfies their proposal: ![image](https://global.discourse-cdn.com/zcash/original/3X/9/b/9b474d708ebe441ab05cbd1d4edbc3becccaf710.png) And the ETH is theirs! [Sepolia Transaction Hash: 0x84c89a928e... | Etherscan Sepolia](https://sepolia.etherscan.io/tx/0x84c89a928e2c76b7390c31a371e26cb1935b1eb8b767231234cecfca7f8055d1) ![image](https://global.discourse-cdn.com/zcash/original/3X/3/5/350c6dd38fcc9c4353e78beb7c47ef8bc7a154d8.png) We just did a fully trustless swap! Disclaimer: these were not wrapped in zero-knowledge proofs, and as such, the blinding factors required to generate cmx were made public. While they still do not deanonymise you, fear not, we are diligently working to make them into NIZKs (via BLS12-381 Groth16), but this serves as a nice proof-of-concept! # B-but Strahn, is this just swaps? Adaptor signatures can do the same thing! I want more! Aha, one would think that… but you would notice a curious detail, namely, remember that when party A placed their order, they simply advertised their pk\_d and g\_d, and did not have to sign anything? That’s it! Using this primitive, it is possible to commit to transactions to an address and prove that it was included without actually revealing who you are! That means that it is possible for OTHER contracts to include the bridge and verify receipt of shielded transactions to a given address, which can be multisig (FROST comes to mind?) That means it is possible to use this to create a trustless wrapper primitive to a guardian multisig, much the same as the red.bridge, but it is widely accessible (virtually any Turing-complete chain can implement this, including Solana, that reminds me, @bentertainer) and instead of relying on a committee of validators, it validates incoming ZEC trustlessly. Further, for institutional users, who are scared of signing strange signatures such as adaptor signatures, the signature itself is a bog-standard, normal transaction send, so they do not have to migrate any systems and can continue to use their institutionally mandated 69 of 420 FROST+SSS signature scheme. # Wait… someone said this was… _checks notes_ programmable? LOL. It is. While not implemented yet (as we haven’t formally proven security), the compact digest we verify allows for a `encCiphertext[0...52]`, which, funnily, is not REQUIRED to be ciphertext. Since it is ChaCha-Poly1305 encrypted, it is not possible for validators or your wallet to discern if it is actually a ciphertext or not, and thus it can be used as a mechanism to transmit inter-chain messages from shielded Zcash to the EVM, for example. While 52 bytes clearly do not seem like much, we have devised a mechanism not much unlike Taproot, which allows for cross-chain secure script creation with commit anonymity, too! # So, we want community input! Is this something you want coming into Zcash? Should we apply for a community grant to productionise it? We’ll soon be making a post detailing how the programmability can work in the future. Feel free to ask _ **any questions you like** _! Crucially, it is on Sepolia and not Base (where it was originally intended) because to be fully honest, we run on basically no funding, so we have to make a request for donations: Please donate if you support our work! (let us know if you do, we’ll also give you early previews of things we build in the future _wink wink_). Even small amounts are highly appreciated! Donations go to: `u1dcq3dr3ydfnafssthhqvc6ls7gngs6n8pcgmt74jag552lrfr2rjxnky5wf7hj65cc5c4j9c0p5dalxuzqdr2gneepml94eygy2ff97m9d8tp8mdmhxlhpyhcuzy75exykt82fcwt7phacq45s2y3gqdpk5dpeve2krtfqdchguj4ewc`! --- _[View the full topic](https://forum.zcashcommunity.com/t/we-just-did-a-fully-trustless-shielded-zec-to-evm-atomic-swap-with-no-new-signing-primitives-and-yes-it-is-programmable/57827)._