How HushCause works
What the protocol does, what it protects, and who you have to trust. Written to be checked against the contracts, not to sell them.
Describes the design as of October 2026. This site reads the deployed contracts, which have not been audited yet.
Overview
HushCause turns a token launch into a fundraiser. A creator describes a cause, a beneficiary is verified privately, and the token launches on Flap with a trading tax. The cause's share of that tax flows into a Cause Vault — a contract with fixed split rules — and the beneficiary claims from it with a zero-knowledge proof.
Flap is the launch and trading layer: bonding curve, DEX migration, the tax token and its tax processor. HushCause does not run a launchpad. It adds the fundraising, accountability, privacy and distribution layer on top.
The lifecycle
- The creator registers a draft in the CampaignRegistry: description link and hash, split rules, fallback recipient. These rules cannot change later.
- The creator sends the beneficiary a private invite. The beneficiary reviews the exact splits and consents.
- The beneficiary creates a claim key in their browser and sends encrypted evidence to the verifier.
- The verifier approves and signs the beneficiary's commitment (a hash of their key, bound to this campaign). It is registered on-chain. No personal data is.
- The creator launches the token through Flap's VaultPortal, which creates a Cause Vault for the campaign. Only verified campaigns can launch.
- Trades generate tax. Flap dispatches the vault's share. The beneficiary claims any time with a proof; other recipients are paid by anyone pushing their balance.
Where the money goes
Every trade pays the token's tax to Flap's tax processor. Flap takes its protocol fee and sends the configured market share to the Cause Vault when anyone calls dispatch. The vault never swaps and never calls out when it receives funds.
Inside the vault, each recipient's share is computed from total revenue: other recipients get floor(revenue × share), and the beneficiary gets the rest, so rounding dust always goes to the beneficiary. The invariant is simple: everything paid out never exceeds everything received, and the difference is exactly what the vault holds.
| Recipient | How they are paid | Can it change? |
|---|---|---|
| Verified beneficiary (≥ 50%) | Claims with a zero-knowledge proof, to an address chosen per claim | The share: never. The key: only through a 7-day public update the beneficiary can veto |
| Up to 3 other recipients | Anyone can push their balance to their fixed address | Never |
| Fallback recipient | Only after the campaign is closed, revoked or abandoned | Never |
Privacy model
| Data | Who can see it |
|---|---|
| Beneficiary's name, ID, documents | The verifier only. Encrypted in the browser, deleted within 30 days of the decision. Never on-chain. |
| Claim key | Nobody. Created and kept on the beneficiary's device. |
| Commitment, nullifiers | Public, but they reveal nothing about the person. |
| Payout address of each claim | Public. It is pseudonymous only as long as it is never linked to the person. |
| Wallet that submits a claim | Public. Use the relayer to avoid linking your own wallet. |
| Campaign story | Public. If it is specific, it can identify the beneficiary. |
| Amounts, splits, every transaction | Public. |
Why a zero-knowledge proof, if payouts are public? In this version it gives roughly the privacy of a fresh signing key that is never linked to anyone. Its practical value is that a relayer can submit claims without being able to change the recipient or fee, and that the same commitment can later be used with a shielded pool for private payouts.
The proof binds the chain, the registry, the campaign, a nonce, the action, the recipient, the relayer, the fee, the amount and a deadline. A proof cannot be replayed, reused on another campaign, or front-run to a different recipient.
Who can do what
| Role | Can | Cannot |
|---|---|---|
| Creator | Edit the description (its hash is recorded); cancel a draft before launch | Withdraw funds, change splits, change the beneficiary |
| Beneficiary | Claim, veto a key change, close the campaign — each with a proof | Change splits or the fallback |
| Verifier (attester) | Register the beneficiary's commitment; propose a new key after re-verification (7-day public delay) | Move funds; replace the key if the beneficiary vetoes |
| Risk operator (HushCause multisig and the Flap Guardian) | Freeze claims for up to 30 days; revoke after at least 3 days frozen | Send funds anywhere except the fallback recipient fixed at creation |
| Flap Guardian | Upgrade the vault implementation, which Flap requires for its verified-vault badge | — This is the largest trust assumption: an upgrade could redirect funds |
| HushCause backend | Store metadata and encrypted evidence; run the indexer and an optional relayer | Move funds or forge claims |
| Anyone | Push recipient balances, sync the vault, call Flap's dispatch; close a live campaign as abandoned once a year has passed since launch or the last claim, whichever is later. The unclaimed beneficiary balance and all later revenue then go only to the fallback recipient | — |
How we use Flap
- Launch: VaultPortal.newTokenV6WithVault with a Tax Token V3 and our CauseVaultFactory. The factory only accepts calls from the VaultPortal and only for verified campaigns.
- Tax: Flap's token takes the tax; its tax processor pays the market share to the vault on dispatch. Before DEX migration the tax is collected in BNB; after migration it accrues in the token and Flap sells it on the main pool.
- Checks: the dashboard reads the live tax rates, the market recipient and the commission receiver from Flap. A campaign is flagged if the vault is not the market recipient or a commission is set.
- Badge: our factory is unregistered with Flap until it passes Flap's partner audit, so Flap shows its vaults as unverified until then.
If Flap changes its contracts, fees or rules, those changes apply to HushCause campaigns too. We list Flap-controlled values with a “From Flap” label wherever they appear.
Main risks
- Compromised verifier: could propose a new beneficiary key. Mitigated by the public 7-day delay and the beneficiary's veto.
- Lost claim key and backup: recoverable only through re-verification and the same 7-day delay. If nobody claims for a year, funds go to the fallback.
- Dishonest creator: cannot take funds, but can write a misleading story. Read the verifier's summary, not just the story.
- Flap upgrade or failure: the Guardian can upgrade vault code; Flap's own contracts and fees are outside our control.
- Market risk: the token's price can fall to zero. The cause is funded by trading volume, not by price.
Audit status
- Contracts: unit, fuzz and invariant tests, and fork tests against Flap's live VaultPortal on BNB Chain.
- Planned: an independent audit of the registry, vault, factory and circuit before mainnet, and Flap's partner audit for the vault factory.
- The claim circuit uses PLONK with a public universal setup, so there is no circuit-specific trusted ceremony.
Labels used on this site
| Label | Meaning |
|---|---|
| On-chain | Read from HushCause contracts and enforced by them |
| From Flap | Read from Flap's contracts; Flap controls it |
| Off-chain | Provided by the HushCause backend; not enforced by contracts |
| Attester | Depends on the verifier's review |
| Private | Not published |
| Estimate | An illustration, not a guarantee |