Privacy Policy

1The short version#

This summary is not a substitute for the rest of the policy, but it is accurate as far as it goes.

• We do not store your password, because there isn’t one. We do not store your email address in readable form — only an irreversible hash of it, used to recognise a returning account.
• We do not store your IP address in readable form. What we keep is a keyed hash, which can tell two visits apart without telling us where either came from.
• We run no advertising, no ad networks, no third-party trackers, and no cross-site tracking. We do not sell or share personal information for advertising.
• We publish computed performance about Solana wallet addresses, most of which belong to people who have never used Cooked. Section 5 explains what we publish, what we refuse to publish, and how to make it stop.
• We never publish dollar amounts for a wallet that is not the viewer’s own. Percentages and counts only.
• You can get a wallet removed from Cooked without an account, without a reason, and without a lawyer. See section 8.

2Who is responsible for your data#

[OPERATOR NAME], an individual trading as Cooked, at [BUSINESS ADDRESS], is the controller of the personal data described in this policy. Requests under section 9 reach the operator directly — there is no separate privacy department to route through.

For privacy questions, requests, or complaints, contact [PRIVACY CONTACT]. To have a wallet removed, use cooked.trade/legal/takedown — you do not need to contact us first.

3What we collect when you use Cooked#

You can browse Cooked and paper trade with no account at all. Everything below applies only once you create one, or only to the specific feature named.

Sign-in details, precisely. When you sign in with a wallet, we issue a single-use challenge, you sign it, and we verify the signature. When you sign in with Google, your browser or app completes the sign-in with Google and hands us the identity token that falls out of it. We verify Google’s signature on that token offline against Google’s published keys. We never hold a Google client secret, never exchange an authorisation code, and never call Google on your behalf.

Google sends more than we keep. The identity token carries your name, profile picture, given name, hosted-domain, and locale. None of it is stored. We take the subject id, hash the email, and discard the rest in the same function that read it.

4What we deliberately do not collect#

This section exists because a privacy policy that only lists what is collected leaves the reader to assume the worst about everything else.

• No password. There is no password field anywhere in the product and no password hash in the database.
• No plaintext email address, anywhere. Only an irreversible hash. A copy of our database is not a mailing list.
• No readable IP address. Where we need to tell two requests apart — session-reuse detection, and spotting a flood of takedown submissions — we store a keyed hash instead. The key makes it resistant to the enumeration that would defeat a plain hash of something as small as the IPv4 space.
• No phone number, no postal address, no date of birth, no government identifier.
• No advertising identifiers, no ad network integrations, no cross-site tracking pixels, no fingerprinting.
• No private keys, seed phrases, key shares, or recovery secrets — not for any user, under any feature, present or planned.
• No dollar amounts published for any wallet that is not the viewer’s own.

5Wallets we publish about that never signed up#

Cooked indexes Solana wallet addresses and publishes computed performance about them. The overwhelming majority of those addresses belong to people who have never used Cooked, never agreed to anything, and may have no idea the Service exists.

The underlying transactions are already public. The Solana blockchain is a public ledger and anyone can read it. But reading a ledger and publishing a ranked, searchable, shareable performance record about an identifiable address are different acts, and we do not treat the first as automatic permission for the second.

What we publish about an unclaimed wallet:

• The wallet address itself.
• Percentage return over each measurement window, with the number of trades and closed round trips it was computed over.
• Win rate, maximum drawdown, best and worst trade as percentages, average and median hold time, and the number of distinct tokens traded.
• Individual trades and closed round trips, as token amounts and percentages.
• Coverage dates — the point from which we can vouch for the data — and disclosure figures saying how much of it was unpriceable, undecoded, or otherwise suspect.
• A leaderboard position, if the wallet clears every eligibility gate.

What we refuse to publish, for any wallet that is not the viewer’s own:

• Dollar amounts of any kind. No portfolio value, no realised or unrealised profit in dollars, no position size, no capital deployed.
• Any attempt to identify the human behind an address. We do not link addresses to names, social accounts, IP addresses, or each other, and we do not buy or use any dataset that would let us.
• Any inference about a person — wealth, employment, location, or anything else — beyond the trading figures above.

The dollar-amount rule is enforced structurally rather than by policy. The share-card payload has no field a dollar figure could go into, free text passing through a card is scrubbed for currency figures, and the rendered output is scanned for one before it ships. Adding a dollar amount would take a schema change and a code review, which is where the rule gets caught.

We also exclude addresses that are not people. Liquidity pools, program-derived accounts, exchange hot wallets, and high-frequency arbitrage patterns are classified out of the rankings using the on-chain account owner as the dispositive signal, cross-checked against how often the address actually signs its own transactions.

Whether a Solana address is "personal data" is genuinely unsettled. It is a pseudonymous identifier that does not name anyone on its face, and it can in some circumstances be linked to a person by someone with other information. We have chosen to treat it as personal data wherever doing so gives the person more protection, and we have not resolved the legal question ourselves.

6Why we are allowed to process this (GDPR)#

This section applies if the GDPR or the UK GDPR applies to you. It is stated in draft form and is one of the things counsel is being asked to review.

7Who else touches this data#

We use the following third-party providers. Each is listed with what it does and what actually reaches it, because "we may share data with service providers" tells a reader nothing.

Configured but not currently in use: Privy, which would operate embedded wallets when live trading ships and would then hold your login with them and your wallet’s key shares — never Cooked. A product analytics provider is present in our configuration but is not wired into any application, so nothing is being sent to it. A payment processor will be added when billing is switched on, and this table will be updated before it is.

We also disclose data where we are legally required to — a valid subpoena, court order, or equivalent — and where necessary to investigate fraud or a security incident, or in connection with a merger or sale of assets. We will tell you about a legal demand where we are permitted to.

We do not sell personal information, and we do not share it for cross-context behavioural advertising, as those terms are defined by California law.

8Getting a wallet removed, and what removal does#

If a wallet published on Cooked is yours and you want it gone, you can make that happen. There is no account requirement, no fee, no form of words, and no obligation to say why.

Requiring you to create an account on the product you are objecting to, using the wallet you want disassociated from it, would be a remedy that only works for people who do not need it. So the intake requires no sign-in and stores no account link.

1. 01Signed route. We issue a one-time challenge; you sign it with the address. Because only the key holder can produce that signature, there is nothing for a reviewer to weigh — the removal is applied immediately and automatically, and the record notes that no human judged it.
2. 02Unsigned route. Submit the address and, if you want a reply, a way to reach you. It enters a review queue with a 72-hour target from the moment it arrives. The target is stamped on the request when it is received, so a later policy change cannot silently re-baseline a request that was already late.

What removal does:

• The address stops being a subject we publish about. No leaderboard row, no profile page, no history endpoint, no share card. Any card already rendered is invalidated.
• Removal survives recomputation. Our statistics jobs run constantly and would otherwise republish a removed wallet on their next pass; the check is re-read on every rebuild, so there is no stored verdict for a rebuild to overwrite.
• If we cannot verify whether anyone has been removed — for example, because the removal registry is unreachable — the leaderboard publishes nothing rather than publishing everyone. The system is built to fail towards silence.

What removal does not do, stated honestly:

• It does not delete the Solana blockchain. Those transactions are public, permanent, and not ours to erase.
• It does not delete the transaction records we derived from the chain. We suppress publication rather than deleting the underlying rows, because deleting them would destroy the evidence for figures we have already published and would make the removal itself unauditable. Suppression is reversible and accountable; deletion is neither.
• It cannot reach copies other people already made — a screenshot, a cached page, a repost. We can stop publishing; we cannot un-publish what left.
• A rendered share card may survive in a third-party or CDN cache for up to five minutes after removal. That window is the reason the cache lifetime is set where it is.

If you would rather we deleted the derived records outright than suppressed them, say so in your request. That is a decision we will make case by case, and the reason it is not the default is stated above rather than hidden.

If you hold an account and want to keep it but stop being ranked, you can opt out of the leaderboard from your settings without submitting a takedown at all.

9Your rights#

Depending on where you live, you may have some or all of the following rights. We apply them to everyone where we can, rather than checking your location first.

Access

Ask what we hold about you and get a copy of it.

Correction

Ask us to fix something inaccurate. For a computed figure, tell us what you think is wrong and we will re-examine the computation.

Deletion

Delete your account from your settings, or ask us to. See section 8 for what deletion can and cannot reach.

Objection

Object to processing based on legitimate interests — in particular, to us publishing about a wallet. The takedown route in section 8 is how to exercise this, and it does not require you to invoke a legal right by name.

Restriction

Ask us to stop processing while a dispute about accuracy or lawfulness is resolved.

Portability

Get the data you gave us in a machine-readable form.

Withdraw consent

Turn off push notifications at any time, in the app or in your device settings.

Non-discrimination

Exercising any of these rights will not get you a worse service. Nothing on Cooked is behind a paywall, so there is nothing to withhold.

To exercise any of these, contact [PRIVACY CONTACT]. We will respond within 30 days, or tell you why we need longer. You may also authorise someone to make a request for you.

A limitation worth stating: for an unclaimed wallet we hold no identity, so we cannot verify that you are the person a request concerns except by asking you to sign with the address. If you cannot sign, we can still act on a request — the unsigned route in section 8 exists for exactly that — but we cannot hand over data about an address to someone who has not shown they control it, because doing so would expose the address holder to anyone who asked.

If you are in the EEA or the UK, you can complain to your national data protection authority. If you are in California, you can also contact the California Privacy Protection Agency.

10Cookies and local storage#

We use two cookies. Both are strictly necessary for the Service to work, neither is used for analytics or advertising, and there are no third-party cookies.

In deployments where the web app and the API are on genuinely different sites, these cookies are set with SameSite=None and Secure, which is what browsers require in that configuration. Where the two share a domain, they are set with SameSite=Lax.

We also use your browser’s local storage for things that never leave your device: your guest paper-trading token, your recent searches, and a couple of interface preferences. Clearing your browser storage clears them. Clearing the guest paper token will orphan an unclaimed paper portfolio permanently, because that token is the only handle on it that exists.

The fonts used on this site are served from our own domain, not from a font provider, so loading a page does not disclose your visit to one.

11How long we keep things#

Account, profile, claimed wallets

Until you delete the account.

Sessions

Up to 30 days, or until you sign out. Signing out everywhere revokes them immediately.

Sign-in challenges (nonces)

Minutes. They are single-use and expire quickly by design.

Unclaimed guest paper portfolios

7 days, then deleted.

Rendered share cards

Cached briefly and regenerated on change. Invalidated immediately on a takedown.

Derived trade and performance records

Indefinitely, as the evidence behind published figures. Suppressed rather than deleted on a takedown — see section 8.

Takedown requests and their outcomes

Kept as the record that a request was made and how it was handled. [VERIFY: a retention period should be set here rather than left indefinite.]

Administrative audit log

Append-only and hash-chained, so that tampering is detectable. Retained indefinitely. [VERIFY: confirm this is the right answer for a log that names people who requested removal.]

12Security#

What we actually do, rather than a paragraph about taking security seriously:

• Session credentials are stored only as hashes. A dump of our session table is not a set of working credentials.
• The session cookie is HttpOnly and scoped to the sign-in routes; the short-lived access token is never written to storage a script can read, and dies with the tab.
• Signature algorithms are pinned everywhere a token is verified, so a token asserting no signature is not a token we accept.
• Administrator accounts are a separate table with a separate session space from user accounts, so no column anywhere in the user-facing schema can confer administrative access.
• Administrative actions are written to an append-only, hash-chained audit log. An administrator with database access could still destroy history — we say so rather than claiming otherwise — but not without leaving a detectable gap.
• Per-IP rate limits apply to sign-in, signature verification, and the takedown intake.
• Automated tests scan the API and worker source for key-material identifiers and fail the build on anything unacknowledged, so "we hold no keys" is enforced rather than remembered.

No system is perfectly secure, and we do not claim ours is. If you find a vulnerability, report it to [SECURITY EMAIL] and give us a chance to fix it before publishing. If a breach affects your personal data we will notify you and the relevant regulators as required by law.

13Children#

The Service is not for anyone under 18 and we do not knowingly collect personal information from anyone under 18. If you believe a child has given us personal information, contact [PRIVACY CONTACT] and we will delete it.

14Where your data goes#

We are based in the United States and our infrastructure is in the United States. If you use the Service from outside the United States, your data will be transferred there, where privacy laws may differ from those where you live.

Where a transfer of personal data out of the EEA or the UK is involved, we rely on the European Commission’s Standard Contractual Clauses, or the UK Addendum, with the providers concerned.

15Automated decisions#

Rankings, eligibility gates, and the classification that decides whether an address is a person or a program are all automated. They determine whether a wallet appears on a leaderboard and where.

None of them produces a legal effect or anything similarly significant for a person — nobody is refused credit, employment, or a service by them. They are, however, published, and being ranked publicly is not nothing. So: the method is documented in full and served publicly, every published figure names the version of the method that produced it, and section 8 gives you an unconditional way out.

16Changes to this policy#

We may update this policy. The current version and effective date are at the top of this page, and previous versions remain available.

For a material change we will give at least 30 days’ notice through the product before it takes effect. Because we hold no readable email address for most accounts, an in-product notice is usually the only channel we have — see section 4.

17Contact#

Privacy questions and rights requests

[PRIVACY CONTACT]

Takedown requests

cooked.trade/legal/takedown

Security reports

[SECURITY EMAIL]

Everything else

[SUPPORT EMAIL]

Postal

[BUSINESS ADDRESS]