Pinned Tweet
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.
thezecathon.com 👇
we're working on native end-to-end encrypted messaging in zigs, using zcash shielded memos as the transport layer.
zcash already encrypts memos, but we're adding application-level encryption so message confidentiality doesn't depend on the viewing key remaining secret.
the interesting constraint is the 512-byte memo limit. ml-kem-768 ciphertexts alone are 1,088 bytes, so the initial handshake needs multiple shielded outputs. subsequent messages can be considerably smaller.
early preview of the zigs web wallet is now open on devnet for early testers.
dealerless frost dkg, encrypted signer invitations, shielded balances, transaction proposals and threshold approvals. all directly in the browser. the cryptography stays local. the relay coordinates without holding spending authority.
sign up, give it a try.
we spent quite some time evaluating privacy protocols on solana before settling on zolana by @heliuslabs.
what we like is the architecture. programmable shielded balances, zk proofs and native solana settlement. no bridges, wrapped assets or separate execution environment.
more importantly, it composes with our frost-based custody model. threshold approvals remain separate from proof generation, with local proving as an option.
we're not looking for another mixer. we want programmable privacy that can become part of the wallet's underlying infrastructure.
zolana gives us a fairly interesting foundation to build on.
the new zigs website is live.
full end-to-end detailed technical explainers, architecture breakdowns, security considerations and references to the protocols we're building on.
if you're curious about what we're building, how it works and the engineering decisions behind it, it's all there.
have a look. link in bio.
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
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.
zigs.app
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
one of the things we want to get right before releasing zigs is native, end-to-end encrypted p2p messaging using zcash memos.
whislt zcash already encrypts shielded memos, we're exploring a second layer of application-level encryption using hybrid post-quantum key exchange (pqxdh) and key ratcheting.
the interesting problem is payload size.
zcash memos are limited to 512 bytes. an ml-kem-768 ciphertext alone is 1,088 bytes. the maths doesn't work.
the current approach is focsed around splitting the initial handshake across multiple shielded outputs, then use established session keys and a double ratchet for subsequent messages.
the result we're working towards: private messaging entirely over zcash, with message confidentiality that doesn't depend solely on the zcash viewing key remaining secret.
private speech is free speech. accelerate.