Docs
Product documentation and vision
PrivyPad
1. Introduction
PrivyPad is being built around a simple idea: privacy should be a core part of how tokens are launched, not something added later.
Most blockchain activity is publicly visible. Wallet addresses, transactions, and participation can often be tracked through block explorers and other analysis tools. This can expose information that users may prefer to keep private, especially during a token launch.
Our goal is to build a launchpad that gives privacy focused projects a place to launch while exploring ways to make participation more confidential.
The project takes inspiration from the cryptographic technology used by Zcash, particularly zero knowledge proofs and their ability to verify information without revealing everything behind it.
We want to bring these principles into the token launch process while keeping the experience simple enough for anyone to use.
Development is divided into two areas:
- Current features: The launchpad interface and any discovery or launch functionality that has already been implemented and tested.
- Planned features: Privacy preserving transactions, zk-SNARK integration, shielded launches, and a token buyback and burn mechanism funded by platform revenue.
This distinction matters because our long term vision goes beyond what is necessarily available in the initial release.
2. What We Are Building
PrivyPad is focused on three main ideas.
Privacy first
We want to reduce the amount of sensitive information exposed during token launches. This means exploring ways to protect transaction details and participation data while still allowing the protocol to verify that its rules are being followed.
Simple to use
Privacy technology can be complicated, but using the platform should not be. The goal is to make discovering projects and participating in launches straightforward, without requiring users to understand the cryptography working behind the scenes.
Built around the community
PrivyPad is intended to support projects and communities working toward a more privacy focused blockchain ecosystem. Over time, the platform aims to combine project discovery, confidential participation, and a native token connected to the ecosystem.
3. Current Features
This section covers the initial product and its intended scope. Features should only be described as live once they have been implemented and verified.
Launchpad interface
PrivyPad provides a dedicated interface for presenting privacy focused token projects and their launch information.
The goal is to make it easy to understand what a project does, explore its details, and find the relevant launch information without navigating a complicated dashboard.
Project discovery
The launchpad is designed to give users a straightforward way to explore projects.
Depending on the available implementation, project listings may include:
- Project name, logo, and token ticker.
- A short description of the project.
- Launch status and relevant dates.
- Official website and social links.
- Blockchain network and verified contract information, where available.
A project listing does not automatically mean that a token has been deployed or that its launch is active. These details should be clearly identified.
Project information
Each project can have its own page containing relevant information about the token, its purpose, and its launch.
As the platform develops, these pages may include launch conditions, participation requirements, contract details, and links to official resources.
Current privacy limitations
The initial interface should not be confused with a fully shielded launchpad.
Until the planned privacy infrastructure is implemented and tested, users should assume that ordinary public blockchain transactions may remain visible. A privacy focused design alone does not hide wallet addresses, transaction amounts, or participation activity.
The aim is to build toward stronger privacy protections through the underlying technology, rather than relying on branding alone.
4. Planned Privacy Technology
One of the main goals is to explore zero knowledge proofs, specifically zk-SNARKs, to support privacy preserving transactions and launch mechanisms.
This approach is inspired by Zcash, which uses zero knowledge cryptography to support shielded transactions under its own protocol.
PrivyPad intends to explore similar cryptographic principles for token launches, but its implementation will be designed around its own requirements.
What are zk-SNARKs?
zk-SNARK stands for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge.
In simple terms, this technology can allow a system to verify that something is true without revealing all the information used to prove it.
For example, a properly designed system could verify that a participant meets certain launch requirements without revealing all of their private information.
This creates opportunities to protect sensitive data while still allowing the protocol to enforce its rules.
However, zk-SNARKs do not automatically make every transaction anonymous. The protocol must be designed to specify which information is protected and which information remains public.
Inspiration from Zcash
Zcash is an important example of how zero knowledge cryptography can be used to protect transaction information while maintaining the validity of transactions.
We are taking inspiration from this approach and exploring how similar principles could be applied to token launches.
Potential applications include:
- Protecting sensitive participation information.
- Verifying that launch requirements have been met.
- Reducing unnecessary exposure of transaction details.
- Supporting confidential launch participation.
- Verifying certain launch conditions without revealing all the underlying data.
These are planned applications, not claims that PrivyPad already uses Zcash's technology or currently provides equivalent privacy protections.
The final design will depend on the selected blockchain, cryptographic system, and implementation.
5. Planned Shielded Transactions
Shielded transactions are an important part of the platform's long term direction.
On many public blockchains, transaction details can be inspected by anyone. Depending on the network and transaction type, this can reveal wallet addresses, amounts, timing, and other information.
We want to explore mechanisms that allow supported transactions to be verified without exposing all of their underlying details.
How it could work
A future implementation could use zero knowledge proofs to demonstrate that a transaction follows the protocol's rules without revealing specified private information.
The system would need to define what information can be hidden, how transactions are verified, and how the protocol prevents invalid activity.
The intended result is a more confidential transaction experience, with privacy provided by the actual protocol rather than simply by the interface.
What this means for users
If successfully implemented, these mechanisms could reduce the amount of sensitive information exposed during supported interactions with the launchpad.
The exact protections will depend on the final design. Public transaction metadata, network activity, wallet software, and external services may still reveal information, even when zero knowledge proofs are used.
The goal is to provide clearly defined privacy protections that can be tested and independently reviewed.
6. Planned Confidential Launches
Another major goal is to support launches that remain shielded until their predefined reveal conditions have been met.
Traditional token launches can expose participation and transaction activity while the launch is still underway. Depending on the design, this information can be analyzed by other participants or automated systems.
PrivyPad aims to explore ways to reduce this exposure.
Commit and reveal
One possible approach is a commitment based launch mechanism.
During the initial stage, participants or the protocol commit to certain information without immediately revealing the underlying values. Later, the system verifies those commitments and follows the rules established for the reveal stage.
Zero knowledge proofs may help verify certain conditions without requiring all committed information to be disclosed early.
The exact mechanism will depend on the type of launch and the privacy requirements involved.
Reveal conditions
A launch could be designed to reveal specific information only after a predetermined condition is satisfied.
For example, the condition might involve reaching a launch deadline, completing a participation phase, or satisfying a protocol defined threshold.
These are possible design options rather than confirmed features. Each launch mechanism will need clear rules explaining what triggers the reveal and what information becomes public.
Why this matters
The goal is to reduce premature information exposure and give participants a more confidential environment.
However, confidential launches do not automatically prevent market manipulation, front running, or every form of transaction analysis. These risks must be considered as part of the protocol design.
Making the process verifiable
Reveal conditions should ideally be enforced by the protocol rather than depending entirely on an operator's discretion.
The system will also need to account for situations where a launch does not complete, a participant fails to provide required information, or an external service becomes unavailable.
These details are important to making confidential launches reliable in practice.
7. Native Token Utility
The native token is intended to be connected to the broader PrivyPad ecosystem.
Its long term role should be based on real functionality within the platform, rather than simply existing as a tradable token.
Any token related benefits, such as access to platform features, launch participation privileges, or governance, will need to be defined and implemented before they are presented as available.
Holding the token should not automatically be described as providing transaction privacy unless the protocol explicitly supports that functionality.
Revenue funded buybacks and burns
The proposed token model includes using a portion of platform revenue to buy back the native token and burn the purchased tokens.
The intention is to connect platform activity with the token's supply over time.
When tokens are permanently burned, they are removed from the total supply. Depending on the source of the purchased tokens, this can also reduce the circulating supply.
The final mechanism needs to define:
- Which platform revenue qualifies for allocation.
- What percentage of that revenue is used for buybacks.
- How purchases are executed.
- How purchased tokens are burned.
- How completed transactions are verified.
- Whether the process is automated or managed by a treasury.
Until these rules are implemented, the buyback and burn mechanism should be described as planned.
Connecting platform growth to token economics
If platform activity generates more eligible revenue and the agreed allocation policy is followed, more funds could become available for token buybacks.
This creates a potential connection between the growth of the launchpad and demand generated by its buyback mechanism.
Burning tokens can reduce supply, but it does not guarantee an increase in token price or ensure that buying pressure will exceed selling pressure. Market conditions and investor behavior remain important factors.
The intention is to establish a clear and verifiable relationship between platform revenue and the token economy.
8. Security and Reliability
Privacy technology needs to be implemented carefully. A system can use advanced cryptography and still have weaknesses if the surrounding protocol is poorly designed.
Security will therefore be an important part of development.
Cryptographic security
The implementation should use established cryptographic libraries and a proof system appropriate for the selected blockchain.
The system must correctly verify proofs and reject invalid transactions. Its security assumptions, including any trusted setup requirements, should be understood and documented.
Program and contract security
Any on-chain programs or smart contracts will need to be tested for vulnerabilities involving authorization, transaction validation, state changes, and settlement.
If the protocol handles funds, it must also account for deposits, withdrawals, refunds, failed transactions, and other relevant scenarios.
Administrative permissions should be limited where possible, with any remaining privileges clearly documented.
Privacy beyond cryptography
Zero knowledge proofs do not automatically protect everything surrounding a transaction.
Wallet providers, browsers, network metadata, public transaction timing, and external services can still expose information.
The privacy model needs to account for these limitations and explain what users can reasonably expect the platform to protect.
Testing and audits
Before privacy features are described as production ready, the implementation should undergo appropriate testing and independent security review.
Testing should cover proof verification, transaction validity, launch conditions, reveal behavior, failure handling, and potential information leaks.
No audit can guarantee complete security, but careful implementation and independent review can help identify and reduce risks.
9. Development Roadmap
The following stages describe the intended development direction. They are not a claim that these milestones have already been completed.
Phase 1: Core launchpad
Build the initial user experience, including project discovery, project pages, and the supported launch interface.
The focus is on usability, reliable navigation, and clearly communicating which features are available.
Phase 2: Privacy research
Define the required privacy protections and evaluate suitable cryptographic systems.
This includes researching zk-SNARK implementations, identifying which transaction details can realistically be protected, and understanding the requirements of the target blockchain.
The result should be a technical specification that defines the intended privacy guarantees and their limitations.
Phase 3: Shielded transaction prototype
Develop an initial prototype of the selected privacy mechanism.
The prototype should demonstrate how proofs are generated and verified, what information remains public, and how the system rejects invalid activity.
Phase 4: Confidential launch mechanisms
Develop the planned commitment, participation, and reveal processes.
This stage should define how launches move between states, what triggers a reveal, and what happens if the process does not complete as expected.
Phase 5: Token economics
Finalize the revenue allocation policy and implement the proposed buyback and burn mechanism if it remains part of the approved token design.
The process should be documented clearly enough for users to understand how eligible revenue is allocated and how completed burns can be verified.
Phase 6: Security review
Test the complete system and conduct an independent security review before enabling production privacy features.
The launchpad should document its actual privacy guarantees, limitations, and relevant technical details before announcing the features as live.
10. Transparency and Accountability
The project aims to build trust by being clear about what the technology does and what remains under development.
Documentation should distinguish between live features, planned functionality, and potential future improvements.
The platform should not claim complete anonymity, fully shielded transactions, guaranteed resistance to front running, or operational buybacks unless the relevant mechanisms have been implemented and verified.
Where possible, public transactions and token burns should be independently verifiable. At the same time, the privacy architecture should minimize the exposure of sensitive information that does not need to be public.
The goal is to balance confidentiality with accountability, rather than treating them as competing priorities.
11. Our Long Term Vision
PrivyPad aims to make privacy a fundamental part of launching and participating in blockchain projects.
Inspired by the zero knowledge cryptography used by Zcash, the project intends to explore ways to protect sensitive transaction information, support confidential launch participation, and verify protocol rules without unnecessarily revealing private data.
Alongside this technical direction, the proposed native token model aims to connect platform revenue with token buybacks and burns.
Together, these ideas form the foundation of the project's long term vision: a launchpad focused on privacy, built around verifiable technology, and designed to grow with its community.
The priority is to turn these goals into secure, practical features that provide meaningful privacy protections and can be independently verified.
Privacy is the goal. Verifiable technology is how we get there.
