Privacy

What we store

When you join the waitlist we store: your email address, a timestamp, which button you used, and — if you arrived through a friend’s link — their referral code. To stop bulk signups we also keep a one-way hash of your IP, scrubbed within the hour (on the next signup) — never the raw address. That is the entire waitlist record. No tracking cookies, no analytics identifiers, no data brokers — none of those exist anywhere on this site. If you go on to create an account, the section below sets out what that adds.

If you create an account

Signing in with Apple or Google is optional and separate from the waitlist. If you do it, we store: the identifier your provider gives us, your email address, a handle you choose once, and the bets you post — each with the time you posted it and the kick-off it beat. Your provider also sends a display name and, with Google, a picture; the sign-in service (Supabase) stores those with the login. We do not read or show them anywhere, and erasing the account removes them. We never receive your password, and we never connect to a bookmaker account: every bet on Betclub is one you posted yourself.

A posted bet is public, and the list is longer than people assume: your handle, the match, the selections, the price you took, the stake, the bookmaker you named, the time you posted it, the kick-off it beat, whether you sealed it, its commitment (a hash our server writes with the post), the tag your own tool attached to it if it sent one (the Idempotency-Key of the posting API — a label you chose, published as you wrote it, so do not put anything in it you would not put on the record), and how it settled; after kick-off, the commitment's salt too. The stake is on that list and cannot be taken off it — a record of how someone bets is meaningless without the size, and a page that let you think otherwise would be worse than one that says it plainly. If you would not want the amount read by a stranger, that is a reason not to post the bet, not something we can hide for you. What sealing does is narrower than hiding: a post you seal is public from kick-off, sealed until then, committed from the moment of posting — it keeps its match, selections, price, stake and salt off the public row until the last of its legs kicks off (its kick-off time itself, and that it is sealed, are public from the start), and publishes all of them from then on; the commitment is public from the first second, and the post is locked, graded and permanent exactly as an unsealed one. The rest of it is the point of the product — a record nobody can edit after the result. It also means a post cannot be edited by us, and cannot be taken back down by you; the one thing that can be done to a post afterwards is set out under deleting, below, and so is its limit.

An account also carries three things that describe the account rather than any one bet: how it came to exist (one of a short list — organic, referral, waitlist, creator), whether another account referred you, and any paid access you hold, with the dates it runs between. None of those three is readable by another account. Your handle and your posts are; what you pay for and who invited you are not — and that is enforced in the database itself, not by the app choosing what to render. Concretely: the public record of a post is a fixed list of columns, those two attribution fields are not on the list, and the key that ships in the app is granted no way to read them. Paid access is readable only by the account that holds it.

Three more rows can be attached to an account, and they behave differently from the three above, so they get their own paragraphs. The first is a seat. An organisation that hosts its members’ records on Betclub does not add you to a seat; it offers you one, and you are listed only after you accept. The offer is a row our server writes at the organisation’s request, naming your handle and who offered it; it is readable by you (the app shows you what you have been offered), by the organisation’s owner (who sees your handle on their pending list until you answer) and by our server — by no one else. Accept, and the seat exists; decline, or say nothing, and it never does. A seat is public by design: your handle, your role in the organisation (owner or member) and the organisation itself appear on that organisation’s page and in the embeds it hosts, and anyone with the key from our app can read the same three facts. Your posts do not change — they were public already — but the fact that you sit on that organisation’s list is new public information about you, which is why you accept it rather than find yourself on it. You may leave at any time from the app, and the owner may remove you; either ends the seat and nothing else. Your record does not go with it: the posts stay exactly as they were, under your handle, and nothing of the seat remains on Betclub. What does remain is the offer row, with your answer on it, private as before.

The second is an API key, for posting from your own tools. You create it from inside the app and the secret is shown to you once. What we store of it: the label you typed, the first ten characters of the secret, a one-way hash of the whole secret (we cannot recover the secret from it, and neither can anyone who reads our database), and three timestamps — when it was created, when it was last used to post, and when it was revoked. The key posts as your account and as nothing else. You can list your own keys — the label, the ten characters and the three stamps; the hash is read by nothing but the check that a posted secret matches it — and no other account, and nobody with the key from our app, can list them. You can revoke a key at any time; the posts it made stay, because they are the record. A key ends with the account: erasing the account revokes every key it holds and deletes the label, which was your text.

The second is the Edge list. Edge is the paid tier and it is not for sale yet. Signed in, you can press a button that says “Put my name down for Edge”; pressing it stores one row — your account, which screen the button was on, and when you pressed it — and nothing else. It is not a purchase and not a commitment: no price is held, no card is taken, no payment runs, and if Edge does go on sale we ask before anything is charged. The row is private to your account and to our server; it is not readable by another account, and the only number anyone else can see is how many rows there are. There is no button to take your name off again — nothing in the app may update or delete that row — so if you want it gone, the erasure below is what removes it.

We are naming the mechanism because we got it wrong once. When the paragraph above was first written it was not true: the two attribution fields had been added to a table that granted every column to every reader, so anyone with the key from our own app could have read who invited whom, by handle, across the whole site. It was found and fixed before a single bet had been posted, so nothing was ever exposed — which is the only reason we can write this down instead of writing to you.

If a friend invited you

Signing up through someone’s link records one fact: that they invited you. It is a small record and a different kind of one — a relationship between two people rather than an attribute of one, which makes it personal data belonging to both of you. Neither of you is in the room when it is written, either: your friend is not there when you sign up, and you were not there when they shared the link.

So we do not publish it. Who invited whom is not on your profile, not in the public record of your bets, and not readable by any other account — the field is granted to our own server and to nothing else. What your friend is told is that an invitation qualified. We do not send them your betting activity — and we won’t pretend it is hidden from them either, because your posts are public under your handle and that is the whole product.

If you erase your account we remove the account-level link — the field on your profile that says who invited you. There is a second copy we cannot remove, and you should hear it from us rather than infer it: every bet you post copies that answer onto the row at the moment you post it, and a posted row can never be altered by anybody, which is the entire basis of the product. So the copy sitting on posts you have already made stays there for as long as they do. It is not published, for the reasons in the paragraph above — but it is not deleted either, and calling it deleted would be the easy lie.

Your friend keeps the days it already earned them. We are not going to claw back access somebody has already used — which is also why the legal basis for this one is not consent. See below.

What we do with it

One email when the founding badge lands, awarded in order of signup. Your email is never shared, sold, or used for anything else — there is no advertising on this site to sell it to. Referral counts decide badge priority, and once you have an account a qualifying referral grants paid access under the referral terms.

Two things here are automated, and this page used to tell you neither was. Referral rewards are granted and refused by code: it checks that the bet was posted before kick-off, that it reached a settled result, that the stake met the minimum, and that the two accounts are not one person holding two handles — and it can refuse on those grounds with nobody reading it. We also group accounts by how they arrived (organic, referral, waitlist) to see which routes bring people who go on to actually post. That is profiling in the ordinary sense, and saying otherwise was easier than saying this.

What it isn’t: nothing here scores you as a bettor, prices anything differently for you, or reaches a decision with a legal effect on you. The one automated decision that can cost you something is a refused reward. If that happens, email privacy@betclub.gg and a person will look at it and tell you what the check saw — you should not have to argue with a script about your own account.

Why we’re allowed to

The account, the handle and the bets you post are processed because they are the service you asked for (GDPR Art. 6(1)(b)): a public, timestamped record is what Betclub is, and it cannot be provided without holding it. The waitlist is different, and rests on consent —

Your consent, given when you submit the form (GDPR Art. 6(1)(a)). Giving us your address is entirely voluntary — nothing on this site requires it, and the demo works without it. You can withdraw consent at any time by emailing us, which deletes the record; withdrawing doesn’t affect anything we did with it beforehand. The one-way IP hash is kept on the separate basis of our legitimate interest in stopping bulk signup abuse (Art. 6(1)(f)), which is why it is discarded within the hour.

Consent is the right basis for a mailing list and the wrong one for attribution, so we don’t claim it there. The link between you and whoever invited you is held under Art. 6(1)(b) — we need it to perform the reward terms you both took part in. That is not us reaching for the convenient basis. Consent has to be withdrawable at any moment, and an attribution whose 30 days of Edge have already been spent cannot be unwound; offering you a withdrawal we could not honour would be the dishonest option, not the generous one. The checks that decide whether a referral qualifies run instead on our legitimate interest in not paying rewards to invented accounts (Art. 6(1)(f)). You can object to those under Art. 21, and the honest consequence is that a referral we are not permitted to check is a referral we cannot pay.

How long we keep it

Until the founding badges are awarded, plus up to 30 days after that email goes out — then the waitlist is deleted in full. If the badge is never awarded, the list is deleted and you get one email telling you so. The IP hash is scrubbed within an hour of signup. And if you ask us to delete you sooner, we delete you sooner.

An account is on a different clock, and one part of it has no clock at all: the link to whoever invited you, the record of paid access you have held and your row on the Edge list live as long as the account does; a seat lives until you leave it, the organisation removes or ends it, or the account is erased; an offer of a seat lives as long as the account, with your answer on it; an API key lives until you revoke it or the account is erased, and its row stays as the record of a key that existed, with the label deleted; and your posts outlive the account, because nothing can delete them. Erasing an account is the next section, and the honest limit on it is there too.

Deleting, and what deleting reaches

Email privacy@betclub.gg from the address you signed up with and we delete the waitlist record — usually same day, always within 30 days (GDPR Art. 17). No questions, no retention tricks. If you also have an account, the same email starts that erasure too, and the next three paragraphs set out exactly what it removes and what it cannot.

One honest limit, because it is the whole product: a bet you posted is designed so that nobody — including us — can change or remove it after the result. So here is what erasing an account actually does, item by item, instead of a sentence that sounds complete. We delete the sign-in identity your provider gave us and your email address, so nothing that remains can be used to contact you or to sign in as you. We reset your handle to a meaningless one, so the record stops carrying the name you chose. That last step is worth one more sentence, because we nearly promised it without being able to do it: nothing in this product may edit a profile, so the reset runs through a single narrow database function that exists only for erasure and only our server can call. We would rather hold that one capability on purpose than tell you a thing we could not perform. The same function removes the rows described under accounts: any seat you hold in an organisation, so the reset handle is not left listed as one of its members, and your row on the Edge list — both deleted outright, not hidden. It withdraws any seat you were offered and had not answered, so the reset handle is not left on an owner’s pending list. It revokes every API key you hold and deletes each key’s label. One case it refuses, and tells the person running it why: an account that is the owner of an organisation cannot be erased until that owner seat has been handed to someone else, because an organisation with no owner has nobody who can act for it. None of these is part of the record, so nothing about a posted bet changes when they go.

What we do not do is delete the posts or unpick the row that points at your profile, and we would rather say so than promise it and fail quietly. No key this product holds — not the app’s, not our own server’s — is granted permission to update or delete a posted bet, so there is no way to blank out the poster and leave the bet standing. Deleting the profile instead is refused by the database, because the posts point at it. Reaching past that would mean granting ourselves a permission the schema was written to withhold — the deliberate, visible act our design exists to expose, not a thing a support request can quietly trigger. We would rather tell you the limit than book a 30-day promise we would have to break to keep.

What we can do, and will if you ask: flag the posts. A flagged post drops out of the ledger — the one view every part of Betclub reads — so it stops appearing in your record, in any total, and in anything we publish. The limit worth knowing before you rely on it: the row itself is still in the posts table, and that table is readable, which is exactly what makes the record checkable by someone who does not trust us. Flagging removes a post from what Betclub shows and counts. It does not make the row unreadable to somebody querying the database directly. If that distinction matters to you, it matters before you post rather than after.

The same address covers every other right you have: a copy of what we hold (Art. 15), correcting it (Art. 16), restricting or objecting to what we do with it (Arts. 18 and 21), and getting it in a portable file (Art. 20). On the waitlist the record is one email address and a timestamp, so all of these are quick. On an account, correction runs into the same wall as erasure: a posted bet cannot be rewritten by anyone, so the remedy there is a flag and a new post, never an edit.

Where it’s stored

The waitlist lives in a Cloudflare D1 database. Accounts and posted bets live in Postgres with Supabase, in the EU (Frankfurt).

Our processors are: Cloudflare, Inc. (hosting and the waitlist database) and Supabase (accounts, authentication and the record of posted bets). If you choose to sign in with Apple or Google, that provider authenticates you and tells us who you are; they are independent controllers of what happens on their own side, and their privacy policies govern it. We use no analytics provider, no email marketing platform and no advertising service — there are none on this site.

Cloudflare runs a global network, so we can’t promise your data never leaves the EEA; where it does, the transfer is covered by the European Commission’s standard contractual clauses, which are part of those terms.

Who we are

Betclub is a product in beta built by Darryl and operated by The Quantum Club B.V., registered in the Netherlands (KvK 93498871), Pieter Cornelisz. Hooftstraat 41-2, 1071 BM Amsterdam. That company is the data controller for everything on this page. Betclub is not a bookmaker and takes no bets. We are launching UK-first. Questions: privacy@betclub.gg.

If we get it wrong

Tell us first — we would rather fix it. You also have the right to complain to a data protection authority: in the Netherlands that is the Autoriteit Persoonsgegevens, and if you are in the UK, the Information Commissioner’s Office. You can go to either without asking us first.