Karma Duck: public-good commitments, private recipient details

1. A purpose for participation

A community can bring people, ideas and resources together. Karma Duck gives that shared energy a public-good purpose: a funding path for genuine needs, with commitments the community can follow.

Recurring support from community activity.Net trading tax is allocated 50% to platform KOL/project funding and 50% to the selected charity. The platform-managed half follows the published internal budget rule.

Respect for the people receiving support. Coded applications, encrypted contact records and a shielded-transfer design keep private details separate from the public grant ledger.

Flap supplies the launch layer, Railgun supplies the zero-knowledge shielded pool, and on-chain list commitments give the community a lasting record to verify.

2. Mechanism

Three components, each with a single job.

2.1 Launch layer

Tokens are issued on BNB Smart Chain through the Flap protocol using FlapTaxTokenV3 (TOKEN_TAXED_V3, enum value 6) via Portal.newTokenV6. The reserve asset is ZEC (0x1ba42e5193dfa8b03d15dd1b86a3113bbbef8eeb, 18 decimals).

Fixed settings use mktBps = 10000 and deflationBps = dividendBps = lpBps = 0. beneficiary is a fixed 50/50 tax-split contract, while commissionReceiver remains the published platform dev address. The token address ends in 7777, found through a client-side CREATE2 salt search.

You sign launch transactions with your own wallet. Your recovery phrase and private key are never submitted to the launch page.

2.2 Money layer

Curve-phase tax is collected in the quote asset ZEC and sent to the tax-split contract. After graduation, tax accrues in the token and is liquidated to the quote asset before reaching the same split contract. Half is credited to platform funding and half to the selected charity.

The real rate during the bonding curve is the 1% protocol fee plus the tax. A 3% tax means traders pay 4%. That visibly suppresses volume, so a higher tax does not necessarily produce more revenue.

The internal budget allocation of the platform half is 9:1. Direct aid uses the 90% grant budget; KOL outreach awards, protocol fees and gas use the 10% operations budget. KOLs submit the post URL and plan directly; the platform verifies the post during review and sets the final net award. Verified receipts feed integer budgets and the registry records batch commitments.

2.3 Commitment layer

Before each round moves any money, the platform writes the recipient list (code, amount, purpose) to a JSON file, hashes it, and publishes the hash into the CommitmentRegistry contract. The list file itself never goes on chain.

2.4 Public-good receiving options

Launch selects the charity for a fixed 50% share: Binance Charity by default, or Giggle Academy. The other 50% always funds platform KOL outreach and reviewed project applications through the published platform address.

• Platform share: 50% — uses the fixed developer address published by Karma Duck.
• Binance Charity (default): 0x8B99F3660622e21f2910ECCA7fBe51d654a1517D
• Giggle Academy: 0xC7f501D25Ea088aeFCa8B4b3ebD936aAe12bF4A4

Each charity has a separate fixed tax-split contract, set as beneficiary at launch. Both destinations, the quote asset and the 5000/5000 basis-point allocation are immutable. Revenue is recognised by balance delta and credited using integer base units; repeated empty wake calls do not double count. Permissionless dispatch or claim sends a share only to its fixed recipient. Protocol commission remains separate and goes to dev.

The launch confirmation shows both 50% destinations and the split contract. Before preparation and sending, the application checks deployed bytecode and on-chain destinations, quote asset and shares; backend receipt verification repeats these checks at the mined block. Changing the charity invalidates prepared transactions. The published dev address and split deployments must be configured before launch.

2.5 Applications and review

The application page opens on KOL outreach by default. Public-good projects and people seeking direct aid can switch to Grant application. Applicants provide a public code, contact information, an execution plan, a requested amount and a receiving method. The code should not contain a real name.

For KOL outreach, publish an X post containing Karma Duck and paste the specific post URL with your X username and outreach plan. Submit directly for review. During review, the platform checks the publishing account and post text through public post data; no X API key or applicant-side pre-verification step is required.

Post verification is one part of review. The platform then considers the plan, public-good purpose and available budget, and sets the approved net amount. One actual X account may receive one outreach award per campaign. Project and direct-aid applications do not require a promotional post.

The homepage shows real application summaries: code, category, review status and submission date, with pagination and refresh. Contact details, receiving addresses, requested amounts, X-account mappings and full application descriptions remain outside the public list.

Applications progress from awaiting review or verification to approved or not approved. Approved applications enter a funding plan and commitment workflow. Paid status is assigned after payment execution is verified; an approval or a list commitment alone does not mark an application paid.

3. Money flow

50% of net tax supports KOL outreach and platform project applications; 50% is allocated to the selected charity, defaulting to Binance Charity. The following list-commitment and Railgun workflow applies to platform-managed grants.

4. On-chain commitment

A fixed list, an on-chain timestamp and a hash anyone can compare form the foundation of batch accountability.

4.1 What it does

Every batch snapshot has both keccak256 and sha256 hashes. Both are recorded in the commitment transaction, so the exact file bytes can be checked with standard tools.

The contract records the batch id, commitment hash, total, headcount, submission time, the submitting address, and a memo that carries no identity information. The contract is append-only: a published record cannot be deleted or modified.

4.2 What it guarantees

• The commitment binds the original list bytes. Changing, adding or deleting an entry changes its hash and requires a new commitment.
• If a round ends up not being executed, the platform must cancel it publicly, and the cancellation is just as permanent.
• The ledger distinguishes a published commitment, verified payment execution and a public cancellation.

4.3 A verification role for every record

• List-file hashes check that a supplied snapshot matches the original commitment.
• Verified income receipts and integer budgets support the published allocation rules.
• Payment receipts and private allocation checks are verified separately from the list commitment.

A public commitment gives the community a durable reference for each approved batch, making changes and cancellations visible.

4.4 How the community can verify a batch

1. Open the published registry address and locate the batch. Compare its commitment hash, total amount, recipient count, publisher and timestamp with the ledger entry.
2. When authorised to access a batch snapshot, hash the original file bytes with keccak256 and SHA-256 and compare both digests with the registry. Preview, download and transaction preparation reuse one snapshot; changes require a new snapshot and commitment.
3. Follow payment progress separately. The application checks a successful receipt, target contract and matching events before publishing verified execution. Ordinary-wallet payouts also match the destination transfer; private payouts use the protected allocation verification process.

5. Zero-knowledge privacy

5.1 Who is protected

The recipient's identity. The reason is in section 1: a public receiving address puts the recipient under pressure from holders. Accepting help should not require giving up privacy.

5.2 Railgun zk-SNARK shielded transfers

Karma Duck uses Railgun’s zk-SNARK shielded pool. Zero-knowledge proofs validate the spending of shielded notes, while private transfers encrypt recipient and amount details. Contact and identity mappings are stored separately in encrypted records.

BSC mainnet transactions provide evidence of the tested shield deposit and origin recovery. Grant execution and independent recipient receipt verification have their own status in the public ledger.

5.3 Privacy and public accountability work together

• Private application records. Contact and identity mappings are encrypted. Optional 0zk receiving keeps allocation details within the shielded pool; ordinary receiving publishes the final address and amount on chain.
• Public batch evidence. Commitment hashes, amounts and verified execution records support community oversight.
• Clear transfer roles. Flap token trading remains public; Railgun supplies the shielded grant-transfer layer. Shield deposits and unshield destination addresses are visible on chain.

5.4 List integrity and payment execution

The list commitment binds exact file bytes. Railgun’s accepted zk-SNARK proof validates shielded-note spending. Ordinary payouts require matching chain events and actual recipient transfers; private transfers require separate decrypted allocation checks.

The operator binds each approved net amount and receiving method to the fixed payout plan. The ledger reports verified execution separately from commitment, and personal application records stay encrypted.

5.5 Two receiving methods

Ordinary BSC wallets are the default. Supply a compatible self-custody wallet address, such as one from OKX Wallet or MetaMask. The platform prepares a Railgun unshield payout to that address. Applicants do not need to create a privacy wallet or share a recovery phrase or private key.

Optional 0zk receiving uses a Railgun address for a private transfer within the shielded pool. The applicant chooses the receiving method before the payout plan is fixed. Contact and identity records remain encrypted in both workflows; ordinary unshield destinations and amounts are visible on chain.

The approved amount is the net amount the recipient is meant to receive. Protocol fees and gas are budgeted separately by the platform. ZEC is the launch pool’s quote asset; Railgun’s shielded pool and zk-SNARK verification provide the grant privacy layer.

6. Token parameters

7. Fees and revenue

The platform has two revenue lines. Both come from trading, neither from fundraising.

7.1 Commission

Flap supports a commissionReceiver parameter for V3 tax tokens. The protocol calculates commission internally from the applicable tax configuration. Karma Duck uses the published platform address for this receiver. Accounting uses verified on-chain receipts rather than a projected percentage of trading volume.

7.2 Tax share

The 50/50 rule applies to net trading tax reaching the split contract after protocol deductions. Only the platform half is entered into platform budgets. The existing 9:1 internal allocation divides eligible platform-managed income into direct aid and operations; KOL outreach, protocol fees and gas use operations. The external charity half is not counted again as platform income.

7.3 Budget example and amount precision

For an illustrative 1,000 units of verified eligible income, the 9:1 rule assigns 900 units to direct aid and 100 to operations. This is a budget example, not a revenue forecast. Amounts remain decimal strings and are converted to integer base units using each asset’s decimals; excess precision is rejected. Approved plans reserve their budget so the same funds are not allocated twice.

8. Appendix

8.1 Contract addresses

Current platform contract and treasury addresses are loaded from the public site configuration and shown below. Available charity tax-receiving options and their fund flows are listed in section 2.4.

8.2 Terms

• Commitment hash — the keccak256 of the list file, unchangeable once on chain.
• Shield pool — a zk-SNARK pool that supports public shield deposits, encrypted private transfers and unshield withdrawals.
• Code — the stand-in identifier a recipient is published under; the link to a real identity exists only off chain.
• Curve phase — the period when a token trades on the bonding curve and has not yet migrated to a DEX.

8.3 Disclaimer

Nothing in this document is investment advice, an offer, or a promise of any kind. The platform does not issue securities, does not promise returns, and does not provide asset management. Before trading any token, assess the risk yourself and confirm that you comply with local law.

8.4 Participate and explore the sources

Launch a community token, apply for KOL outreach support, or submit a public-good project. Follow coded applications on the homepage and commitment and execution records in the public ledger.

• Flap official V3 launch interface
• Railgun zero-knowledge cryptography
• Railgun unshield developer guide