Legal

Privacy Notice

This page is generated from the deployment’s data inventory. A notice written separately from the system describes what somebody believed on the day they wrote it; this one is missing a category only if the inventory is.

Operator and legal review required. This notice describes what the system does, accurately and in full. It makes no claim of compliance with GDPR, CCPA or any other regime, because compliance is a legal assessment nobody has performed here. The controller identity, the lawful basis and any data-transfer position are marked [REVIEW] and must be supplied before this can be relied on.

Who is responsible

[REVIEW] The legal entity acting as controller, its registered address, and a data protection contact are not stated. Inventing them would be worse than omitting them.

For anything factual about what is stored, the table below is the answer, and beta@stonereason.com reaches a person.

What is stored

Fifteen categories. Every durable store in the deployment appears here.

What	Why	Fields	Kept for	Who can read it
Accounts	To know who is signed in, and to let them sign in again.	Email address, an Argon2id password verifier, account state, email verification state, when it was created, a session epoch.	While the account exists. A closed account keeps its row, because payment and audit history refer to it; it can no longer authenticate.	The person themselves. An operator sees the address and the states, never the verifier.
Sessions	To keep somebody signed in without asking for a password on every page.	A SHA-256 digest of the session id, the account it belongs to, when it began, when it was last seen, the browser's user agent, a CSRF token.	Until it expires, is signed out, or the password changes — which ends every session at once.	The person themselves, on their settings page. An operator sees that sessions exist, never their ids.
Organizations and memberships	To hold projects for a tenant rather than for a person, so work outlives one account.	Organization id, name, when it was created, who owns it, membership rows with roles.	While the organization exists.	Members of that organization. An operator, through the console.
Projects	The commercial isolation unit: what a workload may reach, and what it may spend.	Project id, display name, status, environment, allowed networks, allowed capabilities, quota and rate policy.	While the project exists.	The organization's members. An operator, through the console.
API key metadata	To authenticate a request and decide what it may reach.	Key id, display name, status, scope (networks, capabilities, transports, environment), an IP allowlist where set, when it was created and last used, and a verifier.	While the key exists. A revoked key keeps its row so its past requests stay attributable.	The organization's members. An operator sees metadata only.
Usage accounting	To enforce a quota and to show a customer what they have used.	Per project and per window: request counts, response bytes, event deliveries, refusal counts.	Quota state is durable for the window it belongs to. Aggregates are bounded.	The organization's members. An operator.
Request logs	So a customer can see what their keys did, and an operator can answer a support question without guessing.	Timestamp, request id, project id, key id, network, method, transport, outcome, latency, response bytes, upstream call counts.	Bounded: the newest are kept and older ones are dropped. An operational record, not an archive.	The organization's members, on their usage page. An operator, through the console. The records are identical.
Beta analytics	To answer whether somebody who signed up ever made a successful call, and where people stop.	Event kind, when, and the ids it is about (account, organization, project, key, request). Acquisition context where a visitor's own URL carried it: the landing path, the referring host, and UTM source, medium and campaign.	90 days for events. Whether a stage was reached outlives the event, or a busy month would make every customer look new.	An operator, through the console. Not shared with anybody.
Payments	To watch for a payment you are expecting and tell you when it arrives and settles.	Watch id, network, asset, recipient address, routing value, expected amount, match and finality policy, creation height, a cursor, and the occurrence identity of anything detected.	While the watch is held, plus its receipt.	The organization's members. An operator.
Webhook configuration	To deliver a payment event to your endpoint and let you verify it came from here.	Endpoint URL, status, a signing secret, delivery attempts and their outcomes.	While the endpoint exists.	The organization's members. An operator cannot retrieve a signing secret.
Support requests	To answer a question somebody asked.	Category, subject, the message, state, and safe context: account, organization, project, page, time, and a request id where given. Notes from either side, with internal notes marked.	Bounded. Closed requests are dropped first; an open one is never dropped.	The person who opened it, minus internal notes. An operator.
Security events	So a customer can see what happened to their organization, and an operator can answer 'was this us'.	When, what kind, which organization, which account, the object acted on, and a short note.	Bounded per organization.	The organization's members. An operator.
Administrative authority	To decide who may operate this deployment.	Which accounts are administrators and at what level, a TOTP secret per administrator, single-use recovery code digests, administrative session digests, and whether a bootstrap credential is still unrotated.	While the authority exists. Withdrawing it removes the second factor and ends the sessions.	Operators, through the console.
Admin audit	So every consequential thing an operator does is attributable.	When, which administrator, what action, on what subject, the reason they gave, and what changed.	Bounded, newest kept.	Operators.
Published incidents	To tell every customer what is wrong, deliberately.	Title, impact, components, when it started and resolved, and an append-only list of updates.	Bounded history; an open incident is never dropped.	Everybody. This is the public status page.

What is never stored

Per category, and by construction rather than by policy — in most cases the record has no field that could hold it.

Accounts: The password itself is never stored, in any form that could be reversed. Nothing can reveal it, including us.
Sessions: The session id is never stored. Only a digest of it.
Organizations and memberships: No billing details, because nothing is billed.
Projects: No price, no plan name, no tier. There is nowhere in the record for one to appear.
API key metadata: The key secret is never stored. It exists in exactly one response body and nowhere else — not for support, not for an operator, not for us.
Usage accounting: No per-end-user data. This counts a project's calls, not a project's customers.
Request logs: No request body, no response body, no headers, no key. The record has never had a field for any of them, so there is nothing to redact.
Beta analytics: No third-party pixel, no advertising identifier, no cookie shared with anybody, and nothing that follows a person off this site. The referring host is kept and the referring URL is not — the other site's path is their visitor's business. A property whose name looks like a credential is refused rather than stored.
Payments: No custody and no private key. The addresses are yours; StoneReason only reads them.
Webhook configuration: A signing secret is never rendered after it is issued.
Support requests: An API key, an authorization header, a password, a private key or a request body cannot be attached. The guard refuses a field whose name looks like any of them.
Security events: Never a secret, a password or a token. The note is a sentence, not a payload.
Administrative authority: A TOTP secret is a shared secret and has to be stored to verify a code; it is never rendered after enrolment. Recovery codes are stored as digests.
Admin audit: Never a secret. The reason is a sentence an operator typed.
Published incidents: No provider name and no internal topology. An update is written for customers to read.

Cookies and browser storage

Three cookies, all of them strictly necessary. Nothing else is written to your browser.

Name	Kind	Purpose	Lifetime	Flags
`__Host-sr_session`	Cookie	Keeps you signed in to the dashboard.	30 days, or until you sign out or change your password.	HttpOnly, Secure, SameSite=Lax
`__Host-sr_form`	Cookie	Proves that a sign-up or sign-in form came from this site, so another site cannot make your browser submit one.	One hour.	HttpOnly, Secure, SameSite=Strict, __Host- prefixed
`sr_ops`	Cookie	An operator's administrative session. Never set for a customer.	30 minutes, and 10 minutes idle.	HttpOnly, SameSite=Strict

What is not used

localStorage — nothing is written. The site and the dashboard serve no script that could.
sessionStorage — the same.
IndexedDB — the same.
Third-party cookies — none. No analytics script, no advertising tag, no embedded widget, no font or asset loaded from another origin.

There is no consent banner, and that is a decision rather than an oversight. Every cookie above is strictly necessary and there is no analytics, advertising or third-party storage to consent to. A banner here would be asking permission for something that is not happening, which teaches people to click through the ones that matter.

Where the data goes

Nowhere it does not have to. There is no analytics provider, no advertising network and no data broker. Nothing here is sold or shared.
Upstream blockchain providers see the requests this service makes on your behalf — an address you asked about, for instance. Which providers are used is not published, because a page naming them would be telling customers which third party to blame for something StoneReason is responsible for.
No transactional email is sent, because no mail provider is configured. If one is configured later, it becomes a processor and this page will say so.
[REVIEW] Where the host is located, and what that means for transfers, requires the entity in section one to be fixed.

Your choices

See it. Your account, organizations, projects, keys, usage, request log and support requests are all on your dashboard.
End sessions. Sign out everywhere from your settings page. Changing your password does it too.
Close the account. From settings. It stops authenticating at once; the row is retained because audit and payment history refer to it, and saying “deleted” while keeping the row would be a lie.
Ask. Open a support request if you want something not in that list.

Last updated with the deployment. This page is part of the site build.