--- title: Privacy description: What data Superstables stores about services, submitters, early-access applicants, buyers, budget owners and visitors, where it is kept, and how to have it removed. canonical: https://staging-next.superstables.com/privacy last-updated: 2026-10-14 --- # Privacy > Most of what Superstables stores is about services, not people. This page lists exactly what the site records, why, and how to reach us about it. ## Reading the index Browsing the directory, calling the JSON API, using the MCP server or the natural-language endpoint requires no account, key or login. The only login cookie is the account session cookie, set when you sign in with your wallet. Requests pass through our hosting provider, which keeps standard request logs (IP address, user agent, path, time) as part of operating the service; we do not build profiles from them. On public pages, the X (Twitter) conversion tracking pixel loads so we can measure and reach visitors with X ads. When configured, Google Analytics records page views, early-access starts and submissions, and share actions. Submission events include role, stage and whether a referral was used. Account and approval pages do not load these analytics or advertising scripts, and neither does the private review area. Your theme preference is kept in your browser's local storage only. Our server sends Google Analytics events for setup-page requests, skill download requests, service-list requests, owner sign-ins, and budget and single purchase milestones. Depending on the event, these include a broad client category, the published skill filename and version, or the service-list type. We do not forward your IP address or account details. Google receives our server's IP address. ## Data about services Index records describe endpoints: name, description, category, URL, payment rails, chains, assets, advertised price, facilitator, the sources the entry was found in, the results of our liveness probes (time, status code, latency, how the challenge was detected), and a copy of the provider's icon from its website. Probe history is kept indefinitely. This is information the services publish about themselves; if you operate a listed service and want a record corrected or removed, contact us and we will delist it. ## Listing a service When you submit a service, we store the endpoint URL, the name and the contact you give us, and the time of submission. We probe the endpoint once immediately and, when notifications are configured, notify our team by email with the result. The contact is used only to reach you about the listing. Repeated submissions of the same endpoint within 24 hours are deduplicated. ## Early access The early-access form stores your email address, your answers to the qualifying questions, your optional free-text note, a short share code, the share code of whoever referred you, and the browser user agent and referring page at the time you submitted. One row is kept per email; submitting again updates it. When notifications are configured, our team receives an email for each application and a copy is posted to an internal webhook. Your place in line is derived from these rows and can be looked up with your share code; that lookup returns position and referral count only, never your email. ## Demo feedback The demo feedback form is no longer on this site; to reach us, use Contact. We keep reports submitted through Tally and still process any submissions it sends us: each holds your written report, any screenshots you attached and a contact if you gave one, with the form's fixed context (the demo page and its testing environment). Reports are copied into our issue tracker so the team can act on them. Nothing from the form is written to the index database. You can still ask us to delete a report. ## Buying a testnet service When an agent creates a purchase, we store the service and request it asked for, the payment terms (with the seller's own description of the request, as its payment request gave it), a short match code and the time. The agent's access token and the approval link's token are stored only as hashes. Purchase and budget requests store a hash derived from the caller's IP address, using the network prefix for IPv6. We use it to limit requests and scope purchase retries. To approve a payment, add an agent or open your account, you sign in with an Ethereum wallet (Sign-In with Ethereum) or a Solana wallet (Sign In With Solana). We then store your wallet address and wallet type, the time you signed in, a session (an HttpOnly cookie, kept as a hash on our side, ending after 24 hours idle or 7 days), and the limits on single purchases for your account. From the moment you prepare a payment, we also store, for that payment: the payer, recipient, amount and validity window, and what the payment needs on its network. On Base Sepolia and Arc Testnet, that is the authorization nonce and the order it commits to (the purchase, service, request, terms and a random salt). On Tempo Moderato, it is the transfer your wallet is asked to send. On Solana devnet, it is the transaction you are asked to sign and, once you sign it, your signature, which identifies the transaction on chain. We then store the transaction and what the chain shows about it, the service's answer and a receipt. In the browser-wallet flow, Superstables receives signed authorizations or transactions, not your wallet's private key. On Base Sepolia and Arc Testnet, your signed authorization is passed to the seller once and is not stored in our database. The requesting agent can read the purchase result using its purchase-scoped access token, including the paying address and the transaction. Payer and transaction details on the approval link are shown only when signed in to the owning account. Other link visitors can see status, service details and payment terms. Payments in the preview use test tokens, and transactions on a public chain are public. ## Budgets for an agent An agent asks for a budget, or to be added to your account, with a request signed by its own key. We store the request: its kind (adding the agent, or a transaction such as a grant, a gas top-up or a revoke), the network, the agent's address and the label it gave, an idempotency key and a hash of the request body, the transaction it asks your wallet to send and its decoded terms, a short match code, its state and the reason when it ends, and the times. The agent's access token and the approval link's token are stored only as hashes. To detect replayed agent requests, we store the agent's address, request nonce and a hash of the agent's address together with the signed request text. We do not store the agent's signature. When you add an agent, your wallet signs a short text naming this site, your address, the agent, its chain, the request and its match code. We store that signature with the request and give it to the agent as proof that you added it. Once the agent is added, we store your account, the agent's address, network and label, when it was added or removed, and the last cap confirmed on chain, with its transaction, block and time. On Solana devnet we also store the Solana address you proved when you added the agent. Budget requests also store your account and wallet address, and the transaction and chain receipt when there is one. Each change of a request's state is stored as an event. Payments an agent makes from a budget are sent by the agent, not recorded with your account; your account shows a budget's use as its cap minus what the chain shows remaining. ## Review build The password-gated product preview keeps everything you do in it (sample keys, policies, wallets, activity) in your browser's local storage. It sends nothing to a backend and moves no money. A small operator-editable settings store on the server holds site settings such as a published contract address; it contains no personal data. ## Where data lives The site is served from Vercel and the database is Neon Postgres. Transactional email, when configured, is sent through Resend. Demo feedback reports are collected by Tally and copied into Linear, our issue tracker. To generate index labels, we send OpenAI each listing's public service ID, name, description and source category. A language model generates a subcategory, tags, title and summary; the index derives the top-level category from the subcategory. Some listings may remain unlabelled. These providers process data on our behalf under their own terms. ## Your choices You can ask us to delete your early-access application, your service submission, your demo feedback, your account, purchases, receipts, added agents and budget records, or a listed service record, or to tell you what we hold about you. Signing out of your account ends the session at once. Use the contact links in the footer of any page. Standard AI crawler directives for this site are published in robots.txt, and machine-readable guidance in llms.txt. Last updated: 2026-10-14