1. Who this is about

Two different groups of people appear in this policy:

• Developers and staff — the people with an account here, who run the protection for a game.
• Players — the people playing a game that Sovereign protects. We process a small, pseudonymous record about them on behalf of that game's developer. The developer decides what the game checks and who gets banned; we provide the software and the hosting.

Sovereign is reachable at q1d3 on Discord for anything on this page.

2. What we hold about developers and staff

On this website, for your account here:

• Your username, an optional email address, and your password stored only as an Argon2 hash — we never hold the password itself.
• Your profile picture, if you upload one.
• One row per signed-in session: when it started, when it was last used, the IP address it came from and your browser's User-Agent string, so you can recognise and end a session that isn't yours. You can end all of them at once from your profile.
• Failed sign-in attempts against an IP address for a few minutes, to rate-limit guessing.
• Messages you send through live chat, so we can answer them.
• A session cookie and short-lived one-time form tokens.

In the protection portal, for the games you run:

• Sign-in activity: when you signed in, the network it came from (an IPv4 /24 or IPv6 /48 block, not the exact address) and a short "browser on system" label — the raw User-Agent is not stored there. This list exists so you can spot a sign-in that wasn't you, and it cannot be cleared from the dashboard.
• An audit record of what you do: policy changes, bans and unbans, revokes, SDK uploads — with your account name and the reason you gave.
• Messages in your portal inbox.

3. What the protection holds about players

The game never sends us a player's name, email address, friends, voice, chat or position in the world. What a verified session produces is:

• A pseudonymous account reference. The Meta account ID is put through a keyed one-way function and shortened. The result identifies the same player again but cannot be turned back into their Meta ID, and is different on every deployment because the key is.
• A pseudonymous headset reference, made the same way from the device identifier in Meta's attestation. This is what makes a ban stick to a headset when a developer chooses that.
• A pseudonymous network reference, made the same way from the IP address. The raw address is used to answer the request and to apply rate limits, and is not written into the records or the alerts.
• What Meta verified: that the app is a store-recognised install, its package and Android version code, the device's integrity verdict, and when the proof was issued and expires.
• Check results: which runtime checks were asked for, what the client answered, file digests for the APK, the managed assemblies and the native library, the risk signals raised and the score and tier they produced.
• Session facts: when a session opened, its heartbeats, the build it ran, when it closed or was ended, and why.
• Moderation facts: bans with their reason, length and what they cover, and a flag when a new account appears on a headset a banned account used.
• A PlayFab ID, only if the developer has turned PlayFab on for that game.

We do not profile players, sell anything, serve ads, or run analytics or tracking scripts of any kind.

4. Why we hold it

To tell a genuine copy of a game from a modified one, to tell one player from another without knowing who they are, to catch tampering while a game runs, and to let a developer keep a cheater out. That's the whole purpose, and the data collected is the minimum that makes it work.

Where the law needs a basis named: for players it is the legitimate interest of the game's developer in keeping their game fair and secure, and for developers' own accounts it is the contract between us.

5. Who else sees it

• Meta. The attestation token from the headset is sent to Meta's platform API to be verified, with the challenge it answers. Meta's own policies apply to that exchange. Nothing else about the session is sent to Meta.
• Cloudflare. Traffic to this site and to the protected backends passes through Cloudflare, which sees connection data including the IP address.
• Photon and PlayFab. Only if the game's developer configures them. PlayFab then receives the ban the developer applies; Photon receives the verification result for joining a room.
• Alert destinations. If a developer points detections at a Discord channel or another webhook, the records routed there contain the pseudonymous references above and the signals, never raw IDs or addresses.
• Nobody else. We don't sell, rent or share any of it, and there are no advertising or analytics third parties.

6. Where it lives and how long

Everything runs on hardware we look after ourselves, not a managed cloud account, and the databases are copied by a nightly backup so a failure doesn't lose a game's history.

• Detections and audit records: kept for the retention window the operator sets — 30 days by default — then deleted.
• Sessions: kept while they are live, then dropped after they close or go stale.
• Player records: kept while the game uses them, so a ban can still find the right player. Deleted on request or when the game's data is removed.
• Bans: until they expire or are lifted.
• Sign-in activity for accounts: kept so you can review it.
• Backups: kept for a rolling window and then overwritten, so a deletion reaches the backups within that window too.

7. Your choices and rights

Developers and staff: ask us at q1d3 on Discord for a copy of what we hold about you, a correction, or deletion of your account and its data. You can end your own sessions and change your own details from your profile at any time.

Players: start with the developer of the game you played — they control the data and can look you up and delete you. If you'd rather come to us, write to q1d3 on Discord with the game and roughly when you played. Because the records are pseudonymous we may not be able to find you from your Meta name alone, and we will not create new personal data in order to try.

Depending on where you live you may have rights to access, correction, deletion, restriction, objection or portability. We honour those within a month, and we will tell you if an exception applies — for example, we will not delete a live ban on request from the banned account, because that would defeat the purpose it was created for.

8. Children

Games on Quest are played by younger people. The protection does not ask for or receive a date of birth, a name, an email address or any other detail about a player, and we do not knowingly collect personal information from children. If you believe a child's personal data has reached us anyway, write to q1d3 on Discord and we will delete it.

9. How it's kept safe

• Passwords are hashed with Argon2; tokens are stored hashed, never in the clear.
• Every page and API call is served over HTTPS.
• Player identifiers are pseudonymised with a key that stays on the server and is not in any export, alert or dashboard.
• Each game's data is isolated from every other game's, and a game backend cannot read another's.
• SDK packages are signed with a publisher key that is kept off the portal, so a compromised portal still can't push code into a developer's Unity project.
• Sign-in attempts are rate-limited, and sign-ins from a new network are recorded where you can see them.

No system is perfect. If something does go wrong that affects your data, we'll tell you, and the affected developers, as soon as we know what happened.

10. Cookies

A session cookie to keep you signed in, and a short-lived form token to stop forged requests. That's it — no advertising, analytics or third-party cookies anywhere on this site.

11. Changes

If this policy changes, the date at the top changes with it, and anything material is announced on the site. Carrying on using Sovereign after a change means you accept the new version.

Questions, requests or complaints: q1d3 on Discord.