Do you have a link where I can play around w/ the product?
There is one thing I want to make very clear, because this discussion is starting to mix technical scrutiny with conclusions about a product that has not yet been released for inspection.
We are not asking anyone to trust ZECpad today.
And we are not asking anyone to treat the current private release candidate as already proven.
Before public access, every material factual claim we make about the production system will either have inspectable evidence behind it, or we will not present it as a production fact.
That includes things such as:
- fee and accounting rules;
- reserve and liability accounting;
- market-rule immutability;
- wallet custody boundaries;
- payout finality and replay protection;
- recovery behavior;
- Proof of Reserves / Proof of Backing;
- backing custody;
- reference-market execution;
- Shadow eligibility/finalization;
- privacy and authorization properties;
- and final on-chain/economic reconciliation.
The evidence will not just be screenshots or “trust us” statements.
Depending on the claim, it may include protocol specifications, relevant source code, deterministic verifier tooling, reproducible tests, release hashes, real mainnet transaction evidence and reconciliation artifacts.
If a claim cannot be demonstrated, it does not get promoted to a production claim.
That is the standard we are using internally as well.
There is also a correction worth making about older public material.
Earlier in development I used wording such as “everything is open-source”. That was too broad for what the project has since become.
The current ZECpad architecture is materially larger than the early prototype, and our release strategy is now more precise:
the code and artifacts required to independently verify public protocol claims will be published; security-sensitive operational infrastructure will not be dumped publicly simply for optics.
For example, users should be able to inspect how fees are calculated, how a proof is formed, how solvency is verified, what an anchor commits to, and what the trust boundaries are.
That does not mean publishing private keys, signer infrastructure, internal operational topology, abuse controls or other details whose publication would add attack surface without improving independent verification.
That is also broadly how serious systems tend to separate public verification surfaces from internal operations.
So yes: the old public documents are stale.
We have already said that.
They describe an earlier architecture and should not be used as if they were the final production specification.
That does not make them meaningless historical material, but it does mean that conclusions about the current system should be based on the current release candidate, current specification and current evidence — not on a months-old snapshot.
On your latest comments specifically:
If you believe creator-fee vesting would produce better incentives, that is a product-design argument.
If you believe paid placement should not exist, that is a product-design argument.
If you believe memecoin launchpads are inherently negative-sum and should not exist on Zcash, that is a philosophical/product-category position.
You are entitled to all three views.
We will evaluate useful ideas where they improve the product.
But those views are not the same thing as demonstrating that ZECpad’s current implementation is insecure, deceptive or technically unsound.
That requires evidence against the actual system.
If, once the current implementation is published, you can show that:
- liabilities can exceed real backing;
- market rules can be altered after users enter despite our stated guarantees;
- one economic claim can pay twice;
- recovery fails when normal ZECpad infrastructure is unavailable;
- reserve accounting includes virtual value as if it were real;
- a private user’s state can be extracted by another user;
- or our accounting does not reconcile;
then those are real findings, and we will treat them as such.
That is exactly the kind of scrutiny we want.
But declaring the project “rotten” before inspecting the current implementation is not the same thing as reviewing it.
It is a conclusion reached before the evidence is available.
So I think the fairest point to leave this at is simple:
Wait for the current code, current specification, verifier tooling and acceptance evidence.
Then attack the implementation as hard as you want.
If the evidence does not support our claims, the criticism will be justified.
If it does, that will be visible too.
Not publicly yet.
We’re still running the final private staging/mainnet acceptance work, and we don’t plan to open a separate public test environment.
Once the release candidate clears the remaining gates, we’ll open ZECpad directly on mainnet.
So there isn’t a public link to play with right now — the next public version is intended to be the actual mainnet release.
I agree implementation claims should be tested against the current implementation, not a stale prototype.
You seem like a reasonable guy who wants to make this work.
But two corrections.
First, “rotten” was about the pump.fun business model, not your code. We haven’t seen any of your code yet.
That does not change that the pump.fun model is rotten to the core. You say I’m entitled to that view. Good.
After criticising that business model, I followed up with some ways to make it less worse.
I would like to see you consider those properly. But in the fullness of time, I’m sure.
The negative-sum arithmetic does not come from, or depend on, the old specification, or the earlier implementation you described.
Instead the 1% fee, the 0.45% creator share and the roughly 2% round-trip figure I used are all in your current service overview on X (Twitter). The incentive criticism is about the economic rules you’ve published. It does not depend on seeing your code.
Second, on open source. It wasn’t only your wording that became too broad. In June, grant application #319 told ZCG the reference implementation and tests were already public, and you told this forum anyone could verify everything with npm test && npm run demo. They weren’t in the repo.
I note your new position: code needed to verify public claims will be published, operational infrastructure won’t be.
Those are fair corrections, and I think there are two separate issues here.
On the open-source point first: the June ZCG application reflected a much earlier and much narrower version of the project.
At that stage, ZECpad was closer to a reference implementation/prototype, and the public-code language was written around that architecture.
Since then the project has changed substantially.
It now includes wallet infrastructure, recovery logic, settlement and payout controls, reserve/reconciliation systems, custody design, proof systems, reference markets and significantly more operational security infrastructure than the version described in that application.
So I agree that the old wording no longer matches the project as it exists today.
The current position is more precise:
the specifications, verifier tooling, evidence and code required to independently verify our public protocol claims will be published.
What we do not intend to publish wholesale is security-sensitive production infrastructure where publication adds attack surface without materially improving independent verification — things like signer orchestration, internal operational topology, abuse controls and other sensitive production plumbing.
That is not a retreat from verifiability. It is simply a distinction between what needs to be public for independent verification and what belongs to production operations.
On the economics, I understand your argument.
Yes, fees are a cost to traders. I’m not disputing that arithmetic.
The 0.45% creator fee and 0.45% ZECpad fee have different purposes.
The creator fee is part of the market incentive structure.
The ZECpad fee funds the infrastructure itself: development, servers/RPC infrastructure, monitoring, security work, maintenance and continued engineering.
Protocol/platform fees separate from creator fees are normal in this type of infrastructure, and ZECpad currently has no other recurring revenue source that pays for those costs.
We have been working on the project for roughly four months, funding the infrastructure and development ourselves, without receiving external funding for that work.
At some point a production service needs a sustainable way to continue operating. We think 0.45% is a small and transparent way of funding that work rather than hiding monetisation elsewhere.
The more useful discussion, once the current release is public, will be whether ZECpad does what it says it does and whether those claims can actually be verified.
@mrnobody, noted. You’re not disputing the fee arithmetic, and ZECpad’s 0.45% funds the service. Fair enough.
But that explains ZECpad’s share, not the creator’s. Paying creators 0.45% of turnover still rewards churn and makes wash trading cheap. That’s the incentive I’d like you to think about.
One question that doesn’t need to wait for your code, because it’s a design fact you already know:
Can the protocol link a creator’s other claim keys to the creator, or not?
If it can, the privacy model is weaker than advertised. If it can’t, what stops the creator routing around the 5% cap through other claim keys?
Your answer doesn’t depend on the release candidate.
For the rest, you’ve now listed what will be independently verifiable before public access: fees, liabilities, reserve accounting, rule immutability, custody boundaries, privacy and authorisation properties, recovery, backing, finality, replay protection and reconciliation.
Good. Those are testable.
The key question for me will be where the verification boundary sits. Which facts can be derived independently from public or on-chain data, and which are produced by private infrastructure and then fed into the verifier? A verifier that checks data supplied by a closed system can prove consistency with those inputs. It does not, by itself, prove that the inputs are complete or independently true.
You also named recovery without normal ZECpad infrastructure as a valid test. OK. That should be part of the acceptance evidence.
So yes: publish the current specification, relevant source, verifier tooling, release hashes and mainnet evidence. Then there will be something concrete to review.
For others reading who might have come into the thread later: until then, there is nothing to try, nothing to inspect and nothing to verify.