Privacy Policy

Last updated: 31 August 2026. This policy explains how Sculk AntiCheathandles personal information on the Sculk website and store, consistent with the Australian Privacy Principles (APPs). The software’s own data handling is covered in the Licence Agreement (EULA) and summarised below.

What we collect on the website

• Account & sign-in data — your email address, and the details of the sign-in method you choose. You can sign in with an email magic link, with an email and password (if you set one, only a salted hash is stored — never the password itself), or by linking a Discord, Cfx.re or Googleaccount, in which case we store that provider’s account identifier and the email it returns. If you enable two-factor authentication, we store your authenticator secret encrypted and your backup codes as hashes.
• Order data — what you bought, when, the price, and the server address if you choose to bind one to a licence. Card details are handled entirely by Stripe and never reach our servers.
• Licence data — issued licence keys are stored as cryptographic hashes; we can verify a key but not read it back.
• Contact submissions — name, email, and message when you use the contact form.
• Security logs — IP address, timestamps and basic request metadata are processed for session security and abuse prevention, and retained only as long as needed for that purpose.

The processors we use

We keep our processor list short and name it plainly:

• Supabase — authentication and account/order database.
• Stripe — payment processing (card data is handled by Stripe under its own PCI-DSS compliance).
• Resend — transactional email (magic links, receipts, security notices).
• Trustpilot— review invitations. Your email address is passed to Trustpilot’s Automatic Feedback Service when an order confirmation is sent, so that it can invite you to review us.

Some of these providers process and store data on servers outside Australia. Where that happens, the information is handled under each provider’s security and privacy commitments. We use these providers only to run the service — we do not sell or rent your personal information, and there are no third-party advertising trackers on this site.

Cookies

The site uses only the cookies required for login sessions and basic security (for example, the signed session cookie). There is no analytics or advertising cookie; if that ever changes, this page and a consent mechanism will change with it.

The software and your players

Sculk runs on your server and analyses gameplay traffic — for FiveM, server-side events and entity/player-state signals; for Minecraft, movement and interaction packets — in memory to detect cheating. Detection and moderation records are not kept only on your server: the software sends them to us so they appear in your dashboard and can be reviewed by your staff. This is personal information about your players, so we set out plainly what we receive:

• Moderation events— the player’s in-game name and identifier, the detection, the reason, and the acting staff member.
• Bans— the player’s in-game name, identifiers, hardware tokens and IP address.
• Screen captures— when a server’s staff request one, an image of the player’s game view, stored against their name and identifier.
• Licence and server metadata — licence key hash, platform and version.

Bans can be shared between our customers, and the server operator decides. Config.GlobalBanSharing is on out of the box: while it is, a ban your server issues is contributed to a cross-server database — identifiers, hardware tokens, a device fingerprint, the reason and the supporting evidence. Set it to falseand your bans stay on your server and are never published. Contributing your players’ identifiers to a database other customers can act on is a choice, so it is a setting, and it is the one to change if you do not want to make it.

Two further settings control the other direction, what arrives from other servers. Config.GlobalBanApply is on by default and decides whether your server receives the shared feed at all; set it to false and the feed is ignored entirely. Config.GlobalBanAutoEnforce decides what an arriving ban actually does, and it is off by default. With it off, a ban from another server is stored and filed as a review signal — it names the player, the detection and the evidence, and it refuses nobody. Your staff decide whether anything happens.

Turning auto-enforcement on does not make a foreign ban permanent or unconditional. It still has to clear bars your own server sets: the detection it names must be one your build classes as deterministic, at least two independent servers must have reported the same player before anything is enforced, and an adopted ban lasts at most 30 days and then lapses on its own. Anything below that bar stays a review signal. This is deliberate — a player dropped for somebody else’s detection has nobody on your server who can answer for it, so a wrong answer has to be able to expire.

Shared ban records are not deleted on a timer. The way one is withdrawn is by lifting the ban on the server that issued it: the withdrawal is pushed back to the shared database ahead of everything else in the queue, and servers that took the record drop it on their next sync.

How long the rest is kept: screen captures are deleted after 30 days. Moderation events are capped at 5,000 per licence and bans at 50,000 per licence, with the oldest removed first — these are storage caps rather than time limits, so a quiet server’s records may persist indefinitely.

The server operator is the data controller for their players and we process this information on their behalf. If you are a player on a server running Sculk and you want to know what is held about you, or want it corrected or deleted, contact the operator of that server first — and you may also reach us via the support form. If you are a server operator, you are responsible for telling your players that an anticheat is in use and what it records, where your jurisdiction requires it.

The Discord bot

Connecting the Sculk Discord bot to your guild creates three more kinds of record. Two of them are about your players and members rather than about you, and earlier versions of this policy did not describe them.

• Identity links — a player can run /link in game and then complete a Discord sign-in, which proves that one person holds both that Discord account and that machine. What we store is the Discord account id joined to the identifiers your server observed for them: CFX hardware tokens, the device fingerprint, the Rockstar license and license2, Steam, and the live and xbl identifiers. These are stored as the values themselves, not as hashes, because a link is only useful if it can be matched against a live connection. Weaker links are recorded too, each marked with how it was arrived at: a moderator asserting one by hand, two identifiers turning up on the same connection, and the in-game discord: identifier, which is self-reported and is never treated as proof of anything.
• Join-gate verdicts — when someone presses Verify to get into your Discord, the bot records what it decided: their Discord account id, the reason codes behind the verdict, references to the ban or the identity link it relied on, and the policy settings that were in force at the time. It records this for refusals and for admissions alike, so that a refusal can be appealed and overruled. The gate collects no device signal at all — no browser or hardware fingerprint, and no IP address.
• Staff action log — every ban, unban or kick your staff run through the bot is written to an audit log before it is carried out, and the action does not run if the log write fails. The entry holds the Discord account id and the email address of the staff member who ran it, both in the clear, plus the command, the reason they typed, and the outcome. The player being acted on is recorded as a keyed hash rather than a readable identifier.

Identity links are not shared between customers. Every link is held against one licence, and there is no cross-customer view of them and no global index that would make one cheap. A player who links on your server has to link again on the next one. That costs us a feature and we are keeping it that way on purpose: a player running /link is consenting to your staff knowing that their Discord account maps to their machine, and turning that into a Discord-to-hardware database queryable by every other Sculk customer is a different thing that nobody asked them about. Bans are shared; identities are not, and the two should not be read as the same feature.

How long these are kept. An identity link expires a set time after it was last seen — 365 days for a link proven by an in-game and Discord session, 180 for one a moderator asserted, 30 for two identifiers merely co-occurring, and 14 for a self-reported hint — and rows are deleted 90 days after that, so a proven link can sit with us for up to 455 days after the last time we saw it. Seeing the same link again extends the clock, so an account and a machine in continuous use do not lapse. Revoking a link takes effect immediately and does not wait for the clock. Join-gate verdicts are kept for the number of days you set: 30 by default, never fewer than 7 or more than 180, and an admission is dropped after 7 days whatever you set. The staff action log is append-only and is kept for at least 400 days — see below, because that has a consequence we would rather state than have you discover.

Retention and your rights

Account and order records are kept while your account exists and for as long as tax and accounting law requires afterwards. Under the APPs you can request access to, correction of, or deletion of your personal information, and you can delete your account, via the support form. We honour deletion requests except where we must retain records by law — and in one place, where we have built something we cannot undo.

The bot’s staff action log cannot be erased.It is append-only, enforced by a database trigger that refuses to delete any entry younger than 400 days and that binds us as much as it binds the software. There is no supported way — not through the application, not by hand — for us to remove one person’s entries from it inside that window, so if you ask us to erase them we will tell you no rather than tell you it is done. That is a constraint we chose, because an audit log a staff member can have their own actions removed from settles nothing; it is not a legal retention exemption and we are not going to dress it up as one. What is in there about a staff member is their Discord id and email address; what is in there about a player is a keyed hash, which someone who already holds the identifier can match and nobody can read. After 400 days an entry becomes deletable, but nothing deletes it on a schedule: clearing old entries is a statement we run by hand, so treat 400 days as the earliest they can go rather than the day they do. Everything else we hold — account and order records, identity links, join-gate verdicts, moderation events, bans and screen captures — we can delete on request, with the caveat above about bans already published to other servers.

If you are not satisfied with how we handle a privacy request, you may contact us to escalate it, and you may complain to the Office of the Australian Information Commissioner (OAIC).

Questions about this policy? Reach us via the support form.