ZecPad — a privacy-first bonding-curve launchpad for Zcash

[mrnobody]

What I’m building: ZecPad — a privacy-first bonding-curve launchpad for Zcash

Short version: pump.fun-style token launches (create → instant liquidity → trade), but built around Zcash’s privacy
ethos instead of against it.

The problem

Zcash already has solid inscription tooling — Zecscriptions, Zinc, Zerdinals — but those are marketplaces (the
Ordinals/OpenSea model: mint, list, trade). What’s missing is a launchpad primitive: a deterministic bonding curve
that gives a token instant liquidity the moment it’s created, with no order book and nobody seeding a pool.

The other half is cultural. The Solana launchpad world runs on surveillance — wallet tracking, whale-watching feeds,
founder-doxxing. That’s the opposite of what Zcash is for. We want the fair-launch / instant-liquidity UX without the
panopticon.

Why Zcash specifically

• Shielded ZEC for payments → participation is private by default.
• Encrypted memos to carry buy/sell intent privately — which is exactly why the ZAP1 and memo-coordination posts above
  caught my eye; structured memo conventions are what a trade-intent → settlement flow actually needs.
• The honest framing for today’s design: “private participation, transparent supply.” Who bought/sold is never exposed
  by us; the token ledger stays publicly verifiable. A fully-shielded ledger waits for ZSA.

The technical approach

Zcash has no VM, so a bonding curve can’t live “as code” on-chain. So:

• Meta-protocol (ZPAD-20): deploy / buy / sell / transfer ops written into transactions, with an indexer computing
  state — same idea as BRC-20/Ordinals, but shaped for a launchpad rather than a marketplace.
• Off-chain engine, on-chain settlement: price is computed by a deterministic engine; a curve-reserve holds ZEC in the
  MVP (semi-custodial, reserve transparent = proof-of-reserves), with PCZT atomic swaps as the trustless endgame.
• Wallets: Zcash has no MetaMask-style injected provider, so trades go to any wallet (Zashi, YWallet, Zingo,
  Zecwallet, Keystone) as ZIP-321 payment requests + QR, with the intent in a shielded memo. We also derive real BIP-39
  / unified viewing keys in-browser for an embedded wallet.
• Infra: zebrad reads the transparent ZPAD-20 ops (lightwalletd’s compact blocks strip transparent data, so the
  indexer needs full blocks) + lightwalletd for wallet sync / broadcast / shielded payment detection + indexer +
  Postgres.

Where it is now (honestly)

Working frontend + a real backend: the bonding-curve engine, a persistent trade log, real OHLC candles built from
actual trades, live updates over WebSocket. In-browser key derivation is real. On-chain settlement (indexer + node) is
the next milestone — the app is explicit about what’s live vs simulated. Testnet first, audit before any mainnet.

What I think is missing in the ecosystem

• No bonding-curve / instant-liquidity launch primitive on Zcash.
• No shared pattern for off-chain trading engines with verifiable on-chain settlement.
• PCZT tooling for one-sided / streaming settlement is still early.
• And the obvious one: ZSA for a fully-shielded fungible ledger can’t land soon enough.

What I’d want feedback on

• Is “transparent supply, shielded participation” the right MVP tradeoff, or worth waiting for ZSA before shipping a
  token ledger at all?
• Best path to trustless settlement for a one-sided curve trade — is PCZT the right tool, and are there working
  patterns?
• Indexer reliability: how are people handling reorgs / deterministic replay for meta-protocol state on Zcash?
• Standards: keep ZPAD-20 custom, or align the token layer with an existing standard (e.g. ZRC-20) for interop?

Happy to open-source the spec and compare notes — especially with anyone working on memo conventions (ZAP1) or memo-based coordination, since our settlement leans on exactly that.

[mrnobody]

Progress update on ZecPad

Heads-down building, and there’s a lot working now on testnet:

Privacy-first by design:

• Identity is a claim-key, not a wallet address. The system exposes only aggregate distribution (holder counts, concentration) — never per-wallet activity. No leaderboards, no whale-watching.
• Shielded settlement on testnet: payments settle against real on-chain value via the reserve’s viewing key — senders stay private, supply stays verifiable.
• Buy / sell / transfer working end-to-end, with signed, replay-protected operations.

Anti-rug by design — not a casino:

• Creator allocation hard-capped at 5%, enforced as a protocol rule.
• Fair-launch per-address caps enforced in the engine — no first-block sniping.
• Creator vesting so creators can’t instant-dump.

Built carefully: tiered confirmations, reorg-safe and restart-safe state, a fund-loss guard, and a hot/cold custody design.

Everything’s open-source (MIT). I’ll keep posting milestones here as the project moves toward mainnet. Feedback and hard questions welcome.

The mission: prove asset launches on Zcash can be surveillance-free and rug-resistant.

[mrnobody]

Important Update — ZecPad is evolving into the Private Market Layer for Zcash

What ZSA could unlock

ZecPad is being designed so that its core market infrastructure does not need to wait for ZSA.

The oracle layer, pricing engine, private claim system, settlement logic, collateral controls, hedge engine and proof systems can all be built today.

But ZSA could fundamentally improve how these markets are represented and used natively inside the Zcash ecosystem.

Today, ZecPad can create application-layer private markets where users enter and exit with shielded ZEC, while market pricing can be linked to external references such as equities, indexes, commodities or crypto assets.

That already creates an interesting model:

A user can gain exposure to a real-world market reference while keeping their financial activity inside the privacy model of Zcash.

That is very different from the normal public-chain model, where a wallet can often become a permanent financial profile:

• which assets it holds
• when it entered
• when it exited
• how large the position was
• how much profit or loss it made
• what other assets belong to the same wallet

For ZecPad, the long-term goal is to separate market transparency from participant transparency.

The market itself can remain observable and verifiable:

• reference price
• executable market price
• collateralization
• aggregate hedge coverage
• oracle status
• market solvency
• supply and market statistics

while the individual participant does not need to become public market data.

This is where Zcash is uniquely valuable.

A market can be transparent enough to verify that it works correctly without requiring every user’s financial history to be transparent as well.

Real-world indexed private markets

One of the most important directions for ZecPad is the ability to build markets whose value is linked to real-world references.

For example:

• NVDA-linked markets
• AAPL-linked markets
• broad equity index references
• gold and silver references
• crypto reference markets
• community-created markets whose pricing includes an external reference component

Users can enter these markets with ZEC and exit back into ZEC.

The external reference affects pricing and settlement, while the user remains inside the Zcash settlement environment.

This means ZecPad is not only a launchpad.

It can become infrastructure for a new class of private financial markets built around shielded participation.

Why ZSA matters

Today, these positions can exist as application-layer private claims.

ZSA could allow those same economic relationships to become native shielded assets.

That would be a major step forward.

Instead of a private position existing only as an application-level state, it could potentially become a native shielded asset that wallets and other Zcash applications understand directly.

This could enable:

• native shielded community assets
• native shielded indexed assets
• native shielded reference-linked markets
• private asset-to-asset trading
• stronger wallet interoperability
• private portfolio ownership without public token balances
• better composability between ZecPad and other Zcash applications
• native transferability of positions without exposing ownership history
• fully shielded market structures where ownership and transfers remain private by default

For example, a community market linked to NVDA could eventually exist as a native shielded asset rather than only as an application-layer claim.

Likewise, a direct reference market could potentially be represented as a native shielded asset whose economic value follows an external reference while settlement remains within the Zcash ecosystem.

More than a token standard

The important point is that ZSA would not replace the architecture ZecPad is building today.

It would make the asset layer native.

The difficult parts still remain:

• reliable oracle infrastructure
• deterministic pricing
• collateral and solvency controls
• external risk management
• aggregate hedging
• private ownership
• settlement
• proof systems
• market integrity
• recovery and reconciliation

These are not problems that disappear when native assets arrive.

ZSA would instead give those systems a much stronger native representation layer.

That is why we see ZecPad as more than a simple token launch application.

The broader opportunity is to combine:

Zcash privacy + verifiable markets + real-world reference exposure

in a way that public smart-contract chains do not naturally provide.

A user should be able to participate in a market without turning their wallet into a public financial identity.

That is the direction we think Zcash is particularly well suited for.

ZecPad is approaching launch, and we’ll be entering the market very soon with the first version of our private market infrastructure on Zcash.

[doberdanny]

Any chance you need any help with a launch? More than happy to contribute with dev resources and network. I truly believe it’s a great idea

[woodtallica]

Thanks for sharing your journey! I joined the forum specifically to follow ZSA developments and start building on it asap.

One question :what happen after the bonding curve?

[mrnobody]

Thanks! That’s actually one of the most important parts of what we’re building.

The bonding curve is only the launch phase. Once the curve completes, the asset “graduates” into the broader ZECpad market layer instead of simply ending there. Holders keep their exposure, price discovery becomes market-driven, and liquidity/trading continues beyond the initial curve.

With ZSA, the goal is for that lifecycle to remain Zcash-native and privacy-preserving — launch, trade, graduate, and continue as a real market rather than a one-off bonding curve token.

We’ll share the exact graduation/liquidity mechanics as we get closer to the ZSA implementation

The curve is where a market starts, not where it ends.

[mrnobody]

ZECpad Development Update — Shadow Genesis, pre-ZSA assets and trust minimization

A short update on where ZECpad is heading and how we are approaching some of the limitations that exist on Zcash today.

One of the topics discussed recently in the Zcash ecosystem is the absence of native ZSA support on mainnet and what that means for projects experimenting with tokens, collectibles and new market structures.

We agree with an important part of that criticism:

an application-layer asset should not be presented as if it were already a native Zcash asset.

That distinction is important to ZECpad.

Shadow Genesis

ZECpad will introduce Shadow Genesis, a limited collection of 512 Genesis collectibles distributed through participation rather than a traditional paid mint.

The first Genesis draw begins with mainnet participation.

Users who complete the pre-mainnet Genesis process and seal their Shadow Pass will be included in the first Genesis phase.

The idea remains simple:

512 Genesis Collectibles. Earned, not bought.

Before ZSA exists on mainnet, these collectibles should not be confused with native Zcash assets.

Instead, ZECpad uses a verifiable ownership layer designed specifically for the pre-ZSA period.

The important point for users is that ownership is not intended to depend on an administrator manually deciding who owns what.

The system is being designed around cryptographic ownership proofs, verifiable history and explicit trust boundaries.

When native ZSA support eventually becomes available, the Genesis system is designed to evolve toward native shielded assets rather than creating a completely separate ecosystem.

About backdoors and operator control

Another topic worth clarifying is administrative control.

ZECpad is deliberately being designed so that sensitive user ownership and market state cannot simply be changed through a hidden administrator switch.

That does not mean we are claiming zero trust or complete decentralization today.

There are still components that depend on ZECpad infrastructure, particularly before native ZSA support exists.

The difference is that we want those trust assumptions to be:

limited, visible and progressively removable.

Sensitive execution paths are being built to fail closed rather than becoming active because of a configuration mistake or a simple administrative toggle.

We also treat recovery as part of the architecture itself.

The long-term objective is that the failure of the ZECpad website should not automatically mean the failure of user ownership or access to assets.

Some of that work is still undergoing testing, and we will not label it production-ready before those tests are complete.

Why this matters beyond Genesis

Genesis is only one example of the wider architecture.

The same principle applies to ZECpad’s future market infrastructure.

ZECpad is not being designed around exposing individual user activity to external venues wherever that can be avoided.

For future reference markets, the goal is to preserve user privacy while still allowing the system to manage aggregate market risk.

The internal mechanisms behind this are intentionally not being published in full before release, but the design principle is simple:

external infrastructure should learn as little as possible about individual ZECpad users.

Likewise, ZECpad is not being built around a single asset provider, liquidity provider or marketplace.

We want those components to remain replaceable infrastructure rather than becoming the protocol itself.

ZSA

ZSA remains important to the long-term direction.

When native shielded assets become available on Zcash, they can remove some of the trust assumptions that necessarily exist in pre-ZSA application-layer systems.

But ZECpad is not waiting for ZSA by pretending that it already exists.

Instead, the goal is to build useful market infrastructure around what Zcash can securely support today, while keeping a clear migration path toward more native primitives as the protocol evolves.

That is also why we describe ZECpad as:

The Private Market Layer for Zcash.

Not simply an NFT platform.

Not simply a token launcher.

The larger goal is private market infrastructure built around Zcash, with explicit security boundaries and a path toward increasingly native ownership as Zcash itself evolves.

We will continue publishing the security properties and trust assumptions users need to evaluate ZECpad without publishing implementation details that would unnecessarily expose security-sensitive infrastructure.

Technical feedback is always welcome.

[mrnobody]

ZECpad Development Update — Final Validation Phase

Over the past development cycles, ZECpad has moved from core architecture and execution testing into its final validation phase.
At this stage, our focus is no longer on adding as many features as possible.
The focus is on making sure the system behaves correctly not only when everything works, but also when things go wrong.
Our latest release candidate has now completed the full functional regression with 2312/2312 tests passing, alongside clean type checks and runtime isolation tests.
During this phase we have been stress-testing the platform across several areas, including:

• execution safety
• stock backing
• privacy boundaries
• fee accounting
• recovery behavior
• market data integrity
• failure handling
• user-facing trading flows

We are also validating the StockFi layer under real market conditions.
The objective is to make stock on Zcash behave like a real market product rather than simply displaying a synthetic price.
This includes the relationship between execution, backing, historical market data, positions and settlement.

One principle remains especially important for us:
User liabilities should always remain covered by verifiable backing.
Another major area of development has been recovery.
For us, recovery does not simply mean restoring a wallet.
We have been designing and testing a recovery path intended to remain useful even when parts of the normal application infrastructure are unavailable.
This has been one of the more difficult parts of the project, but also one of the areas we believe is most important for a privacy-focused financial application.
We are currently continuing final validation across the complete system, including adversarial testing, staging behavior and small end-to-end real-value scenarios.
We have deliberately taken a slower approach here.
It would have been much easier to launch earlier and fix edge cases afterward.
We prefer the opposite approach:
find the failure modes before users do.
ZECpad is getting very close to the point where the product can speak for itself.
We will share more as validation continues.
If anyone in the community has technical questions about the architecture, recovery model, StockFi design, privacy model, backing structure or testing approach, feel free to ask.

We are happy to discuss the technical reasoning behind the system where it makes sense, without exposing security-sensitive implementation details.

[vaspholdings]

Hello @mrnobody, your latest update says ZECpad is now at release candidate status, with 2,312/2,312 tests passing, adversarial testing, runtime-isolation testing and real-value end-to-end scenarios.

Where can we inspect this code?

The only public repo I can find has no implementation and no test suite. It has not changed since 17 June.

That is particularly awkward because your ZCG application #319 said the reference implementation, deterministic ledger state machine, replay tooling, passing test suite, demo and ZSA compatibility document were already public.

In the ZPAD-20 grant thread you went further. You said anyone could “verify everything in five minutes” with npm test && npm run demo, and that “everything’s open-source (MIT).”

But none of that implementation is in the public repo.

The public spec is also plainly for a different product. It says a transparent token ledger, 85 ZEC raised for graduation, a 0.1 ZEC launch fee and no recipient consent. You now describe an encrypted/private feed, a 50 ZEC market cap, a 0.01 ZEC fee and consent-first transfers.

On Discord you confirmed that consent-first isn’t shipped. Today, if somebody already knows a user’s market-specific claim key, a direct transfer can create a valid position without the recipient signing first.

There is also the matter of the ZCG review.

ZCG already reviewed the foundation of this architecture and declined the grant. The first member’s recorded objection was that the assets were not enforced by Zcash consensus and depended on an external indexer interpreting memo data as token state. A second ZCG reviewer said the inscription approach did not work with shielded transactions and would not work with ZSA, and that he would not fund technology running against the principle of privacy.

You now describe a substantially different and much more private architecture.

What changed? Which of those ZCG objections have now been solved?

Because at the moment, nothing public shows that they have been.

You answered my questions yesterday on Discord about holder privacy and recipient consent. But every answer described work that either isn’t shipped or isn’t published, and you said repos and docs will come “before launch.”

Meanwhile, in Discord you are asking the community for visibility, ecosystem support, feedback and introductions, while here you have repeatedly asked for technical feedback and hard questions.

[vaspholdings]

So, questions… First, I see unanswered questions on custody and recovery.

Who controls the reserve keys? Who can move the ZEC?

You say users will be able to “prove what they’re owed and recover the ZEC value through an independent recovery path.”

What exactly is that independent recovery path?

Being able to cryptographically prove that ZECpad owes me ZEC is not the same thing as being able to recover the ZEC without ZECpad. Who holds the reserve keys, who authorises the recovery transaction, and can a user actually redeem their claim if ZECpad and its normal infrastructure disappear?

Your overview’s answer to “What if ZECpad disappears?” is that users can restore their 24-word phrase in any Zcash wallet. But that only covers ZEC still in the user’s own wallet.

ZEC paid into a bonding curve sits in the reserve, and after graduation in a “permanent pool”. For coin positions, the overview offers cryptographically provable claims and a recovery path, not ZEC sitting under the user’s own keys.

Your overview also says ZECpad will publish proof of reserves so anyone can check solvency. On Discord you said the accounting layer exists, but the independently verifiable solvency and proof-of-control side is still being finished.

How will that proof work, and will the scheme be available for review before launch?

And the anti-rug claims need more than marketing copy.

How does a 5% developer-buy cap work when the system is deliberately designed around unlinkable claim keys? What stops the same developer using five, ten or fifty identities?

Neither the cap nor the 30-day lock appears in any public spec.

The StockFi part raises even bigger questions. Who legally operates it? Your overview says backing assets are held in multisig “protocol custody.”

Who are the signers? Where are the assets held? What legal claim does a user have on those assets if ZECpad fails?

[vaspholdings]

And finally, who actually works on the ZECpad project?

Your ZCG applications #318 and #319 named you as project lead and sole developer/engineer, with no other team members. Your updates now say “we.”

Are @doberdanny or @woodtallica connected to ZECpad in any capacity: developer, adviser, investor, contractor, infrastructure provider or otherwise?

I am not saying they are. I am asking.

Both appeared supportively in this thread shortly after your September update. doberdanny offered “dev resources and network”. woodtallica said they joined the forum specifically to follow ZSA, then asked what happens after the bonding curve, giving you an opportunity to make a promotional reply.

If they are simply independent community members, fine. If either has a relationship with the project, that should be disclosed.

Well, here you have quite a lot of questions. If you have code to show, they should not be hard questions.

Please publish the current implementation, indexer, settlement and recovery code, test suite and current spec. If 2,312 tests are passing against a release candidate, there should be something other people can actually inspect and reproduce.

Publishing a test suite and spec does not require publishing production keys.

Until somebody outside ZECpad can inspect and reproduce them, “2,312/2,312 tests passed” is just another unverified claim.

[mrnobody]

Thanks for the questions. I think part of the confusion comes from looking at ZECpad through older public snapshots of the project.

When I submitted the original grant application, I was indeed working as a solo developer. That was accurate at the time. The developers who are now contributing to ZECpad were working on their own separate projects then. Those projects did not continue for different reasons, and they later decided to contribute to ZECpad instead.

So the team structure changed after the original application; there is no contradiction there.

The technical scope has also changed significantly since that first application.

ZECpad today is not simply the early bonding-curve prototype described months ago. The current architecture includes the launch lifecycle, protected trading, payout finality, permanent post-graduation markets, private claim-based ownership, deterministic asset identity, recovery architecture, data-availability work, backing and solvency controls, StockFi execution, treasury separation, and an integrated self-custody browser wallet.

We have spent the last development cycles going back through these systems again from a production-acceptance perspective rather than simply adding more features.

Our internal release process is deliberately stricter than “it works on my machine.”

The staging environment is designed to mirror the production architecture and uses real Zcash mainnet systems, real ZEC and controlled real-value execution where applicable. We are testing failure handling, replay safety, restart behavior, recovery, accounting, wallet behavior, backing and settlement before opening the product to public users.

That is also why some of what exists today has not yet been published in detail.

There is already active competition around this product category, and we did not think it was sensible to continuously publish partially finished implementation details while the architecture and security boundaries were still changing.

But this should not be interpreted as “the work does not exist.”

Before ZECpad is opened to public users, we intend to publish the relevant GitHub repositories, architecture documentation, protocol specifications, trust assumptions, release artifacts and validation evidence so that people can evaluate the system from code and reproducible results rather than from claims made in forum posts.

The distinction matters:

we are not asking the community to trust a private black box after launch.

We are choosing to complete the engineering and adversarial validation first, then expose the implementation in a state that can actually be reviewed meaningfully.

The embedded browser wallet is one example of that process.

Instead of relying on a generic external-wallet flow, ZECpad now has a self-custody browser wallet architecture being validated directly against current Zcash mainnet behavior. The keys remain on the user side, while the wallet handles synchronization and the transaction flows needed by the application.

The same philosophy applies to the market layer.

Graduation is not simply a terminal bonding-curve event; the market continues after graduation. Trading authorization is replay-protected, payout obligations have explicit finality states, asset identity is deterministic rather than being an arbitrary database identifier, and market/recovery state is being designed so that ownership is not simply whatever an operator-controlled SQL row says.

We have also been very deliberate about the pre-ZSA / post-ZSA boundary.

We are not claiming that the current application-layer assets are native ZSAs. ZECpad has its own verifiable pre-ZSA asset architecture, and ZSA is intended to become the native representation layer when that becomes available. The market infrastructure itself is not designed to depend on ZSA existing first.

On StockFi, the objective is also not simply to display an external equity price and call it a stock market.

The architecture is built around the relationship between user liabilities, verified backing, execution, settlement, market state and recovery.

In other words, if the system creates a user liability, the backing side has to be accounted for as part of the same product architecture.

Recovery and failure handling have received the same treatment.

We are not treating recovery as “restore the website and hope for the best.” It is part of the protocol design: what happens if normal infrastructure is unavailable, how claims are identified, how duplicate settlement is prevented, how state can be independently reconstructed, and how operator failure should affect user ownership.

So if you are comparing the project today with the first grant application or the earliest forum posts, you are looking at very different stages of the same project.

I actually welcome difficult technical questions.

If there is a specific invariant, trust assumption, privacy property or settlement mechanism you think does not hold, ask it directly. We can answer those questions much more usefully than arguing from older screenshots or descriptions.

And once the final pre-launch validation is complete, the code and supporting technical material will be available publicly before users are asked to rely on the system.

At that point, the project should be judged by what the implementation actually does — not by whether we managed to describe every internal development step on the forum while we were building it.

[woodtallica]

Hello,

I have no relations with ZECPad. I was just wondering how they are doing graduations since ZSA isn’t live.

I’m just following this project’s development.

[vaspholdings]

Thanks for taking the time, but most of the important questions remain unanswered.

In June you said the reference implementation, tests and demo were already public, and that anyone could verify everything with npm test && npm run demo.

They weren’t in the public repo.

What exactly were you referring to?

You still haven’t said who controls the reserve keys, who can move the ZEC, or how a user turns a cryptographic claim into actual ZEC if ZECpad disappears.

You still haven’t answered who holds the StockFi backing assets, or what legal claim users have on them.

You explained why the team changed, but still didn’t tell us who the team is. Pseudonymity is perfectly acceptable here. This is Zcash. But I think your users may care who is actually building and operating the system given how much custody you will have over their deposited assets.

As for the code: fine. Your answer is essentially “you’ll see it before launch.”

OK. Let’s not waste any more time on this until there is something to inspect.

[mrnobody]

Thanks for laying out the questions clearly. We’re still completing the testing and validation work, so we’re not opening ZECpad to users or asking anyone to rely on it yet.

Before users get access, we’ll publish the current specifications, relevant code and test evidence, and a clear explanation of the system’s trust boundaries. That will include who controls the reserve and backing assets, how funds can be moved, what happens if ZECpad or its infrastructure becomes unavailable, how recovery and redemption work, what rights users have, and who is building and operating the project.

At that point, we’ll answer these questions against the actual implementation and documented model, with full transparency about what is verified, what still depends on operators, and what remains a limitation. Until then, the system is still under validation; no one should have to take our word for it or treat it as ready for users.

[vaspholdings]

Fair enough on publishing before launch. But one thing won’t change when the code appears: the business model.

Even if every technical question eventually gets answered, ZECpad is a very bad idea. The problem isn’t the code. It’s what the code is for.

You told us that in your very first post here: “pump.fun-style token launches”. Not a privacy tool that happens to have tokens. A pump.fun clone with the lights turned off.

Let’s examine what this means.

Pump.fun is already awful. It industrialises the creation of disposable speculative tokens, rewards insiders and early buyers, and depends on later buyers becoming exit liquidity.

Solidus Labs analysed more than seven million Pump.fun tokens and found that 98.6% collapsed into effectively worthless pump-and-dump schemes.

Solana Rug Pulls & Pump-and-Dumps: What Crypto Institutions Must Know |...

98.6%.

That is the model you are importing.

But pump.fun gets one thing right, almost by accident: it runs on a transparent public chain.

When a market is this full of garbage, being able to see who created the token, who bought early, who accumulated, who dumped and where the money went is actually useful. It does not stop the scams. But it helps people see them.

And that is exactly what you set out to remove. Not as a side effect. As a core product feature.

In your opening post you said the Solana launchpad world runs on surveillance: “wallet tracking, whale-watching feeds, founder-doxxing”. You called that “the opposite of what Zcash is for”, and promised the same launchpad experience “without the panopticon”. In June you added: “No leaderboards, no whale-watching.”

Read that feature list again with 98.6% in mind.

Wallet tracking is how buyers see insiders accumulating. Whale-watching is how they see the dump coming. Tracing the founder is how rug victims find out who took their money.

In a pump-and-dump market, those aren’t surveillance problems. They are some of the few defences the victims have.

You are not selling privacy to ordinary users. You are selling the removal of their defences and calling it privacy.

You are not removing surveillance.

You are removing the smoke alarm.

The pump stays. The dump stays. The exit liquidity stays. But now the people doing the extracting get a much better way to cut and run with the proceeds.

That is why I say this is worse than pump.fun.

And making something worse than pump.fun takes some doing.

You headed your June update “Anti-rug by design - not a casino”, with a 5% creator cap “enforced as a protocol rule”.

If claim keys are deliberately unlinkable, how do you know the developer controls only the one labelled “developer”? If the same person controls ten identities, what exactly has the 5% cap protected anyone from?

A cap that cannot see who it is capping is decoration.

Maybe there is a clever answer to all of this. But you haven’t shown it.

I gave you a fair shake to show how ZECpad might solve a genuine problem, or produce something technically useful that improves the Zcash ecosystem.

ZCG gave the earlier version of the project the same chance. You failed to convince them, and they declined it.

You have failed to convince me with your pivot either.

The new version looks like the same bad idea with more machinery wrapped around it.

I still don’t see a useful problem ZECpad solves. What I do see is a machine for manufacturing speculative churn, taking a cut from every turn of the wheel - 1% of every trade, 0.45% of it to ZECpad - and giving the people extracting the money better cover when they cash out.

And don’t get me started on analysing StockFi.

Synthetic equity exposure, effectively securities-like claims without ownership of the underlying shares, off-chain hedging whose backing has not yet been demonstrated, and something hand-wavy called “protocol custody”.

Quite a lot going on there.

I would go on. But life is short. I think the reader gets the picture.

[vaspholdings]

A wider point, for the community and anyone else watching.

Privacy is normal. That is Zcash’s core strength: giving people control over who gets to see what they earn, own, spend, save and support.

But on a pump.fun-style launchpad built around extractive exit economics, transparency may actually protect users.

To be clear, this is not the argument some governments make against privacy coins. Their objection is that privacy can shield wrongdoers from the state, so everyone should surrender privacy in the name of enforcement.

My argument here is almost the reverse.

In an ordinary payment, privacy shields you from outsiders. In this kind of speculative market, the people you most need visibility into are the ones on the other side of your trade: the creator and early buyers selling into you.

ZECpad hides those people from exactly the counterparties they are profiting from.

In a market this rotten, that is not protecting users.

It is protecting insiders from the scrutiny of their own counterparties.

To be clear: I am pro-ZSAs. Native shielded assets will be good for Zcash, for native swaps and for things people actually need to hold and move privately.

My objection is not to asset issuance, or to launchpads generally. A launchpad can help a real project raise capital, distribute an asset and establish a market.

My objection is to pump.fun-style memecoin launchpads, where producing an endless stream of speculative tokens and generating trading churn is essentially the product.

I have yet to find a convincing example where that model creates more social value than it extracts.

At least when you walk into a casino, you know you are gambling, and the house edge on many standard table games is measured in low single-digit percentages.

A market where 98.6% of the tokens analysed end up effectively worthless makes the casino comparison almost unfair to casinos.

That is what these economics amount to: extracting as much crypto cash as possible from as many people as possible, wrapped in a thin veneer of decades-old market-making ideas and crypto-era bonding-curve maths.

ZSAs will make private assets possible. That does not make every business model built on them welcome.

To ZECpad, and to every other pump.fun-style launchpad or bonding-curve token factory eyeing Zcash:

Permissionless means anyone can build with ZEC.

It does not mean this community has to welcome, promote, legitimise or normalise every business model that decides to attach itself to Zcash.

Our credibility is not your marketing.

Our users are not your exit liquidity.

I don’t want these kinds of extractive token launchpads associated with or using Zcash.

Who am I? Just a concerned community member. I only speak for myself.

I imagine I’m not alone.

[vaspholdings]

I said earlier:

Maybe there is a clever answer to all of this. But you haven’t shown it.

Well, here’s one. Free of charge.

It’s an answer. Is it clever enough to solve the problems? Let’s see.

Your marketing promises privacy, fair launches, no sniping, no rugs, no instant dumps and no fake numbers.

Start with privacy, because at the moment it’s lopsided.

Your only published spec has a transparent token ledger, and the reserve’s viewing key reads the shielded memos needed to reconstruct market state. Users are private from the public, but not necessarily from the operator. Meanwhile, rug proceeds can leave as shielded ZEC.

ZSAs fix a large part of this properly. And this isn’t theoretical. There is already a public ZSA Feature Net where you can test issuing, holding, transferring and burning native shielded assets for yourself, though ZSAs aren’t on mainnet.

With ZSAs, the asset becomes native to Zcash. Ownership sits in shielded notes under the holder’s keys, while issuance, transfers, burns and supply validity are enforced by Zcash consensus. The service no longer needs to be the authority maintaining a private claim-key ledger.

That is the right end state.

ZSAs do not fix bonding curves, reserve custody, market manipulation or bad incentives. But they remove a large part of the need to trust the service as the asset-accounting authority.

Until then, somebody still has to run the off-chain market engine. Fine. Build the smallest temporary trust layer possible, collect the least information possible, make the trust assumptions explicit, and publish what the operator can see and the code that determines market state.

Then there is the anti-rug problem.

You advertise a 5% creator-buy cap, a creator lock and anti-sniping protections. But your privacy model is built around unlinkable claim keys.

If I am the creator and one key is capped at 5%, what stops me buying through five more? If the protocol can link those keys back to me, the privacy model is weaker than advertised. If it cannot, the cap is trivial to route around, and based on what you’ve published so far, that appears to be the case.

Either way, identity-based protections are the wrong fit for an unlinkable system.

[vaspholdings]

Don’t make the rules depend on who somebody is. Make them depend on the token, the position, the capital at risk and the state of the market.

For example:

1. Opening batch auction, then the curve.

Collect opening orders for a short period and clear them at the same price. Getting there three seconds earlier no longer gives somebody a better entry.

Nothing to snipe, and no identity required.

2. A real creator bond.

Require meaningful ZEC collateral at launch, proportional to the size of the market, and release it gradually under objective conditions published in advance.

If the launch fails early, some or all of the unreleased bond goes to the pool or holders.

The creator can generate another claim key. They cannot generate another pile of bonded ZEC for free.

3. Make early-exit costs follow the position, not the wallet.

If you want to discourage instant dumps, use a fee that decays with the age of the acquired position. Sell immediately, pay more. Hold longer, pay less. Send the penalty back to the pool, not to ZECpad.

Most importantly, the age must follow the position. Moving it to another claim key must not reset the clock.

4. Use market-level controls, not wallet-level controls.

If you want circuit breakers or limits on extreme sell pressure, apply them to the market as a whole. Ten wallets should not give somebody ten times the escape hatch.

There are trade-offs. Circuit breakers can also trap innocent sellers during a genuine crash, so they need careful design.

But at least the rule survives Sybil splitting.

The exact percentages and time periods are not the point. The principle is.

If anonymity breaks the protection, redesign the protection instead of weakening the anonymity.

Constrain tokens, positions, collateral, time and market state. Make abuse expensive whether somebody has one key or a thousand.

That idea matters beyond ZECpad or memecoins. Private assets and private markets will repeatedly run into the same problem:

We want users to be unlinkable, but our safety mechanism assumes we can recognise the same person twice.

That is a design smell.

The same principle could apply to private token sales, fundraising, vesting, DeFi positions, incentive schemes and eventually ZSAs generally.

Before ZSAs, there is another unavoidable problem: none of this is enforced by Zcash consensus. So the rules, state-transition logic and enforcement code need to be public. Otherwise they are promises made by whoever operates the system.

On this point, the ZCG reviewers identified the right problem. Their objection was that the asset state depended on an external indexer interpreting Zcash data rather than being enforced by Zcash consensus.

That concern still matters.

None of this changes my view of pump.fun-style memecoin launchpads.

What is interesting, and potentially useful beyond this mess, is the design principle underneath it:

Privacy does not mean abandoning market protections.

It means designing protections that do not depend on surveillance in the first place.

None of this stops coordinated pump groups, tells victims where shielded rug proceeds went, or turns a memecoin into something worth buying.

But if you’re going to claim “anti-rug by design”, then the protection should still work when nobody knows who the rugger is.

[vaspholdings]

There is another problem with “anti-rug by design”.

You can add locks, caps, circuit breakers and anti-sniping rules.

But if the creator and the platform still make money when users churn through garbage and lose, you haven’t fixed the underlying incentives.

At the moment ZECpad and the creator get paid when people trade. That means churn is profitable even if the token is garbage.

So start there.

1. Make creator and platform fees vest.

Don’t immediately pay most of the trading fees to the creator and ZECpad.

Escrow them and release them over 30, 90 or 180 days if the market survives under objective conditions published in advance.

If a token pumps, churns and dies in a weekend, the creator should not get rich from it.

Neither should ZECpad.

It also makes fake volume cheaper than it should be. A creator wash-trading their own coin pays the 1% trade fee, but gets 0.45% of it straight back through the creator share.

So the creator is partly subsidised for manufacturing activity in their own market.

An anti-rug system that still pays the creator and the platform while buyers get wrecked has not changed the underlying incentives.

2. Stop rewarding repeated buying.

Your Shadow Genesis model rewards buying activity.

That is exactly the behaviour a fee-generating launchpad already has an incentive to encourage.

Rewarding people for generating more trades is not protection from speculative churn. It is subsidising it.

If you want a reward system at all, weight it by capital genuinely committed over time.

Splitting one economic position across fifty keys should not manufacture fifty times the reward.

3. Stop selling visibility.

Your published spec includes paid “featured slot” homepage promotion at 1, 2.5 or 5 ZEC.

On a launchpad like this, paid visibility is an obvious pump tool.

Pay to be featured, attract buyers, sell into them.

Drop it, or label it unmistakably as advertising.

And even then, paid placement should not substitute for whatever standards you claim to apply to markets appearing on the platform.

4. Freeze the rules.

Fix each coin’s parameters at launch: supply, fees, limits and other market rules.

Nobody should be able to alter them after people have bought.

And publish any change to the engine’s global rules with a notice period before it takes effect, so users can get out first.

Before ZSAs, when users are already relying on an off-chain engine, that is the least you can do to limit what the operator can change on the fly.

Again, the exact percentages and time periods are not the point.

The principle is.

If your anti-rug protections do not materially reduce what the creator and the platform earn from a failed launch, then they have not fixed the economics that create the problem.

A safer design should be less profitable when users get burned.

That is a feature, not a bug.

And gets to the wider problem with the pump.fun model.

I don’t want pump.fun-style memecoin launchpads associated with or using Zcash. Improving the anti-rug mechanics does not make the underlying business model any less extractive.

I think the pump.fun model is inherently rotten.

The rest is a fig leaf over a machine designed to maximise negative-sum extraction from speculative churn.

Negative-sum, because every trade pays 1% to ZECpad, the creator and the Shadow Treasury, while the tokens themselves generate no cash flow or external productive return.

A buy followed by a same-value sell strips roughly 2% out in fees before you even consider price movement.

Turn the same money over five times and roughly 10% of that money has been extracted in fees.

Some traders win. Others lose. But across participants the fees are guaranteed leakage every time the money turns over.

Rotten.

That’s before anyone rugs.

And the more churn there is, the more users collectively pay and the more ZECpad earns.

That is why I keep coming back to incentives.

If the platform earns most when people trade more, the creator earns more when people trade more, the rewards encourage people to buy more, and paid placement lets creators buy more attention, then “anti-rug” mechanics are working against the business model itself.

You can improve the locks.

You can improve the caps.

You can improve the circuit breakers.

But unless you change who profits when things go badly, you haven’t fixed the rot underneath them.