How DollaPad works

The mechanics, the rules the program enforces, and the exact boundary of what is and is not private. Written for people about to put funds into a launch, and for people about to create one.

Overview

DollaPad is a Solana token launchpad. A creator mints a fixed supply, publishes funding rules, and collects SOL into an escrow that belongs to that one launch. If the campaign reaches its target, the escrow creates a Raydium liquidity pool and contributors claim their tokens. If it does not, contributors take their SOL back.

It is being built around Introducing Solana Privacy Rings (Helius, 2026-11-10): the goal is a shielded escrow per launch. That path is not available yet, for reasons set out below. Today every launch is a public launch, and the interface says so wherever a launch appears.

The casino is the artwork. There are no wagers, spins, prizes or random payouts anywhere in the product.

The launch model

One model: a funding campaign with a fixed token allocation. There is no bonding curve and no auction.

• Supply. A classic SPL token. The whole supply is minted into the launch’s vault and the mint authority is revoked in the same transaction. No freeze authority is ever set. The program refuses to register a launch unless it sees exactly that.
• Allocation. Four buckets that total 100%: contributors, liquidity pool, creator, treasury. Each of the first two must be at least 1%.
• Funding. SOL only. A target (at least 0.01 SOL), an optional hard cap, a deadline, a minimum contribution (at least 0.0001 SOL) and an optional per-wallet limit.
• Entitlement. Pro rata: contribution × contributor allocation ÷ total raised, rounded down. With a hard cap, the worst case for a contributor is known in advance; without one it is not, and the interface says that before you sign.
• Vesting. One schedule for the creator and treasury allocations: a cliff after graduation, then a linear unlock. Contributor tokens have no vesting.

State machine and who can do what

“Successful” is the outcome finalize records; the launch moves straight to graduation pending in the same instruction and waits there for the pool. Failed, Cancelled and Recovery are three ways of reaching the same contributor outcome: a full refund.

What freezes when funding opens

Everything: allocation, target, hard cap, limits, window, liquidity share, vesting, and the protocol values the launch copies at that moment (fee, fee treasury, graduation grace period, Raydium program, fee tier and fee receiver). The program has no instruction that edits an open launch, and a later change to the protocol configuration does not reach it.

What happens if graduation fails

graduate is atomic: if Raydium rejects the pool, or the pool does not take exactly the published amounts, or the sender’s cost limit is too low, the whole transaction reverts and the launch is unchanged. Anyone can try again. If the pool has not been created when the grace period ends, anyone can call abort_graduation; the launch enters Recovery, the recorded split is cleared, and every contributor can refund in full. Until the pool exists no SOL has left the escrow, which is what makes that refund whole.

Fees, rounding and conservation

• Protocol fee. Basis points of the raise (never more than 10%), copied into the launch when it opens and taken only after graduation. A failed, cancelled or recovered launch pays no fee.
• Split of a successful raise. fee = raised × fee bps (rounded down), pool = (raised − fee) × liquidity share (rounded down), creator proceeds take the remainder. The three always total the raise exactly.
• Supply split. Contributor, creator and treasury buckets round down; the liquidity bucket takes the remainder. The four always total the supply exactly.
• Entitlement dust. Rounding down each claim leaves fewer base units than there are positions. They stay in the vault permanently; nobody can take them.
• Solvency check. The launch tracks what its vault still owes. After every payout the program asserts the vault holds at least that plus its rent reserve, and reverts otherwise.
• Other costs. Solana network fees and account rent are paid by whoever signs. Raydium’s pool-creation fee and the pool’s account rent are paid by the sender of the graduation transaction.

All amounts are integers end to end, in the program and in the interface. No financial figure is computed in floating point.

Graduation

One venue: Raydium CPMM (the constant-product “standard AMM”), fee tier 0. The launch program makes a single call into Raydium’s initialize instruction with accounts it has already pinned or derived, and forwards nothing from the caller.

• Initial price. liquidity SOL ÷ liquidity tokens. Relative to the price contributors paid it equals (1 − fee) × liquidity share × contributor allocation ÷ liquidity allocation, which depends only on the published terms. Every launch page shows it.
• Deposit amounts. Exactly the liquidity allocation and exactly the liquidity share of the raise. The program verifies both balances after the call.
• Slippage. Not applicable: graduation creates a pool at a price the launch itself sets. It performs no swap. The pool address is the canonical one for the pair, so it cannot be pre-empted by someone holding none of the tokens (and before graduation, nobody holds any).
• LP tokens. Burned in the same transaction. Raydium permanently keeps 100 LP units in the pool on top of that. The liquidity cannot be withdrawn by the creator, by DollaPad or by anyone else. Trading fees accrue to the pool.
• What becomes public. Everything about the pool, from its first block.

Venue parameters, read from the chain on 2026-11-11 (UTC):

Program addresses come from Raydium’s source (raydium-cp-swap, declare_id! with and without the devnet feature: DRaycpLY18LhpbydsBWbVJtxpNv9oXPgjRSfpF2bWpYb and CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C). Raydium can change a fee tier’s parameters; the live values for the configured network are on the status page. DollaPad’s launch program is its own; neither Raydium nor Helius provides it.

Privacy boundary

Sources read on 2026-11-11 (UTC); the list is at the end of this section. Solana Privacy Rings are shielded pools with encrypted onchain balances. The permissionless default Ring is confidential, not anonymous:

Wallet addresses are always visible in that Ring. A deposit from a public balance and a withdrawal to one both reveal the asset and the amount. So even a finished shielded launch would hide contribution amounts while they sit in escrow, and nothing else. DollaPad does not offer, and will not claim, hidden participants or an untraceable history.

What a shielded launch would need, step by step

Why it is unavailable

1. A private escrow is a custom ZK program, and there is no production one. Rings do not provide a ready-made escrow. A private escrow is a "ZK Solana program" that verifies a zero-knowledge proof of its own rules and then calls the Solana Privacy Program. That needs purpose-built circuits, a trusted setup, verifying keys, a program ID and an audit. The official escrow and swap examples say so directly: "Not for production", proved "with insecure test keys generated from a fixed public seed, so anyone can forge their proofs". Sources: Privacy Rings: architecture; helius-labs/zolana-examples (README); zolana-examples: timelock escrow program.
2. No documented way to check a funding target over encrypted amounts. A campaign has to decide, onchain, whether the sum of contributions reached its target, and later split tokens pro rata. Contribution amounts inside a Ring are encrypted UTXOs. Evaluating a total, a refund entitlement or a pro-rata share without revealing the amounts requires a circuit designed for exactly that; none is documented or published. Sources: Privacy Rings: concepts overview; Privacy Rings: private state and UTXOs; zolana-examples: timelock escrow program.
3. Shielded keys belong to the wallet, not to a website. A private transaction is built with the user’s shielded keypair (signing, nullifier and viewing keys), derived from a signature over the fixed message "TSPP/derive/v1". The docs instruct wallets to "reject any sign request for the TSPP/derive/v1 message from a third party", because that signature can decrypt the user’s history. A launchpad therefore must not derive those keys itself; it needs wallets that expose private transfers, or the Embedded Private Wallet, which is described as not live yet. Sources: Privacy Rings: private wallet integration; Privacy Rings: embedded private wallet; Privacy Rings: encryption and privacy guarantees.
4. Graduation is public by construction. Liquidity goes into a public Raydium pool. Leaving a private balance is a withdrawal, and a withdrawal reveals the asset and the amount. So the total paired with the pool becomes public at graduation whatever happens before it. Sources: Privacy Rings: concepts overview; Privacy Rings: encryption and privacy guarantees.
5. The SDK is an alpha that trails the deployed programs. The TypeScript SDK is @heliuslabs/spr 0.9.0-alpha. The examples repository notes that it "predates the deployed 1.0 programs’ per-tree fee defaults" and that "no crates.io release matches the deployed 1.0 programs yet". The docs call the endpoints beta. Sources: Privacy Rings: SDK; helius-labs/zolana-examples (README); Privacy Rings: endpoints.
6. A dedicated Ring per launch is not available. Custom Rings, the mechanism for a ring with its own policy, are "currently being audited", with a mainnet target of Q4 2026 and access through Helius. A per-launch escrow would be a program-owned balance inside the shared Default Ring, not a ring of its own. Sources: Introducing Solana Privacy Rings (Helius, 2026-11-10); Privacy Rings: Custom Rings for enterprises.

A dedicated escrow for a launch is not a dedicated Ring. The design that the documentation makes possible is a program-owned balance, one per launch, inside the shared default Ring. A Custom Ring per launch is neither available nor the plan.

What the app does with Privacy Rings today

• Deployment probe. Reads the four documented Privacy Rings accounts on the configured cluster and reports whether they exist.
• Private wallet registry lookup. Reads the public registry record of a wallet to tell whether it has registered a Private Wallet. No keys, no balances, no Helius API key.
• Nothing else. The Privacy Rings SDK is not installed. No shielded transaction is built, proved or sent, and a public transfer is never presented as a shielded one.

The documented addresses (the same on devnet and mainnet) are ring1GaLCuJnkUMVkX2JeZLTTX17wKsV4fZmPVzXANW (Solana Privacy Program) and regy3WAeRXMYuMYxr5iK3Bf9Arr3PcxGxyzAddbiqDQ (user registry). Both were confirmed onchain on 2026-11-11.

Sources

• Introducing Solana Privacy Rings (Helius, 2026-11-10)
• Privacy Rings: concepts overview
• Privacy Rings: architecture
• Privacy Rings: encryption and privacy guarantees
• Privacy Rings: private state and UTXOs
• Privacy Rings: private wallet integration
• Privacy Rings: embedded private wallet
• Privacy Rings: Custom Rings for enterprises
• Privacy Rings: SDK
• Privacy Rings: endpoints
• Privacy Rings: addresses
• Privacy Rings API: getUserRecords
• helius-labs/zolana-examples (README)
• zolana-examples: timelock escrow program

Keys and signing

• Financial actions are signed in your wallet, one transaction at a time, after a simulation. DollaPad never holds a key that can move your funds.
• It never asks for a seed phrase or a private key, and it never asks your wallet to sign a message.
• In particular it never asks for a signature over the Privacy Rings key-derivation message (TSPP/derive/v1). That signature can decrypt a user’s private history, and the Privacy Rings documentation tells wallets to refuse such a request from any third party.
• The browser stores preferences, the launch draft’s form values and the signatures of transactions you sent. Nothing secret.
• The server sees what any web server sees (requests, and the wallet address you look up). It relays Solana RPC calls so that an RPC provider’s key never reaches the browser. It holds no user keys and takes no custody. It stores the token logo and description you upload.

Delivery modes

• Live. Mainnet, launch program deployed and configured, real services.
• Development. Works on the stated development network (devnet or a local validator), with test funds.
• Unavailable. Something required is missing: the RPC endpoint, the program or its configuration. Signing is switched off and the reason is shown. A deployment without metadata storage stays usable; only creating a token is switched off there.
• Fixtures. Sample launches for interface work. Only with an explicit development flag, never in a production build, labelled on every record, and impossible to sign against.

The header badge and the status page show the current mode, read live. A failed read is shown as a failed read: the interface does not fall back to invented numbers.

Scene guests and sources

The animals on the casino floor are original pixel characters drawn for DollaPad. Each one nods to a well-known Solana meme as an editorial choice. That is not an endorsement, a partnership or a listing, and no token artwork is used. The list below is a dated snapshot, not a live feed.

Method: market capitalisation and fully diluted valuation from the CoinGecko public API (they are different numbers; the $5.0M threshold applies to market cap); the mint address from the same record, then read from Solana mainnet to confirm it exists and is a token mint. Snapshot taken 2026-11-11 09:21 UTC.

Considered and left out:

• official-trump: Depicts a real person.
• melania-meme: Depicts a real person.
• gigachad-2: Built on a real person's likeness.
• pudgy-penguins: A company-owned character brand with its own licensing programme; no permission held.
• chill-guy: An individual artist's copyrighted character; no permission held.
• book-of-meme: Derived from a copyrighted cartoon character; no permission held.
• fartcoin: No character to draw.
• useless-3: No character to draw.

Known limitations

• The launch program has not been audited. Tests are not an audit, and nothing here should be read as a claim of safety.
• Shielded launches are unavailable, as described above.
• A mint can be launched once. A failed or cancelled launch returns the supply to its creator, who must create a new token to try again.
• Only SOL contributions, only classic SPL tokens, and only Raydium CPMM fee tier 0.
• Without a hard cap, a contributor’s share has no fixed lower bound.
• Token logos and descriptions are stored by the deployment that created the token, and whoever operates it controls that storage: a folder on disk in development, an object store on a hosted deployment. Records are written once and not overwritten, but this is not content-addressed permanent storage. The onchain name and symbol do not depend on it.
• Launch discovery reads the program’s accounts directly. A public RPC endpoint is rate limited; a provider endpoint is needed beyond light use.
• The protocol admin can change the fee, the treasury, the pause switch and the pool venue for launches that open later. It cannot touch a launch that is already open.