Privacy

What we store,
and what we never touch.

Quorum is a research surface published by Mohawk Research. This page describes the personal information the service actually holds, written from the code that holds it rather than from a template. It is deliberately specific: where a generic policy would say “we may collect certain information”, this one names the columns.

Last updated: 31 July 2026

01 · Scope

Who this applies to

This policy covers quorum-signals.com and the Quorum mobile application. It applies to visitors who browse without an account and to people who create one.

You can read the leaderboard and the company pages without signing in. Everything in the inventory below exists only because you chose to create an account, and most of it only because you chose to subscribe.

Quorum publishes research about publicly traded companies. The company data on this site comes from public filings and market-data providers — it is not information about you, and it is not covered by this policy.

02 · Inventory

What we store, column by column

Account data lives in a single database. This is the complete list of fields in it that relate to a person.

Email address
Your login identity and the address we send account email to. Required.
Username
Always identical to your email address. We no longer collect a separate one.
Password hash
A bcrypt hash. We never store, log or transmit the password itself, and we cannot recover it.
Two-factor secret
Three fields: the shared secret behind the six-digit codes in your authenticator app, a flag for whether two-factor is switched on, and a counter of the last code used (which is what stops the same code being replayed). They are empty on an account that has never enrolled. If you turn two-factor off from your profile the secret is erased — the field is overwritten with an empty value and the flag is cleared, so nothing usable is left behind. The replay counter keeps its last value; it is a number, not a credential, and it cannot be turned back into a code.
Role
Either user or admin.
Email verified
Whether you have confirmed the address, and whether the account has been disabled.
Stripe identifiers
The customer and subscription IDs Stripe assigns you. They are references into Stripe's systems, not payment details.
Subscription state
Your plan tier, its status as Stripe reports it, and the date the current billing period ends. This is what decides what you can see.
Favourites
The ticker symbols you have starred, and when you starred each one.
Timestamps
When the account was created and when it last signed in successfully.
Short-lived tokens
Random strings issued for email verification and password resets, tied to your account ID with an expiry time. They carry no message content.
Mobile sign-in tokens
Signing in from the mobile application writes one row per token issued to you. What we keep is a SHA-256 hash of the token, never the token itself, so a copy of this table is not a set of working credentials. Alongside the hash: your account ID, an identifier grouping the tokens that came from the same sign-in, which kind of token it is, when it expires, whether it has been revoked, and when it was created and last used. The kinds are an access token, which lasts 15 minutes and is what the app sends on each request; a refresh token, which lasts 60 days and is replaced by a new one every time it is used; and a short pending token issued between your password and your two-factor code, which lasts 5 minutes, is single-use, and can read no product data at all. The pending token exists only for accounts that have two-factor switched on; without it, the password step issues the access and refresh pair directly. Tokens are revoked when you sign out of the app, when you change your password, and if a refresh token is presented a second time — that means two devices hold the same token, so every token from that sign-in is revoked and you sign in again. Every row is erased when the account is deleted.

That is the whole list. There is no separate profile, no analytics record keyed to your account, and no history of the pages you viewed.

03 · Exclusions

What we never collect

No payment card data ever reaches our servers. Both Stripe Checkout and the billing portal are ordinary redirects to pages hosted by Stripe — not embedded frames, not a payment form running on our JavaScript. Your card number, expiry and security code are entered on Stripe's own domain and are never transmitted to, processed by or stored on our infrastructure. This keeps us within the narrowest PCI scope there is (SAQ A).

We also do not collect your legal name, postal address, phone number, date of birth, or any government identifier. We do not store your IP address in the database. We do not build advertising profiles, we do not sell or rent personal information to anyone, and we do not use your data to train machine-learning models. Our email contains no tracking pixels.

If tax collection is enabled on a subscription, Stripe may collect a billing address on its own checkout page to calculate it. That address stays with Stripe; it is not sent to us.

04 · Basis

Why we are allowed to hold it

To provide what you asked for. Your email address, password hash, subscription state and favourites exist because the service cannot work without them. Creating an account is how you consent to that; there is no way to have an account without them. A two-factor secret is different: it is stored only if you choose to enrol, or if the account is an administrator one, where it is a condition of holding the role.

To keep accounts secure. Rate limiting, the replay counter on two-factor codes, and the last-sign-in timestamp exist to protect your account and ours. We consider this a legitimate interest, and it is narrow by design.

To meet legal obligations. Stripe retains transaction records for the periods tax and financial regulation require. Those records are held by Stripe, under Stripe's own retention rules.

You may withdraw consent at any time by deleting your account (section 08). Withdrawing it ends the service, because the data and the service are the same thing here.

05 · Processors

Who else handles it

These are every third party that receives any personal data, and exactly what each one gets.

Fly.io
Hosting. The application and its database run on a Fly.io machine in the yyz region (Toronto, Canada).
Cloudflare
DNS and reverse proxy for the site, so all traffic passes through Cloudflare's network; R2 object storage, which holds the continuous backup of the database; and Web Analytics (see section 06).
Stripe
Payments and subscriptions. Receives your email address and holds your payment method and billing history directly. We never see the card.
Resend
Transactional email only — verification, password reset, and subscription notices. Receives your email address and the message. We send no marketing email.
Google
Optional sign-in. Only if you choose “Sign in with Google”. We receive your email address and Google's confirmation that it is verified; we store only the address. We do not request or retain access to your Google account, contacts or files.
Have I Been Pwned
Breached-password screening when you set or change a password. Only the first five characters of a hash of the password are sent, which is not enough to identify the password or you. The password itself never leaves our server.
Financial Modeling Prep
Market and filing data. This flow is inbound only: company data is delivered into our database by our own pipeline. The application holds no outbound connection to this provider, and no user data of any kind is ever sent to them.

06 · Cookies

Cookies and third-party scripts

We set exactly one cookie, named mohawk_session. It appears only after you sign in. It lasts 12 hours, is marked HttpOnly so page scripts cannot read it, SameSite=Lax so it is not sent from other sites, and Secure in production so it travels only over HTTPS. It holds a cryptographically signed record of your account ID, your username and your role, plus the token that protects forms against cross-site request forgery. Signing makes it tamper-evident, not secret. There are no advertising, tracking or preference cookies.

Analytics. We use Cloudflare Web Analytics, which counts page views without setting any cookie, without client-side storage and without fingerprinting. It gives us aggregate traffic figures. It does not identify you and it is not linked to your account.

Scripts loaded from other domains. Being straightforward about this: the pages load fonts from Google Fonts and JavaScript libraries from unpkg and cdnjs, and the company pages embed a TradingView price chart. Because your browser fetches these directly, those providers can see your IP address, your user agent and which page requested them, under their own privacy policies. None of them receive your account data, and our content security policy restricts what may load to that list.

07 · Retention

How long we keep it

Your account. Kept for as long as the account exists. Cancelling a subscription does not delete the account; delete it (section 08) and it goes.

Tokens. Email verification links expire 24 hours after they are issued and password reset links expire after 2 hours. Both are single-use and stop working once used. Being precise rather than flattering: we do not yet run a scheduled job that erases the expired token rows themselves. The row is a random string and an account ID with no message content, and it is removed when the account is deleted — but it is not swept up on a timer today, and we would rather say so than describe a cleanup that is not written. Mobile sign-in tokens are the exception: an expired one is refused on every read path, and rows whose expiry has passed are deleted when the application restarts.

Backups. The database is replicated continuously to Cloudflare R2, so deleting something from the live database does not erase it from backup history the same instant. Replicated history rolls forward and older snapshots age out.

Logs. A failed sign-in or failed two-factor attempt writes a line to the application log that may include the connecting IP address. These are short-lived operational logs held by our host, not a database record, and they are not linked to browsing activity.

Billing. Stripe keeps invoices and payment records for as long as tax and accounting law requires, independently of us.

08 · Rights

Your rights over this data

Email dev@mohawkresearch.com from the address on the account and we will act on any of the following. We aim to respond within 30 days.

Access
Ask what we hold about you. We will send you the contents of every field listed in section 02.
Correction
Ask us to fix anything inaccurate. You can change your own password from your profile at any time.
Deletion
Delete your account — yourself from the mobile application, or by asking us. Any active subscription is cancelled first, then your account row, your favourites, your sign-in tokens and your verification and reset tokens are erased from the live database. Your Stripe billing records survive, because tax law requires it.
Portability
Ask for your data in a structured, machine-readable file, or ask us to send it elsewhere.
Withdraw consent
Deleting the account withdraws consent for everything in section 02.

On deleting your own account: self-service deletion exists. The JSON API behind the mobile application exposes DELETE /api/v1/me, so the app can delete your account from inside it, without going through us, once it is published. The request has to carry an explicit confirmation in its body, so a call that was retried or repeated by accident cannot destroy an account on its own.

Being precise rather than flattering: there is still no delete button on the website. If you use Quorum in a browser, email dev@mohawkresearch.com from the address on the account — that is a real route, handled by a person. We are not going to promise a web control that does not exist yet.

Either way, the deletion runs in the same order and fails closed. Any active Stripe subscription is cancelled first; if that cancellation does not go through, nothing is deleted and you are told so — a deleted account with a live subscription would be a card charged every month for a service you could no longer log in to or cancel. Once billing is settled, every sign-in token is revoked and removed, your favourites and your verification and password-reset rows are deleted, and the account row itself goes. Each of those is deleted explicitly, and since 31 July 2026 the database enforces its own delete rules as well, so the dependent rows go whether or not the explicit step is reached. Both paths are kept on purpose: neither one alone is something we want to depend on. What survives is what section 07 already describes: backup history until it ages out, and Stripe's own billing records.

Being precise rather than flattering, again: before 31 July 2026 those database rules were declared but never switched on, so an account deleted by us could leave favourites and expired token rows behind, keyed to an account ID that no longer existed. They held no name or address — a ticker symbol or a random string against a number — but they should not have been there. Every such leftover row is now deleted, and the check runs again each time the application starts.

If you are in Quebec you may also complain to the Commission d'accès à l'information du Québec, and elsewhere in Canada to the Office of the Privacy Commissioner. If you are in the European Economic Area or the United Kingdom, you may complain to your national data protection authority.

09 · Security

How it is protected

Passwords are hashed with bcrypt and checked for length and against a corpus of known-breached passwords when you set them. Sign-in attempts are rate limited.

Two-factor authentication is available on every account and optional on an ordinary one. You switch it on from your profile whenever you want, and switching it off again asks for your password first — so someone who finds your browser already signed in cannot quietly strip the second factor and keep the first. It is mandatory for administrator accounts, which cannot remove it: an admin can promote other admins, disable accounts and read every user row, and that is not the same exposure as an account that reads research and manages its own subscription. Whenever two-factor is on, a code cannot be replayed once used — the same counter governs the website and the mobile application, so a code spent on one is refused on the other.

The site is served only over HTTPS, with HSTS, a strict content security policy, and headers that forbid framing, content-type sniffing and ambient access to camera, microphone, location and payment APIs. Every state-changing form carries a CSRF token.

No system is perfectly secure, and we are not going to claim otherwise. If you find a vulnerability, please write to dev@mohawkresearch.com before disclosing it publicly.

10 · Location

Where the data lives, and when it leaves Canada

The application and its database run in Toronto, Canada. Backups are replicated to Cloudflare R2 object storage.

Several of the processors in section 05 — Stripe, Resend, Google, Cloudflare and Have I Been Pwned — operate globally, so the limited data each one receives may be processed or stored outside Canada, including in the United States and the European Union. Using the service means accepting that those transfers happen. Each provider is bound by its own published privacy terms and its own contractual transfer safeguards.

11 · Contact

Changes and how to reach us

Quorum is published by Mohawk Research. For any question about this policy, or to exercise any right in section 08, write to dev@mohawkresearch.com.

If we change how personal data is handled, we will update this page and move the date at the top. Where a change is significant, we will email account holders rather than rely on you noticing a new date.

Research, not advice. Quorum publishes research about public companies and does not provide investment advice or recommendations.