1. Wallet and Session Data
The platform uses wallet signatures to verify control of a wallet. A login signature proves wallet control; it is not a payment, token approval, or transaction approval. We may store wallet addresses, verification times, roles, project access records, and team permissions so dashboards can work.
2. Project Data
- Project name, slug, token mint, creator wallet, treasury wallet, reward token, launch settings, and public links.
- Holder rules, payout splits, referral settings, skipped wallets, burn settings, donation settings, proof-page data, and safety-check results.
- Public-facing project information that creators intentionally publish through generated transparency pages.
- Operational logs, status reports, route-check results, payout round summaries, and error messages.
3. Sensitive Inputs
If a creator chooses to import an existing creator-fee private key, that feature must be treated as a custodial or semi-custodial vault flow. Such inputs should be encrypted at rest and protected by environment secrets. Users should not paste private keys into ordinary support chats, public forms, screenshots, or unsecured messages.
4. Alerts and Integrations
If Telegram or another alert channel is enabled, the platform may store chat identifiers, project alert preferences, selected notification categories, and delivery status. Alert channels may also process data according to their own policies.
5. Public Blockchain Data
Wallet balances, token mints, signatures, transactions, token-account data, and on-chain receipts are public blockchain data. The platform may read, index, display, summarize, or link to this data for holder rules, proof pages, payout calculations, and transparency.
6. Data Minimization
The product should avoid collecting unnecessary personal information. Most core workflows should operate from wallet addresses, project settings, public blockchain data, and operational status records rather than names, addresses, government IDs, or unrelated personal information.