The first private multisig for Zcash and Solana. π¦π‘οΈ
Distributed FROST keys. Client-side proofs. Encrypted chats.
Launching Nov 2026. No token yetπ
today we're announcing that @usezigs is joining the Zecathon. we believe the long-term cultural impact of @zksnarks_ on the zcash:native ecosystem will be undeniable. we here to accelerate that.
we're building the leading multisig solution for Zcash. because your zcash:native deserves better than @Ledger's next apology. institutional-grade security with a user-centric approach.
Accelerate Privacy.
Accelerate Ownership.
Accelerate Self-Custody.
zkSNARKS presents ZECATHON β a $ZEC privacy hackathon.
The goal is simple: put real resources behind people building useful technology on Zcash. Bring new builders in, support the ones already here, and help turn strong ideas into products people can actually use.
$100K prize pool. Submissions are open for the next 30 days.
https://t.co/qKPaKmHRxU π
@zakurazcash identified an interesting problem with @near_intents: publishing shielded refund addresses can expose a shared incoming viewing key to future quantum attacks.
we're exploring per-swap viewing-key isolation, private refund discovery via pir and deterministic recovery compatible with our frost architecture.
generating another diversified address isn't enough. the underlying viewing-key domain needs to be isolated.
we like working on hard problems.
shielded transactions protect what happens onchain. they don't necessarily hide who's connecting to the network.
zigs reduces ip-level metadata leakage across wallet sync, multisig coordination and transaction broadcasting.
there's not much point hiding transaction details with zero-knowledge proofs if the infrastructure can correlate your activity through network metadata.
privacy needs to be enforced across the entire stack, not just the consensus layer.
we've been experimenting with deterministic visual identities for wallets in zigs.
we hash the chain id and public address using sha-256, then derive a seed that controls the procedural generation of a unique 3d metallic orb.
geometry, surface distortion, material properties and accent colours are all derived from the same seed.
rendered locally. no external api, no stored images, no lookup tables. same address, same orb. across every device.
fairly simple cryptography. surprisingly interesting design space.
the frontend is intentionally simple. the architecture isn't. the user should see a balance, a recipient and an amount. not a crash course in cryptography.
under the hood we're combining dealerless frost dkg, redpallas threshold signatures, ironwood shielded transactions, encrypted signer coordination and multichain privacy primitives. we're also exploring post-quantum handshakes and intent-based crosschain execution.
complexity abstracted
@wavymaverick right now they just sit in a pending state until the signing threshold is met, similar to how multisig approvals work for smart accounts on evm. we're exploring configurable timeouts so stale proposals don't sit there indefinitely.
we're building the first multichain privacy wallet, starting with zcash, solana. privacy shouldn't be an advanced setting. it should be the default, even on chains that weren't designed for it.
ironwood handles the shielding on zcash, privacy rings by @helius for solana. all the complexity abstracted under the hood using relayers, a paymaster and the magic of @near_intents.
you tell the wallet what you want to do. the architecture executes witout a trace.
private by default.
before the key ceremony of a new wallet setup, participating devices establish end-to-end encrypted channels through a link or qr-based handshake.
each signer then contributes independent randomness through dealerless frost dkg, collectively deriving a single ironwood spending authority without ever reconstructing the private key.
no trusted dealer. no master key. the cryptography is fairly sophisticated. the user experience is not.
no seed phrases.
zigs uses dealerless frost dkg where each signer contributes independent randomness and receives a unique redpallas key share.
the full spending key never existed. there is no spoon.
instead, we're using passkeys to secure access to the native signer. the browser generates cryptographic key material for qr-based invitations, establishing encrypted channels between participants before the dkg ceremony begins.
the idea is fairly simple. passkeys handle authentication. frost for spending authority and qr handshakes to secure coordination.
working towards a UI where the user doesn't have to understand any of this.
exposing every security decision to the user isn't necessarily good security.
should advanced security be opt-in? should we abstract away the complexity and make certain assumptions on behalf of the user? how much control do we expose by default.
sometimes finding the right balance is proving more interesting than implementing the cryptography.
we're designing an air-gapped frost signer for zigs.
a signer that never touches the internet. ever. all communication happens through encrypted qr codes.
frost requires two signing rounds. the offline signer independently verifies the transaction, generates one-time nonce commitments, then validates the signing package before returning its redpallas signature share.
the other signers don't even know one seat is offline and the network just sees a normal tx. currently in final stages of testing qr payload limits, nonce safety and transaction verification before an independent review.
self-custody should not require trusting an internet-connected device. let alone a @Ledger with sim card and a north korean sim.
we succesfully completed end-to-end testing of private sol transfers using zolana on solana devnet. would not have been possible without the great docs by @Helius privacy.
2-of-3 threshold signing. distributed key generation, shielding and private transfers all worked as expected. we then wiped all 3 signers, restored them from encrypted backups and successfully executed another transaction.
the cryptography works. recovery works. we still have some issues around latency and stale tx we're working through but confident in delivering.
onwards.
we've redesigned the Zigs website and opened registrations for early access.
we're building for the privacy-curious, the cryptographers, the cypherpunks.
come break our beta. we want your feedback.
https://t.co/bnSaAm4ogK
THE MISSION IS UNCHANGED: PUSH PRIVATE, UNSTOPPABLE MONEY FORWARD_
For ten years, Zcash has been building the privacy technology money was missing.
The foundation is here.
Now build what comes next.
$ZEC // ZECATHON // $100K IN PRIZES_
if you've been building in crypto for the last few years and you're actually good at it, this is the time to focus on privacy.
some of the best engineers in the industry are converging on the same problems. there's a real community forming and plenty of external capital looking to back competent builders.
the tooling is still primitive. most of the obvious applications haven't been built. competition is almost nonexistent. the opportunity is fairly obvious.
see you on the @zypherpunks discord.
Announcing Zypherpunk!
We are calling up builders, researchers, and creators to come and shape the future of Zcash.
Our aim is to create an entry point for new talent in Zcash, where they can learn, contribute, meet like-minded people, and also get rewarded for their efforts.
Dozens of developers are already contributing via Zypherpunk with projects like thus-spoke-zakura, and more are being created as we speak.
We will be focused on the following:
- building more projects like thus-spoke-zakura collaboratively with developers
- creating content and media that accelerates developer-focused education for Zcash
- events and meetups that bring more high-quality technical talent to Zcash
- hackathons to identify the next big projects for Zcash and help them find the right partners for mentoring, funding, etc.
The encrypted money for humanity needs the brightest minds of our generation building for it.
If this sounds interesting to you, please fill out the form to join our Discord below π
theres two things we love here at zigs. the speed of solana and the privacy of zcash. there's no good reason a wallet shouldn't support both.
we're integrating @helius privacy rings (aka zolana) into zigs to bring confidential sol and spl balances alongside shielded zec.
the interesting problem we're trying to solve for is multisig. both protocols use two different curves, two signing schemes, separate viewing and nullifier keys. making all of this work under one threshold approval system without compromising self-custody is non-trivial.
same signers. same threshold.
two confidential chains. one zigs wallet