Draft — pending legal review
This policy describes what the Bagged API and website actually do today, checked directly against the codebase rather than assumed. It has not been reviewed by a lawyer, and it does not implement formal GDPR/CCPA mechanisms — a self-serve data export, a verified deletion pipeline, a designated Data Protection Officer. Where we don’t have one of those, we say so plainly below instead of promising something that doesn’t exist yet. Bracketed items like [COMPANY LEGAL NAME] are deliberate placeholders pending real legal/business input.
1. Who this policy covers
[COMPANY LEGAL NAME] (“Bagged,” “we,” “us”) operates the bagged.life website and the Bagged API. This policy explains what information we collect through them, why, and who we share it with. It applies to visitors to bagged.life and to developers who sign up for or use the API.
2. What we collect
Waitlist and signup information
If you join the waitlist on bagged.life, we collect the email address and optional note you provide and store them in our database. API keys are issued by hand, not automatically at signup — if one is issued to you, we store only a one-way cryptographic hash of it, generated from a full-entropy random token, never the plaintext, so even we cannot see or recover the key once it’s given to you.
Wallet addresses you look up
When you or your integration queries a wallet’s PnL or positions, the wallet address you provide is a public on-chain address — not a name, email, or other traditionally personal identifier. Here is plainly what happens with it:
- It is sent to our on-chain data providers (Helius and Alchemy, see Subprocessors below) so we can fetch the transaction history needed to compute PnL.
- It appears in our API server’s request logs, because we haven’t configured any special handling to strip it out of the default per-request logging our web framework writes for every call — the address is simply part of the request URL, logged the same as any other route parameter. We do not maintain a separate, deliberate database of looked-up addresses tied back to who queried them.
- We don’t currently have a defined retention window for those request logs; they persist according to our hosting provider’s own log handling until we build a formal retention/rotation policy.
Per-key usage data
For each active API key, we record how many requests were made in a given time window — a count and a timestamp, not the contents of the requests — along with when the key was created, last used, and, if applicable, revoked. We use this to enforce per-tier rate limits and to spot abuse.
3. Subprocessors
We share data with a small, specific set of infrastructure providers the Service runs on — not a vague “we may share data with third parties.” We don’t use advertising trackers, and we don’t use a CRM beyond what’s listed here.
- Helius — on-chain data provider for Solana. Receives wallet addresses you look up so we can fetch and compute PnL against real Solana transaction history.
- Alchemy — on-chain data provider for our EVM chains (BNB Chain, Robinhood Chain, Ethereum) as their indexing lands. Receives wallet addresses for the same purpose.
- Railway — hosts the Bagged API and its Postgres database (waitlist entries, API key records and hashes, usage counters).
- Vercel — hosts the bagged.life marketing website.
We don’t sell your data, and we don’t share it beyond what’s needed to run the Service as described here.
4. No custody, no wallet-signing
Bagged only ever reads public, already-on-chain data. Nothing in the API or website asks you to connect a wallet, sign a message or transaction, or grant any spending or transfer permission — there is no code path capable of doing so anywhere in the product. We never have access to private keys, seed phrases, or the ability to move funds on anyone’s behalf, for any wallet, including ones you look up.
5. How we use data
- To operate the waitlist and issue and manage API keys.
- To compute and return PnL and analytics, via the subprocessors listed above.
- To enforce per-tier rate limits and usage caps.
- To investigate suspected abuse or security issues.
- To respond to support requests sent to business@bagged.life.
6. Data retention
We don’t yet have a formal, automated data retention or deletion policy. Stated honestly rather than glossed over, here is the practical reality today:
- Waitlist entries and API key records (the hash, never the plaintext) are retained in our database indefinitely until manually deleted.
- Usage counters are retained indefinitely alongside their associated key.
- Server request logs — which can include wallet addresses you looked up, per Section 2 — follow our hosting provider’s default log handling; we have not configured a specific retention or deletion schedule for them.
This is a known gap for a product this early, not a deliberate compliance posture — we are flagging it rather than pretending otherwise.
7. Your choices
We do not currently offer a self-serve way to export or delete your data, a formal data-subject-request workflow, or a designated Data Protection Officer. We would rather say that plainly than promise a mechanism that isn’t built yet.
If you want us to look up, correct, or delete the waitlist entry or API key data associated with your email, email business@bagged.life and we’ll handle it manually, on a best-effort basis. If you’re relying on a specific legal right (for example under GDPR or CCPA), tell us that in your email — we’ll do our best to honor it, but this is a manual process today, not an automated or SLA-backed compliance mechanism.
8. Security
We take reasonable measures to protect the data we hold. For example, API keys are stored only as a SHA-256 hash of a randomly generated, high-entropy token — never in plaintext — so a database compromise alone would not expose usable keys. That said, no method of transmission or storage is perfectly secure, and we do not currently hold a formal security certification (for example SOC 2 or ISO 27001).
9. Children’s privacy
The Service isn’t directed at children, and we don’t knowingly collect data from anyone under 13 (or the relevant minimum age in your jurisdiction). If you believe a child has provided us data, contact us and we’ll remove it.
10. International data transfers
Our subprocessors operate their own infrastructure, which may process or store data in regions other than your own. We haven’t audited or restricted exactly which regions each provider uses — if that matters for your use case, check the relevant provider’s own privacy policy or contact us.
11. Changes to this policy
We’ll update this policy as the product changes — including once any self-serve data-export or deletion tooling is actually built, not just planned. We’ll update the date below when we do. See also our Terms of Service.
12. Governing law
This policy is governed by the laws of [JURISDICTION], consistent with our Terms of Service.
13. Contact
Questions about this policy, or a request related to your data? Email business@bagged.life.
Last updated: September 2, 2026 — initial draft, pending legal review.
