<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Voidify on Medium]]></title>
        <description><![CDATA[Stories by Voidify on Medium]]></description>
        <link>https://medium.com/@voidify?source=rss-d6f29591a5a0------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/1*JEVu0MnuXSkFBQnySoxQjg.jpeg</url>
            <title>Stories by Voidify on Medium</title>
            <link>https://medium.com/@voidify?source=rss-d6f29591a5a0------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Sat, 16 May 2026 03:44:28 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@voidify/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[Privacy Cash’s 4-Person Trusted Setup vs Voidify’s Open Ceremony]]></title>
            <link>https://voidify.medium.com/privacy-cashs-4-person-trusted-setup-vs-voidify-s-open-ceremony-7e7c94f88456?source=rss-d6f29591a5a0------2</link>
            <guid isPermaLink="false">https://medium.com/p/7e7c94f88456</guid>
            <category><![CDATA[solana-network]]></category>
            <category><![CDATA[zero-knowledge-proofs]]></category>
            <category><![CDATA[privacy]]></category>
            <category><![CDATA[cryptocurrency]]></category>
            <category><![CDATA[cybersecurity]]></category>
            <dc:creator><![CDATA[Voidify]]></dc:creator>
            <pubDate>Wed, 06 May 2026 14:28:23 GMT</pubDate>
            <atom:updated>2026-05-06T14:28:23.045Z</atom:updated>
            <content:encoded><![CDATA[<p><em>A side-by-side look at two Solana privacy mixers and why the number of people who held the cryptographic keys decides whether your funds are safe.</em></p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*fGGXmTo29EueqxiGJsMdNg.png" /></figure><h3>The one paragraph nobody reads, but everyone should</h3><p>Every zkSNARK-based mixer in production today — Tornado, Aztec, Zcash, Privacy Cash, Voidify — is built on top of a one-time event called a trusted setup ceremony. During that ceremony, a set of contributors collectively generate the public proving and verifying keys. As a byproduct, each contributor temporarily holds a piece of secret randomness called <em>toxic waste</em>. If, after the ceremony ends, all of that toxic waste is recoverable — because contributors saved it, leaked it, or colluded — an attacker can forge cryptographically valid withdraw proofs out of thin air. In a mixer, that means silently draining every user’s deposit, with the on-chain proofs looking mathematically identical to legitimate withdraws.</p><p>The security of the entire system therefore depends on a single property: at least one contributor honestly destroyed their toxic waste, and the others can’t get to it.</p><p>That’s the bar. Now let’s look at how two Solana mixers actually clear it.</p><h3>Privacy Cash: four people who all know each other</h3><p>Privacy Cash’s own <a href="https://github.com/Privacy-Cash/privacy-cash/blob/main/artifacts/circuits/TRUSTED_SETUP.MD">trusted setup document</a> lists exactly four contributors:</p><ol><li>Zhe — from Privacy Cash itself.</li><li>Stan — a frontend contractor working <em>for</em> Privacy Cash.</li><li>Ilja — from Tensor / Vector.</li><li>Richard — also from Tensor / Vector.</li></ol><p>Take a step back from the names and look at the trust domains:</p><ul><li>Contributor #1 is the project itself.</li><li>Contributor #2 is hired by the project. There is a paying employer-contractor relationship.</li><li>Contributors #3 and #4 are coworkers at the same external company. They almost certainly share an office, share a network, may share a laptop image, and certainly share a payroll.</li></ul><p>Nominally four contributors. Functionally two trust domains — and arguably one and a half, because employer/contractor relationships are not adversarial.</p><p>The document’s security claim is, verbatim:</p><blockquote>“As long as one of those 4 people deleted one of the intermediate zkey files used to generate the final zkey file, the ZK setup is safe.”</blockquote><p>That’s the standard 1-of-N honest-contributor assumption used everywhere in zkSNARK ceremonies. The math is fine. The problem is the N, and the independence of those N.</p><p>There is also no public evidence accompanying the document of:</p><ul><li>the entropy source each contributor used,</li><li>whether contributions ran on air-gapped machines,</li><li>any third-party witnessing of the toxic-waste destruction,</li><li>any video, attestation, or hardware-level proof,</li><li>any reason to believe the four parties cannot be reached, subpoenaed, or coerced together.</li></ul><p>The document is, in effect, a verbal promise from four people who all know each other.</p><h3>How small is “four”? An industry baseline</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*eRpu-RSFIPxBqpc8y-87TQ.png" /></figure><p>Privacy Cash sits below Zcash Sprout. And Sprout’s six contributors were, at minimum, geographically and organisationally separated. Privacy Cash’s four are not.</p><p>It’s worth pausing on Sprout for a moment, because it’s not just an academic punchline. In 2018, the cryptographer Ariel Gabizon — now Chief Scientist at Aztec — found a <a href="https://bitzec.github.io/blog/zcash-counterfeiting-vulnerability-successfully-remediated/index.html">devastating soundness bug</a> inherited from a foundational research paper that the Sprout ceremony was built on. The vulnerability would have allowed an attacker to counterfeit unlimited Zcash without any way for the network to detect it. Zcash patched it before any public exploitation, but the lesson stands: small, closed ceremonies are the layer of zkSNARK systems where catastrophic failures actually happen, not just where they’re theorised. Sprout had six independent contributors and a published, peer-reviewed protocol. Privacy Cash has four interconnected contributors and a one-page README.</p><p>snarkjs phase2contribute — the exact tool Privacy Cash used — explicitly supports public, asynchronous, browser-based contribution. The technical cost of opening up a ceremony to the public is approximately zero. Privacy Cash chose not to.</p><h3>Voidify: an open, public, reproducible ceremony</h3><p>Voidify is another Solana privacy mixer in the same product category. Every claim below can be independently verified — from the open-source ceremony frontend, from the live coordinator’s observable behavior, or from the cryptographic artifacts the coordinator serves.</p><h3>Anyone can contribute</h3><p>The Voidify Phase 2 ceremony runs at <a href="https://ceremony.voidifycto.eth.limo/">ceremony.voidifycto.eth.limo</a> — a single-page application served from IPFS. The frontend that every contributor&#39;s browser executes is fully open-source at <a href="https://github.com/VoidifyCommunity/voidify-ceremony-frontend">github.com/VoidifyCommunity/voidify-ceremony-frontend</a>. At the time of writing, more than 50 independent contributors have already taken part, and the queue is still open.</p><p>What contributors can verify before participating, just by reading the frontend repo and probing the live coordinator:</p><ul><li>The contribution flow accepts any human with a GitHub or Twitter account and a Solana wallet.</li><li>Each identity is single-use — duplicates are rejected by wallet address and by (social_type, social_handle). No Sybil padding.</li><li>A short contribution lock with a heartbeat keeps any one participant from squatting on the queue.</li></ul><p>The set of contributors is not the project team and their friends. It is whoever shows up.</p><h3>Every contribution is publicly verifiable</h3><p>The coordinator serves both genesis.zkey and the latest current.zkey. Every accepted contribution is appended to a public contribution log. The integrity of the ceremony does not depend on trusting the coordinator&#39;s internals — anyone can download the chain and re-run the verification locally against the canonical R1CS using a single snarkjs command. If it exits cleanly, the production zkey is provably a valid Phase 2 chain extension of the genesis zkey. The coordinator can lie about almost anything except this, because the math doesn&#39;t care who&#39;s hosting it.</p><h3>The genesis is reproducible from source</h3><p>The genesis zkey itself can be rebuilt by anyone, locally, from the withdraw.circom source and the public Hermez Phase 1 transcript. If your locally-built genesis byte-matches the one the coordinator serves, the ceremony was bootstrapped from a circuit that anyone can compile from source — not a sealed binary handed down from the team.</p><p>Privacy Cash provides no such reproduction path.</p><h3>Phase 1 capacity</h3><p>Voidify uses powersOfTau28_hez_final_20.ptau — the Hermez Phase 1 transcript with capacity for 2²⁰ = ~1.05 million constraints.</p><p>Privacy Cash uses powersOfTau28_hez_final_18.ptau — capacity for 2¹⁸ = ~262,000 constraints, a fourth of Voidify&#39;s headroom. That&#39;s a circuit-design choice, not a security claim, but it tells you something about the engineering posture: Privacy Cash optimised for a smaller, more fragile envelope.</p><h3>Beacon finalization</h3><p>When the ceremony closes, Voidify finalises the zkey with a public beacon — a publicly auditable, after-the-fact source of randomness, typically a hash committed in a public place like a Bitcoin block — that no contributor could have predicted in advance. This forecloses the possibility that the <em>last</em> contributor secretly biased the output.</p><p>Privacy Cash’s document does not mention any beacon.</p><h3>Side by side</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*oRrhXQoDU5Eax8qX96yhWQ.png" /></figure><h3>What attacks look like under each model</h3><p>Suppose a sophisticated attacker — a state actor, a coordinated insider group, or simply a sufficiently-resourced thief — wants to forge withdraws against the protocol.</p><p>Against Privacy Cash, they need to compromise the toxic waste of all four contributors. Two of them are coworkers in the same building. One is the project team. One is a contractor paid by the project team. A single compromised office network, a single coordinated lawful order, a single private agreement reached over a single lunch is all that stands between the attacker and the entire deposit pool. There is no on-chain signal an outside observer could use to detect the forgery either before or after it happens.</p><p>Against Voidify, they need to compromise <em>every one of the 50+ participants who have already contributed</em> — and every future participant who joins before the ceremony closes. Every additional honest participant — an anonymous browser session from someone in another country, a researcher in a university lab, a competitor who participated out of professional curiosity — adds another piece of toxic waste that must also be obtained. The attack surface grows, not shrinks, over time. And because the ceremony is public, an attacker who <em>did</em> somehow control all participants could not hide that they were the only contributors.</p><p>The first model relies on four people staying honest. The second relies on the entire population of contributors having no honest member at all. These are not the same threat surface.</p><h3>What users should be asking, of any mixer they trust with their money</h3><ol><li>How many people contributed to the trusted setup, and are they independent? “Independent” means no shared employer, no shared network, no shared physical space, no shared payroll. Four coworkers is one trust domain.</li><li>Can I rebuild the genesis zkey from source code on my own machine? If not, you are trusting a binary the team handed you.</li><li>Can I verify, locally, that the production zkey is a valid Phase 2 chain extension of that genesis? snarkjs zkey verify is one command. There is no excuse for a project not to publish the inputs.</li><li>Was the ceremony open? Could anyone have participated? Closed ceremonies put a hard ceiling on the trust domain count. Open ceremonies let it grow.</li><li>Was the final zkey finalised with a public beacon? Without one, the last contributor’s randomness has disproportionate influence.</li><li>Is there an append-only public log of contributions? “We had a ceremony” without a log is a press release, not a ceremony.</li><li>What evidence — <em>not promises</em> — exists that toxic waste was destroyed? Air-gapped hardware, witnessed destruction, recorded attestations. Verbal promises are worth what verbal promises are worth.</li></ol><p>If a project cannot answer those seven questions cleanly, the foundational layer of its privacy guarantees is being held together with social trust, not cryptography. In a mixer, where the toxic-waste compromise scenario is <em>silent fund extraction indistinguishable from legitimate use</em>, social trust is not enough.</p><h3>Closing</h3><p>Trusted setup ceremonies are the part of zkSNARK systems that almost no end user reads, but every end user is exposed to. They are the line where mathematics gives way to people — and where the integrity of the whole system depends on whether those people are independent, accountable, and observable.</p><p>Privacy Cash chose four friends and a verbal promise. Voidify chose an open ceremony — already 50+ contributors deep, with the frontend fully open-source on GitHub, a reproducible genesis, a public log, and a beacon-finalised zkey. Both projects ship the same kind of product. They do not ship the same kind of trust.</p><p>If you are a user of either: read the ceremony documents. Run the verification commands. Compare what you find. The whole point of zero-knowledge cryptography is that you should not have to take anyone’s word for it.</p><p><em>Voidify is a privacy infrastructure protocol on Solana. The Phase 2 trusted setup ceremony is live at </em><a href="https://ceremony.voidifycto.eth.limo/"><em>ceremony.voidifycto.eth.limo</em></a><em> and has accepted contributions from 50+ independent participants and counting. Ceremony frontend source: </em><a href="https://github.com/VoidifyCommunity/voidify-ceremony-frontend"><em>github.com/VoidifyCommunity/voidify-ceremony-frontend</em></a><em>.</em></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=7e7c94f88456" width="1" height="1" alt="">]]></content:encoded>
        </item>
    </channel>
</rss>