Privacy

Who we are

Parabolic ("we") operates the interface at parabolic.family, its subdomains studio.parabolic.family, swap.parabolic.family and every <ticker>.parabolic.family coin website. Contact: contact@parabolic.family. Security reports: security@parabolic.family.

What Parabolic is

A non-custodial interface to public smart contracts on Arc and Robinhood Chain. We never hold your assets or your keys; a third party may hold part of a key you chose to create with it. Every launch, buy, sell, swap, claim and forum post is a transaction your own wallet signs. Everything those transactions do is public on the chain and outside our control.

No KYC

No KYC. We do not collect names, identity documents, dates of birth, addresses or payment cards, and we never ask for a seed phrase or a private key. We do not sell personal data.

What is public on the chain

Your wallet address, every transaction it sends, the coins it creates, the memos and forum posts it signs, and the name, ticker, description and image of every coin launched. We index this to display it. We did not create it and we cannot delete it from the chain.

Referral payouts

On a chain with a referral distributor, each week's record lists every paid referrer's wallet address with its lifetime referral figure in each asset and the proof its claim needs, every referral code that is owed but not yet tied to a wallet, and the codes left out by policy. It is built from public chain data, published beside the claim page at /referrals, public, and kept, because every claim is checked against it. A referrer who ties their code to a wallet signs once, and we keep the code, that wallet, the moment and the id of the signed request, public, so the next week's record pays the code to that wallet.

Holder rewards

On a coin whose creator gives its holders a share of the coin's fees, each epoch's record lists every holder's wallet address, the amount it can claim and the proof its claim needs, with the block its balances were read at. It is built from public chain data, served on the coin's rewards page, public, and kept, because every claim is checked against it.

Bounties

A promoter's submission stores their X account's numeric id and @handle, the wallet that receives the payment, the post's link and the result of the automatic check, kept with the bounty and public on it, because a bounty's claims are public on the chain too. One X account is tied to one payout wallet. Where a bounty asks for an account's age or followers, those two figures are read from X's API at the check and stored with it. A creator's reason for a rejection is stored as written and shown on the bounty.

Holder votes

Where a coin's creator has switched them on, a proposal keeps its title, paragraph, options and cost line, the wallet that made it and when, and a snapshot of every eligible holder's balance of that coin at the block our indexer had reached, with that block. A vote keeps the wallet, the option it chose and when; the creator's mark keeps honoured or not honoured, when, and a transaction hash if they gave one. All of it is public on the coin's page, and the marks on the creator's profile, because the balances and the wallets are public on the chain too. A proposal a moderator hides is kept with the reason. The signature is checked and not kept.

What we keep, and where

Records are JSON documents in a private Vercel Blob store. Nothing below is sold, shared for advertising, or combined into a profile.
Ticker reservations: the ticker, the coin name, your email address and, if you give one, your X handle. Ticker and name appear on the public board. The email is used once, to tell you when launches open, and is never shown or sold.
Comments and reactions: the text you post, your wallet address, the moment, and the image if you attach one. The record’s identifier is the digest of the text your wallet signed; the signature itself is not stored. Public, by coin. An upvote keeps the wallet that gave it and whether that wallet held the coin as it voted (a balance read on the coin’s chain, kept as a yes or a no and nothing more); the count is public, and which wallets upvoted is not shown.
Graduation calls: one standing yes or no per wallet per coin, signed. Kept per coin as vote/<coin>, as a count of the two sides in vote/<coin>/tally, and under the wallet as votes/<wallet>. Public.
Watchlists, follows and followers: which coins and which wallets an address has starred or followed. Readable by address, the way that address’s trades are.
Terms acceptances: the first time a wallet connects, it signs once to accept the terms and this policy. We keep that wallet, the version it accepted, the moment, the id of the signed text and the signature, as the record that it agreed; whether a wallet agreed is readable by address. This browser also remembers it, so you are not asked again here.
Wallet tracker groups and names: the wallets an address put in its Friends group on the wallet tracker, and the names it gave wallets it tracks, signed by that wallet. Private to that wallet: shown only to its own Studio session, or to a device it signed on, and never readable by address the way its follows are. The Smart and KOL groups are not stored: they are read from public fills and the KOL list.
Wallet groups: the named lists of wallets an address keeps on /wallet-groups (each list’s name and the wallets in it), signed by that wallet. Private to that wallet in the same way: shown only to its own Studio session, or to a device it signed on.
Hypermode watchers and alerts: the rules a wallet saved (what to watch, the conditions, the buy it would prompt, and whether to tell it by push or Telegram) and its quiet hours (two times and the time zone they are in), signed by that wallet. Private to it: the bot that delivers them reads the armed ones behind a key, with the wallet’s plan so a higher plan is told first, and nothing else does. For a wallet with watchers or alerts the bot also reports whether a Telegram chat has linked it with /wallet, as a yes or no and never the chat itself, so the Alerts page can say Linked. Automated orders, when a chain has them switched on, are stored the same way and are private to their wallet; before each fill the order executor reads the wallet’s plan from our own public plan read, and for a copy order it reads the copied wallet’s public trades and the coin creator’s public balance. The one exception is a count: the Copyable board shows how many wallets copy a wallet, never which. A Solana wallet's watchers and alerts are kept the same way, under its address exactly as it is written and signed by that wallet; a profile link does not share them with the wallet it is linked to.
Killermode, where it is switched on: the room reads its feeds over one socket to our realtime service. The site checks your plan, then hands the page a pass for each feed; a pass names your wallet and that one feed and lapses after two minutes. The site keeps no record of a pass, and the realtime service holds it in memory only while your socket is open. For a wallet on Ultra that service also holds the last 20 alerts that fired for it (the title, the text, the coin and the moment), in memory and never on its disk, so a page you open shows them at once; they are gone when the service restarts, and the wallets held longest are dropped first once more than 5,000 have some. The insider view keeps a list of the coins that some open room has in focus, so our watcher knows which coins to read: the coin and the moment it was last asked about, never who asked, and a coin leaves the list five minutes after the last look. The live block feed is public chain data, and which of its rows are yours is decided in your browser, from the wallets connected to the page. Your paper bots’ book (their rules, their simulated fills and their history, never a key or a signature) is kept on our side under your wallet, so your phone and your desktop see one fleet, until you delete it; nothing in it is signed or sent. For a paper bot you set to tell you on Telegram, each of its paper fills (the bot’s name, the coin, buy or sell and the size) is kept on our side under your wallet, the newest 50 for a day, so our Telegram bot can message it to the Telegram account that proved that wallet in our mini app (Telegram’s signature and the wallet’s own, both checked); a chat that only named the wallet with /wallet is never sent them. The order executor reports in every 20 seconds with its own address, the module it serves and how many orders it has open: a count, never whose. It keeps its own copy of the open orders it watches, with their signatures, on its own disk at Fly.io, so a restart does not lose a stop.
Creator X records: the X handle a wallet confirmed for its profile, and the post that proved it.
KOL list: the wallets we mark as KOLs. Some are added by hand by Parabolic, with a name and an optional X handle. The rest are wallets that confirmed an X handle, where that X account passes our checks; for those we keep the account’s public follower, following and post counts, its creation date, how many of the last 60 days it posted on, and one follower count a day for up to 60 days, refreshed at most every six hours. The list is public at /api/v1/kol.
Coin confirmations: the X handle that confirmed a coin, the post link and the moment. Public, and shown on the coin.
Promotion bookings: the coin, the spot, the length, the paying wallet, the transaction hash and, when the wallet that paid is the coin’s creator, the line of copy they wrote. Public, and labelled as promoted wherever it renders.
Plan subscriptions: the paying wallet, the plan, the chain, the transaction hash, the amount paid and when each paid period starts and ends, read off the payment on chain; nothing renews and no card is stored. A wallet’s plan is public the way its payment is. The three-days-before reminder goes to the browser push subscriptions registered under that wallet. The fee voucher the aggregator router accepts (the wallet, its fee, the chain and an expiry) is signed on request and never stored. A Data API plan is recorded the same way, under the wallet that paid for it.
API keys and webhooks: for an API key, a SHA-256 hash of the key (never the key itself, which is shown to you once), the label you gave it, the wallet that made it and when; its short id and label are readable by that wallet’s address. For an Ultra webhook, the URL you set, its signing secret and when you set it; the bot sends your alerts to that URL, which is a third party of your choosing, and the host is readable by your wallet’s address. A plan given as a prize or by hand is recorded on the plan like a payment, with the reason and nothing paid. Where the Data API is open, each key’s requests are counted per UTC day under its short id (how many, how many streams and streamed events, and which endpoints with every address and number replaced by a placeholder), readable only with the key itself. For a public webhook, any wallet’s, the URL you set, its label, its signing secret, the coins and events you chose and how its deliveries went (counts, the last error and whether it was switched off); the bot sends those events to that URL, its host is readable by your wallet’s address, and its path only by your own wallet.
Points boards: a shared fold over indexed fills, keyed by wallet address. Nothing is stored that is not already on the chain.
Profiles: the name you choose, a picture you upload, the banner ground, the accent and avatar frame, a one-line bio, your X, Telegram and site links, up to three pinned coins and which figures your page shows. Public, by wallet; a name is unique across the site. The plan a wallet holds is read from its Pro record and shown beside the name, not stored here. A profile kept with an X or Google sign-in and no wallet holds the same parts except the pinned coins and the figures, shown under a keyed hash of that sign-in’s identifier rather than the identifier itself, and whether its X link is the X account that signed in.
Profile links: linking an EVM wallet and a Solana wallet into one profile keeps, under each of the two addresses, both addresses, how the link was proved (a signature from each wallet, or the sign-in that made both wallets for you), an identifier of that proof and the moment. It is public: anyone can read which wallet is linked to which, by either address, and the two are shown with one profile, one set of follows and one watchlist. Signing in with X to wallets made for you links those two by itself. A link lasts until one of its two wallets removes it, which either can do alone, with one signature, under Wallets in your settings. What stays under each address then is that a link was removed and when, with no other wallet named, and signing in does not put the link back.
Weekly leagues: when a week closes, each wallet with points that week, the league its points put it in and its place there, and the Pro months given to each league’s top three. Public, kept for 26 weeks. Where weekly cohorts are switched on, the group of up to thirty wallets each wallet is ranked in that week is kept with it.
Clusters: the clusters a wallet joined, at most three, signed by that wallet, and for each cluster its members with the moment each joined. Public: a cluster's page lists its members.
Quest campaigns: where they are switched on, each campaign's awards: the wallet, the campaign, the points and the moment, folded from public chain data and this site's own public records. Public, on the quests board.
Launch plans: for a coin whose creator planned its launch in the Studio, the coin, its ticker, the launching wallet, the launch moment and whether its first-100-holders quest and day-one badge are on. Public.
Chat rooms: in a coin’s room or a space’s channel, the message you post, the moment, and who posted it as the room shows them (your shortened wallet, your X handle, or a pseudonym for a Google sign-in) with an id for that person (your wallet address, or for an X or Google sign-in a keyed hash that cannot be turned back into your X id or Google identifier, or matched with it anywhere else), with the line beside the name (“creator”, or the share of the coin you held when you posted). Kept for thirty days on our realtime service’s own disk at Fly.io, or in the Blob store when that service is off, then deleted. Public: anyone can read a room. A report you file keeps the message, your reason and who filed it, for the moderators only. We keep no direct messages, because there are none. Rooms keep a first-seen moment per sign-in so a new account waits a day before posting links. A person a moderator stops from posting is kept on a list, by their sign-in's identifier, until the ban is lifted. A coin room’s creator may make it for holders: posting, or with holders-only reading the room itself, then needs a wallet sign-in whose balance of the coin, read on its chain when you open the room and every few minutes while you stay, is at or above the line they set. The balance is read and not kept.
Creator AMAs: a coin’s creator may plan an AMA, which keeps its time, its length, its topic and the creator’s name as the room shows it. A question keeps its text, the moment and who asked as a room shows them; an upvote on a question keeps the id a room shows for the voter, and only the count is shown. A “remind me” keeps the id of this browser’s push subscription or the Telegram chat that opened the bot’s link, for the one reminder and nothing else. Kept with the coin, the current AMA and the five before it. Public, except who voted for what.
Calls, insights, wallet notes and polls: a call keeps the coin, the market cap our indexer read at that moment and who called it; an insight or a note on a wallet keeps its text, the transactions it cites, what the chain said about them, the wallet that signed it and the wallet it is about, and any reply that wallet signs, with a moderator’s decision on that reply; a poll keeps its question, its answers and one answer per voter; a “Helpful” keeps one mark per voter. Public, except who voted for what, which is shown to the voter alone. A voice stage, when one is switched on, runs on LiveKit; we send it the id and the name a room shows for you (never your X id or your Google identifier) to join, and keep nothing of what is said.
Live video: where it is switched on, a coin’s creator may stream on the coin’s page through LiveKit. Nothing is recorded: the picture and the sound go from the creator through LiveKit’s servers to the people watching and are kept by nobody, us included. LiveKit receives the IP address of everyone who streams or watches, and the id and the name a room shows for a signed-in viewer (never your X id or your Google identifier); a signed-out viewer joins under a random id made for that join. Per coin we keep when its stream started and ended, the wallet that streamed, the wallets that reported it and when, and its minutes; per month, the total minutes watched, as one number; and a ban, with its reason, for a wallet a moderator stops from streaming. A report of a stream goes to the same moderators as a chat report.
Launch parties: a party planned from a Studio project before its coin exists keeps the project’s ticker, name and line, the time, the chain and the space, and the sign-in that planned it; the room shows only the host’s display name. It is deleted when the host calls it off. A launch scheduled for a time (from Create or the Studio) keeps the coin it will be (name, ticker, line, picture link, X and Telegram links, chain, opening buy), the time, the wallet that scheduled it, and once it launches the coin and the transaction; the page at /party/<id> is public and shows that wallet’s address, as every coin shows its creator’s. A moderator may hide a scheduled launch’s page, which keeps the record with the reason and answers nobody. A “remind me” keeps, on that party, the id of this browser’s push subscription or the Telegram chat that opened the bot’s link, and nothing else (no IP, no wallet, no name); it is used for the two notices about that party (starting, and live) and nothing more. The “you both hold” hint beside a name in a room reads public holdings from our indexer when you open the room and keeps nothing.
Scheduled posts: where they are switched on, a post you schedule in the Studio keeps its text, what it waits for (a launch, a graduation, a market cap, a holder count or a time), where it goes (your X, your coin’s Telegram group), its picture if you attach one and whether a model drew it, the wallet that scheduled it, and once it goes out, when and what X and Telegram answered (the post or message id, or the reason it did not go out). It is private to that wallet’s Studio session. Connecting X for posting is its own permission, separate from signing in: it asks X for tweet.read tweet.write users.read media.write offline.access, so that a post can go out on your account hours after you wrote it, with its picture. We keep your X numeric id, your public @handle, the scopes X granted and when you connected, and the access and refresh tokens X issues, sealed with AES-256-GCM under a key only this server holds; they are used for nothing but the posts you schedule, and Disconnect deletes them here and revokes them at X. A post to your coin’s Telegram group is sent by our bot, which has to be an administrator of that group.
Moderation: a denylist per chain, holding the coin and a reason. The rules are published in the repository as docs/moderation.md.
Studio projects: the sentence you typed, the name, ticker, description and picture produced from it, the stage each project is at, the launch plan as you edited it with its quest and badge switches, and the coin website record (about text, a tagline, links, gallery, pinned post, roadmap, team, FAQ, the order and visibility of its sections, and a holders-only section with its threshold). Kept under your sign-in identifier.
Suggested pair tokens: a token put forward for the tier-2 checker keeps its address, its symbol, how many times it was suggested and the checker’s verdict. Not who suggested it: a wallet signs the suggestion, and the signature is checked and not kept. While a token waits for the checker it carries a keyed hash of the wallet that put it forward, which cannot be turned back into the address, is never shown, and is deleted once the checker takes the token; it is there only so one wallet cannot hold more than two tokens waiting. A token nobody puts forward again leaves the queue after fourteen days.
Kept kits: a saved Studio result, under a random sixteen-byte id, so a link restores it. With AI on and a sign-in, Create keeps its draft the same way as you work: the sentence, the name, the ticker and the line, and the picture you picked, as a kept kit and as a Studio project.
Coin website visits: one count per UTC day, a count per referring host and a count per campaign tag (the utm_source and utm_campaign of the link you followed), for the last thirty days. No IP address, no user agent, no cookie and no identifier of any kind, so nothing in it can be traced back to a person.
Buyback posts: where auto-buybacks are switched on, a creator who chooses in the Studio to post their coin’s buybacks gives us that choice to keep: the coin, where the posts go (their X, the coin’s Telegram group, and whether the group gets a line for every buyback), the wallet that chose and when. For each such coin we keep which buybacks and which days have been posted and what X and Telegram answered. It is private to that wallet’s Studio session, and switching it off deletes the choice; what already went out stays where it went. The auto-buyback itself, its terms and every buyback it makes are on the chain and public, like any trade.
Visits a scheduled post brought: for each post that went out, an hourly count of the visits its links brought to the coin’s website (the post’s own campaign tag), for up to thirty posts at a time, kept thirty days. Anonymous counts, like the visits above: nothing in them names a person, a wallet or a browser.
Errors: When a page breaks, or a wallet step fails for a reason that is not yours, we keep the error’s text, the page you were on (as a pattern, never an address or a wallet) and your browser’s name and major version, for seven days, to fix it. No IP, no wallet beyond its short form, no cookie or header is kept with it.
Coin website domains: when a coin’s creator puts its website on a domain they own, the domain, the coin’s site name, the creator’s wallet and when it was proved. Public in effect, since the domain serves the page. To check it we look up that domain’s public DNS records, and nothing about who visits it.
Coin website holders sections: to open one, your wallet signs a message saying which site it is opening, and we read that wallet’s balance of the coin on chain at that moment. The signature, the wallet and the balance are checked and not kept.
Referral arrivals: once you open /affiliate, or a partner page is set up with your referral code, a count of arrivals through links carrying that code: per UTC day for thirty days, per utm_source and utm_campaign, and per kind of page landed on. No IP address, no user agent, no cookie and no identifier of the person who arrived. Your wallet signs to read it, and the signature is checked and not kept.
Partner pages: a partner’s name, words, logo, colours, links and payout wallet, set up by Parabolic at the partner’s request and public on their page at their own subdomain; and which coins are listed there, attached by the coin’s creator with a signed request (checked and not kept) or by us.
Browser alert subscriptions: the push endpoint, its public key and its authentication secret, the coins and the kinds of alert chosen, and a wallet address if you give one for sell alerts. A wallet is attached only when that wallet signs for this browser's own subscription, so knowing an address is not enough to receive its alerts.
Telegram alert subscriptions: the chat id, the coins it watches, the kinds of alert chosen, and the wallet address the chat set with /wallet if it set one. These live in a file on the bot’s own disk at Fly, not in the store above.
Alert contacts: where alerts by email or text are switched on, the email address or phone number your wallet asked us to send its price alerts to, whether it is confirmed, which alerts you chose, when each alert and confirmation went out over the last day, and a hash of the pending code and of the unsubscribe link (never the code or the link themselves). Nothing is sent to it but one confirmation until you confirm, and every alert carries a link to stop them. Removing it, or that link, deletes the address or number.
Telegram mini app links: where trading inside Telegram is switched on and you choose to send a wallet’s alerts to your chat with our bot, your Telegram user id, that wallet and when. The name and username Telegram passes the mini app are checked with its signature and not kept.
Telegram group mirrors: when the administrators of a public Telegram group make our bot an administrator of it, the messages of that group for the last seven days, at most five hundred: each message’s number, the author’s display name, its text, what it replies to, whether it carried a picture, its reaction counts, whether the author administers the group and whether the author is a bot account; and the moments members joined, counted with no name attached. No Telegram user id and no username is kept or published. It is shown read-only on the page of the one coin the group belongs to, and nowhere else, and is deleted when the creator or Parabolic switches that coin’s chat off. A group no coin names yet is kept the same way and shown nowhere until a coin names it, for at most two hundred such groups, the least recently active forgotten first. A picture is fetched from Telegram through this site when a reader opens the page, so your browser never contacts Telegram. Where a model key is set, the last hour of a mirrored group’s messages (at most 150, each cut to 280 characters), with the display names the group shows and whether each author administers it, goes to OpenRouter (Anthropic’s Claude Haiku) at most once every five minutes per group, for the three-line summary on the coin’s page; nothing about the reader goes with it.
Uploaded images: a coin’s picture, an image on a comment and a picture in a coin website’s gallery all go through the same upload. Stored privately and served from this site, so the URL written into the token’s constructor keeps resolving.
Embeds: a coin card, ticker, badge or launch widget that another site puts on its page under /embed keeps nothing at all: it sets no cookie, writes no browser storage and records no view. The site that embeds it sees that you loaded its page, under its own policy.
Cross-chain buys: where buying a coin with money on another chain is switched on, the order your wallet signed (the coin, the amount, the price bound and when it expires) with its signature, the route, the bridge transaction it waits on, the balance it started from and its status, under your wallet address, the last hundred kept; and a list of the open ones by wallet, so the order executor can watch them. Private to your wallet.
Gasless trades: where gasless trading is switched on, a count per sign-in per day of the trades the paymaster paid for, and the day’s total it paid for everyone, kept to apply the daily limits.
Trades on other launchpads: where another launchpad's coins are listed, our reader keeps the trades it could tie to the wallet that sent them, from the chain itself: the wallet, the coin, the side, the amounts, the transaction and the moment. On Solana they are kept for 7 days; on other chains, the latest 512 for each launchpad. Public chain data, shown in feeds and on a wallet's page, and on Solana readable by wallet address the way that address's trades here are. A trade the reader could not tie to its sender is counted and left out, never guessed.
Board records: which coin held the top of Explore and since when, and the day’s top traders, both folded from public chain data.
Announcements: the first sentence of a post from our own announcements channel, for the news line.
Communications: anything you send to our contact or security address.

Studio sign-in

To keep the projects you make in the Studio we have to know which ones are yours, so signing in stores one identifier and a session cookie. With a wallet it is your address, proved by one signature; the wallet is asked to sign once, not once per save. With X it is your numeric account id and your public @handle, from the users.read tweet.read scopes, which are the smallest pair X accepts. With Google it is the opaque sub identifier and nothing else: we ask Google for the openid scope alone, so we never receive your name, your email address or your picture. With X through Dynamic, where that is switched on, Dynamic creates a wallet for you and holds one of its two key shares; it receives your X id and handle and your IP address, under its own privacy policy. We receive the wallet address, your X id and the handle, nothing else, and keep the X id beside the address so the same X sign-in finds the same wallet. Two things read that pairing and nothing else does: where airdrops are switched on, a creator signed in to the Studio can look up which wallet an @handle on their airdrop list stands for, and gets an address back only for an X account that signed in here and has a wallet bound to it; and the X launch bot reads it by your numeric X id, to prepare a launch for the wallet you bound. There is no public lookup from an X account to a wallet. That wallet is a wallet, so it can launch. Only a wallet can launch a coin, because a launch is a transaction and the launching address is the address a coin has for ever. Where the site shows who you are (a chat room, a call, a profile, a voice stage), an X or Google sign-in appears under a keyed hash of its identifier, which cannot be turned back into it or matched with it on any other site; the identifier itself is shown to nobody but you. Nothing else is shared with anyone, and signing out clears the cookie.

Cookies

__Host-pb_studio, the Studio session: the identifier above, your public @handle if you signed in with X, the moment it was issued and the moment you signed in, signed with HMAC-SHA256. HttpOnly, so no script on the page can read it, SameSite=Lax, Secure, and only this site’s own host can set it. It expires 30 days after the last time the site read it, and 90 days after you signed in whatever happens in between. Signing out everywhere ends every copy of it at once. Until 10 November 2026 the same session may still arrive under its earlier name, pb_studio, which the site reads once and clears.
__Host-pb_oauth, set only while you are signing in with X or Google: the PKCE verifier, the state value, which of the two you chose and the page on this site to return you to. HttpOnly, SameSite=Lax, Secure, sent to this site’s own host only, for ten minutes, cleared in the same response that spends it.
__Host-pb_xpost, set by /api/v1/posts/x only while you are connecting X for posting: the PKCE verifier, the state value and the wallet that asked. HttpOnly, SameSite=Lax, Secure, sent to this site’s own host only, for ten minutes, cleared in the same response that spends it.
There is no advertising cookie and no cross-site tracker on this site.

What your browser keeps

We do not read your browser’s storage. Some of what it holds you later send us by an action of yours: pb-ref is written into the memo of a buy you sign, and so onto the chain; pb-watchlist is signed into your wallet’s record the next time you star a coin; pb-studio-pending is posted to the Studio when you sign in and the run starts; parabolic:promote:sent is the payment hash we read back to verify a booking; parabolic:pro:sent is the payment hash we read back to grant a Pro plan; pb-hyper-rules: is signed into your wallet’s watcher record when you save your watchers or alerts; and pb-groups-key: is sent back when the wallet tracker reads your own Friends and names, or /wallet-groups reads your wallet groups. Those records are the ones described above. Clearing your site data removes every key below.
Local storage: pb-theme and pb-theme-hyper (light or dark, for the normal site and for the dark room that Hypermode and Killermode share), pb-watchlist and pb-watchlist-synced (the coins you starred on this device, including stars you pressed while connected that are not yet signed into your wallet’s record, and whether that wallet declined to sign them, so the offer to sign survives a reload), pb-ref (a referral code you arrived with), pb-create-draft (an unfinished create form), pb-create-pending (a launch you sent that has not confirmed yet: its transaction hash, chain, the contracts it was sent to, your wallet address and the ticker, kept so that a reload re-reads its receipt and cannot send a second launch; removed once the receipt settles it), pb-swaps: followed by a wallet address (the swaps that wallet made on the Swap page from this device, each with its transaction hash, chain, the two assets and their amounts, so Recent swaps lists them; it never leaves this device), pb-room-read-v1 (the latest message you read in each room on this device, used for unread badges), parabolic.svm.pending. followed by a Solana wallet address (a signed trade and its confirmation ticket, kept to recover an uncertain broadcast without sending a second trade), pb-board-prefs (the board’s tab and view), pb-chart-prefs (how you last set a coin’s chart: price or market cap, the line or candles, and a candle interval if you picked one), pb-discover-seen (the coins you passed on in Discover, each forgotten after a week; it never leaves this device), pb-buy-same-last (the amount you last bought with Buy on a trade, or chose under Settings on My Page, for each money, so the buy sheet opens on it and a trade’s Buy button shows it; it never leaves this device), pb-me-holding (whether My Page shows what you hold as tiles or as a list; it never leaves this device), parabolic:sol-wallet (the name of the Solana wallet you last connected, so a later visit reconnects it without asking; it never leaves this device), pb-safe-mode (whether you chose Safe in the mode switch or turned safe mode on anywhere else; off by default, kept on this device only and never on your account. It is the only thing the mode switch keeps beyond the tab: Normal stores nothing, and Hyper and Killer are each the page you are on; choosing either also remembers the page you left, until the tab closes (pb-last-normal-path, below)), pb-announced (whether you have opened the launch post for a coin), pb-points- followed by a wallet address (that wallet’s last points figure, so the page opens on a number), pb.approve. followed by a chain, a token and a spender (whether you chose to approve once or exactly, so you are not asked twice), pb-install-dismissed, pb-visits and pb-visit-at (the install prompt, shown from the second visit on a phone), parabolic:bell-seen (the moment you last opened the bell), parabolic:bell-claim-seen (the claimable balances the bell had already shown you, so it does not keep announcing the same one), parabolic:bell-plan-seen (the plan reminder the bell last showed you, so it rings once), parabolic:promote:sent: followed by a wallet address (a promotion payment sent but not yet confirmed), parabolic:pro:sent: followed by a wallet address and a chain (a Pro payment sent but not yet confirmed), Hypermode’s own: pb-hyper-prefs (your buy sizes, sell shares, slippage and one-press setting), pb-hyper-basket (the coins you ticked to buy together), pb-hyper-wallet-proofs (for each extra wallet you added to trade from, its address and the one plain message it signed to show it is yours; never a key, and it stays on this device) and pb-hyper-wallet-set (which of those wallets trade and how an amount splits between them), pb-hyper-focus and pb-hyper-recent (the coins you last opened in the terminal), Killermode’s own: pb-killer-blocks (the live blocks’ size threshold for each chain, whether you show new coins only, and the ping you chose, off by default), pb-killer-coins (the coins you pinned in Killermode’s terminal and the last ones you opened there) and pb-killer-presets (your three buy amounts there), pb-killer-room-seen (that this device has opened Killermode’s room, so the next visit loads it sooner), none of which leaves this device, pb-hyper-multi and pb-hyper-multi-prefs (the coins pinned in Multi and its layout), pb-hyper-rules: followed by a wallet address (your watchers and alerts as you last edited them), pb-hyper-rules-meta: followed by a wallet address (their quiet hours, whether Telegram was linked, and whether a Telegram account proved that wallet in our mini app, as the site last answered), pb-hyper-alerts-seen (the moment you last read your alerts), pb-hyper-keys-seen (whether the list of keyboard keys has been shown on this device, so it opens by itself once) and pb-hyper-muted (coins you muted in your alerts), Killermode’s bots: pb-killer-paper:v2: followed by a wallet address (this device’s copy of your paper bots’ book, so the room opens on it at once; the book itself is kept on our side, as the Killermode line above says), pb-killer-paper:v1: followed by a wallet address, or anon when no wallet is connected (the paper bots of the room before the terminal, carried into your book once you sign in and then removed; nothing in either is signed or sent) and pb-killer-accept: followed by a version and a wallet address (that you ticked what the bots can and cannot do before a first session; it never leaves this device), pb-groups-key: followed by a wallet address (the key your wallet was handed when it signed on the tracker, so this device can read that wallet’s private Friends, names and wallet groups without asking again), parabolic:key-saved: followed by a wallet address (that you said you saved the key of a wallet made on Parabolic, so the backup card stops asking on this device; never the key itself), parabolic:account: followed by a wallet address (the name, picture, tier and progress the account button last showed for that wallet, so it is drawn at once on your next visit; it stays on this device), parabolic:terms (the wallets that accepted the terms in this browser and the version each accepted, so they are not asked again here), and keys beginning wagmi., which your wallet library uses to remember the connection.
Dynamic’s keys, only where signing in with X to a wallet made for you is switched on (read off a build with it switched on, 7 October 2026). On every page, once its sign-in has loaded: dynamic_device_fingerprint, dynamic_store and dynamic_ followed by Dynamic’s environment id and _state in local storage, and two IndexedDB databases, dynamic_ followed by the environment id and _keychain, and base-acc-sdk, which the Base Account wallet connector Dynamic carries opens. After you sign in, its code names these as well, for your session, the wallet you last used and its settings: dynamic_authenticated_user, dynamic_connected_wallet_ns, dynamic_last_used_wallet, dynamic_context_session_settings, dynamic_embedded_wallet_session_settings, dynamic_wagmi_session_settings, dynamic_client_session_keys, dynamic_secure_enclave_session_keys, dynamic_keychain, dynamic_social_storage, dynamic_otp_verification_state, dynamic_captcha_token, dynamic_delegation_state, dynamic_embedded_secure_banner, dynamic_phone_input_default_country, dynamic_wallet_picker_search, dynamic_exchange_picker_search, dynamic_bridge_onboarding_completed, dynamic_newtoweb3_wallet_extension_installed, dynamic_svm_network_id and dynamic_enableTroubleshootMode. Parabolic’s own code reads none of them; what it takes from Dynamic is the sign-in token it sends us once, which carries the wallet address, X id and handle above. Dynamic’s wallet frame loads from Dynamic’s own address and keeps whatever it stores there, under its policy.
Session storage, cleared when the tab closes: pb-created-projects: followed by a wallet address (recent receipt-confirmed launches, so My Page shows them before the indexer catches up), pb-studio-run and pb-studio-pending (a Studio run in progress, so signing in does not cost you what you typed), pb-visited: followed by a ticker (so one reader is counted once per session on a coin website), pb-ref-click (the referral codes this tab has already counted an arrival for, so one reader is counted once per session), parabolic:onboarding-shown (so the set-up popover opens once), parabolic:key-backup-shown (so the card asking you to back up a wallet made on Parabolic opens by itself once), pb-board-scope (the chain filter you last had on Explore, so the Explore link takes you back to it), and pb-last-normal-path (the page you were on before Hypermode or Killermode, so the mode switch takes you back there).

IP addresses

Your IP address reaches our hosting provider and our rate limiter, which counts recent requests per address in memory to stop abuse. We do not write it to any record and we do not store it with anything you post. It reaches others by the way the site works: chain reads run in your browser, so the RPC providers below see it on every read; X or Google see it while you sign in; WalletConnect's relay sees it during a QR connection; Vercel Web Analytics, where it is switched on, turns it into a hash rather than keeping it; and for a plan paid by card through MoonPay our server puts a keyed hash of your IP address into the link it signs and MoonPay sees the address itself when its page opens.

Analytics

No analytics or tracking script runs on this site. If we add one it will be cookieless, and this page will say so before it ships.

Who else receives data

Vercel hosts the site and holds the record store above, and sees the requests your browser makes to it.
Fly.io runs the indexer that reads each chain and the Telegram bot, and holds the file of chat watchlists on the bot’s own disk.
RPC providers answer the chain reads a page makes from your browser, so they see the addresses being read and your IP address with them. On Arc that is Alchemy and Arc’s own public endpoint. On Robinhood Chain a read goes to GlobalStake first, then BlockMachine, then Robinhood Chain’s own public endpoint, each asked only when the one before it refuses the read or does not answer; the wallet you connect is given Robinhood Chain’s own endpoint for what it sends. On Solana, where it is switched on, a page’s own reads go to Alchemy, and our server’s reads and the trades it sends for you go to Alchemy. Where a key for one is set, our server also reads a Solana coin’s holder list from Bitquery or SolanaTracker, by the coin’s address and nothing else. On Ethereum it is MEV Blocker’s public endpoint, and on every other chain that chain’s own. Our server makes some of the same reads, and those hosts then see our server’s address and not yours. On Robinhood Chain our server’s reads, and those of the live readers we run on Fly.io, go to Alchemy first.
DFlow and Jupiter, where trading Solana coins is switched on, quote and build each trade. Our server asks them for a price and an unsigned transaction, and sends your wallet's public address, the coin, the amount and your slippage with the request, so they see our server's address and not yours. Your wallet signs the transaction and our server sends it to Solana through its RPC provider. Jupiter also answers our server's read of SOL's price in dollars, with nothing about you.
OpenRouter and the model providers behind it run the Studio. The sentence you type goes to Anthropic’s Claude Haiku for the name, the ticker and the line, and the picture brief and any reference image you upload go to OpenAI’s GPT Image model. Nothing identifying you is sent with either: no wallet, no session, no identifier. In the Studio, nothing is sent until you press its generate button. On Create, optional AI sends the sentence after you pause typing while AI is on; turning AI off stops these requests. Picture requests run only when you ask for them. Drawing a picture needs you to be signed in: our server reads your session to count your pictures, six in ten minutes, and sends none of it to the model.
OpenRouter also draws the Posts tab’s memes, where pictures are switched on: the coin’s public name, ticker, line and picture (or a picture you upload instead) and the idea you type go to the same OpenAI image model, with nothing identifying you. The picture that comes back is marked AI-made. X, where you connect it for posting, receives the posts you schedule and their pictures, sent from our server under your account’s permission, and the weekly digest’s post on Parabolic’s own account where that is switched on; the digest carries public figures about coins and nothing about you.
OpenRouter also writes the intelligence panel’s brief and its answers to Ask about this coin, with Anthropic’s Claude Haiku: the coin’s public facts from its report go with each, and for Ask the question you type. No wallet, no session and no identifier goes with either. It also receives the Telegram hour summary’s messages described under Telegram group mirrors.
Pinata publishes a coin’s picture and its details to IPFS when you launch it on pump.fun from Create, where that is switched on: the picture, the name, the ticker, the sentence and the links you gave, which are then public and permanent, as every pump.fun coin’s are. Nothing identifying you goes with them, and pump.fun’s own servers receive nothing from ours; your wallet signs pump.fun’s program on Solana directly.
X answers the public oEmbed request that reads a confirmation post, and runs the sign-in if you choose it. Google runs the sign-in if you choose it.
Telegram receives your chat id if you ask the bot for alerts. Our bot receives the messages of a group only when that group’s administrators make it an administrator, and our server reads the public page Telegram publishes for a coin’s channel (t.me/s/), the way any browser would.
X, where the coin page’s X panel is switched on, answers our server’s requests for a coin’s own account and its public posts, and for recent public posts naming the coin’s ticker with their authors’ public handles and follower counts, which we count into figures and cache for minutes. Where the X key is set, it also answers our requests for the public counts, creation date and post dates of an X account a wallet confirmed, for the KOL checks. Nothing about you is sent with them.
Dynamic, where signing in with X to a wallet made for you is switched on, creates that wallet and holds one of its two key shares; your device holds the other, and Parabolic holds none. It receives your X id and handle and your IP address while you sign in, under its own privacy policy.
Pimlico, where gasless trading is switched on, relays a trade from the wallet made for you to Robinhood Chain. It receives the trade as a signed user operation, which names your wallet address, through our server, so it sees our server’s address and not yours. Parabolic’s paymaster contract pays the network fee in ETH and the same trade pays it back in USDG at cost plus 25%, shown before you sign.
Across and Circle, where buying a coin with money on another chain is switched on, move the money between chains. Our server asks Across for a quote naming your wallet as the depositor, the recipient and the refund address, with the amount and the two chains; for a transfer through Circle’s CCTP, our order executor asks Circle’s attestation service for it by its transaction hash. Your wallet sends the bridge transaction itself, and the money arrives in the same wallet on the other chain.
Relay, where swapping between chains on the Swap page is switched on, fills the swap. Our server asks Relay for a quote naming your wallet as the payer and the recipient, with the amount, the two assets and the two chains, and later for that swap’s status by its request id. Your wallet sends the deposit itself, and the money arrives in the same wallet on the other chain, or comes back on the chain it left.
WalletConnect relays the connection if you connect by QR code rather than a browser extension.
MoonPay runs a card, Apple Pay or Google Pay purchase of the plan's stablecoin, only if you start one and only where it is switched on. Our server signs the link that opens MoonPay's page, which names your wallet address, the coin, the chain and the amount, and carries a keyed hash of your IP address so the link opens only on your device; MoonPay sees your card, your identity documents if it asks for them, and your IP address itself, under its own privacy policy. We receive none of them.
Resend carries the one email a ticker reservation is for, and price alerts by email and their confirmation, where each is switched on. It receives the address and the message, and nothing else.
Twilio carries price alerts by text and their confirmation code, where they are switched on. It receives the phone number and the message, and handles a STOP reply itself.
Farcaster: where the mini app is switched on and you open Parabolic inside a Farcaster client, the page asks the client for its wallet, to sign on the coin’s chain, and to open links. We do not ask it who you are and keep nothing from it; the client sees what you do inside it, under its own policy.
Our fonts, our scripts and the pictures uploaded here are served from this site. A coin’s picture that lives elsewhere (the address its creator wrote into the token, on any host or on IPFS) is fetched by this site and served from here, so your browser does not contact that host; the copy is kept so it is fetched once. On the create form, a preview of an ipfs:// link goes through the public gateway at ipfs.io.

Why we process it

To run and secure the interface, to keep the work you make in the Studio, to pay referrals and creator fees correctly, to comply with law including sanctions screening, and to improve the product with aggregate statistics. GDPR legal bases: legitimate interests, contract, and legal obligation.

What you can delete

You can delete a Studio project and a coin website record from the Studio, clear your browser storage at any time, sign out to clear the session cookie, turn off alerts to delete a subscription, remove a profile link from either of its two wallets, and email contact@parabolic.family to delete a ticker reservation. A comment can be hidden by the coin’s creator, which takes it off the page; there is no way here for us to delete one. What nobody can delete is anything on the chain: a launched coin’s name, ticker, description and image are written into the token’s constructor with no setter, and a forum post signed on chain is a transaction. We say this before a launch rather than after.

Public by design

A coin website, its about text, its links and its gallery are public to anyone with the address. Comments, reactions and graduation calls are public on the coin they are made on. Watchlists and follows are readable by wallet address, the way that address's trades are. A profile link is readable by either wallet's address until one of the two removes it. A promotion is labelled wherever it renders, and a confirmation is public on the coin and readable by the X handle that made it. None of it is private.

Retention

Interface logs are kept for a limited period for security, then deleted or aggregated. Coin website visit counts keep thirty days and the eight busiest referring hosts and campaign tags, and the rest is forgotten rather than summed. Records you can delete are deleted when you ask. On-chain data is permanent.

Your rights

Depending on where you live you may have rights to access, correct, delete, port or object to processing of personal data we hold. Contact contact@parabolic.family. We cannot alter on-chain data, and we will tell you so rather than pretend otherwise.

International transfers

Our providers may process data outside your country under appropriate safeguards.

Children

The interface is not directed at anyone under 18.

Changes

We will post changes here with a new date.