Privacy Policy
Who is responsible
- Staff accounts (owners, administrators, moderators): CursedTech (CursedTech), (not specified), is the controller. Privacy contact: (not specified).
- Each network's players: the network owner is the controller and we are the processor. Player requests should go to the server owner first; we help them respond.
- Anti-abuse identifiers: for the identifiers we keep to prevent fraud, cheating and ban evasion (see Retention), CursedTech is the controller. Players can ask us directly for access to or deletion of them at (not specified); we review each request and may keep identifiers needed for that purpose where the law allows.
- Payments: Paddle.com is the merchant of record and an independent controller of the data it collects at checkout and in its customer portal (name, email, address, payment details), under its own privacy notice: https://www.paddle.com/legal/privacy. For subscriptions bought earlier through Tebex, and for free downloads of the CAdmin resource from our Tebex store, Tebex plays the same role.
Data we process
- Staff: Discord ID, username and avatar; verified email address (for service and billing notices); billing contact email; registered passkeys; an audit log of your actions; acceptance records of these texts (with the IP address and browser stored only as keyed hashes).
- Players: FiveM identifiers (license, Steam, Discord and others), encrypted and searchable through keyed hashes; in-game names, sessions, game events, movement telemetry, tickets, sanctions, investigations and staff notes; inventory snapshots, encrypted with a key unique to the network.
- IP addresses: stored encrypted with restricted, logged access; matching uses keyed hashes. Short-lived technical web server logs and the Tebex notifications described below are the only other places they appear.
- Voice and screen evidence: only on plans and networks where it is enabled; it is encrypted and kept according to the plan (see the Evidence Policy).
- Support requests: the messages you send through the support centre in your dashboard or by email, linked to your account and network.
- Discord tickets: the messages posted in the ticket channels that CAdmin creates and manages in a network's Discord server (author, content and attachments), and the ticket transcripts built from them, stored by CAdmin on behalf of the network owner. Where the owner turns on the AI ticket assistant, these messages are also sent to AI model providers (see below) so that it can answer players.
- Handset and Switchboard (when enabled): transcripts of the calls and messages players send to service and scripted contacts (the player's character, the text, the outcome and the time), kept for the network's retention period (30 days by default); photos players take, if the network turns on photo hosting (90 days by default); and, where the owner turns on AI replies, the text of those messages sent to AI model providers (see below). Player-to-player messages and calls are not copied into these transcripts.
- Backups of the service: copies of our databases kept on our own servers, which let us restore for about 25 days; every copy is gone within 35 days. Evidence and voice media are not included.
- Game database (when the network owner turns it on): read access to the owner's game database through a read-only user. The data the owner maps (characters with name, date of birth and job, money, inventory, vehicles and properties) is copied into the network's analytics store every 30 minutes. Every read by staff is written to the audit log (member, time and row count, not the rows). Passwords, hashes, tokens, secrets, API keys and session ids are never read, and licence, Steam, Discord, IP and email columns are not read as values. The credential is encrypted and never shown back.
- Database backups (when the Database Backups feature is enabled and the network owner opts in): encrypted dumps of the owner's game database, which contain the owner's players' data. We never store the owner's database credentials.
- Platform support access records: when our staff access a network for support, we record who, when and what was accessed (reads included). Request-level records are kept for 400 days; session start, end and expiry events are kept in our audit log for as long as the network exists. Both are deleted when the network is purged, and neither is visible to the network owner or included in the owner's data export.
- Payment notifications from Paddle: we never receive card details. Paddle's notifications carry its customer, address and subscription identifiers, prices and statuses. We remove payment method and billing details on receipt, keep Paddle's customer identifier only as a keyed hash (to limit trials and link purchases), and remove the remaining customer identifiers after up to 400 days.
- Notifications from Tebex (legacy subscriptions and free resource downloads) may include the buyer's name, email, IP address and Cfx.re username. We keep them for up to 400 days for auditing and disputes and then remove the personal fields.
What we use it for, and why
- To provide the service you signed up for (moderation, support, auditing, link purchases to your network, service and billing notices): performance of our contract with you.
- To secure the service and prevent fraud and abuse (including one trial per network and per person): our legitimate interests.
- To prevent fraud, cheating and ban evasion across networks: our legitimate interests.
- To keep accounting records: legal obligation.
- Optional notices, such as usage alerts, which you can turn off: our legitimate interests.
For players' data that we process on a network owner's behalf, the owner decides the legal basis. We do not sell personal data or use it for advertising.
Our staff's support access
Authorized CursedTech staff can access a customer network to give support and to operate and secure the service, including data that the network's own staff can see, without asking the owner each time. Access runs in support sessions of 7 days by default (the owner can set 1 to 30 days per network) and the owner can end an active session from the network settings (new access stops at once; a live view already open may keep updating until it disconnects). Every access, reads included, is recorded on our side: request-level records are kept for 400 days (configurable) and session start, end and expiry events for as long as the network exists, and both are deleted when the network is purged. Customers cannot see these records and they are not part of the owner's data export.
Discord bot
The CAdmin bot is added to a Discord server by the network owner or an administrator of that server. Discord sends it the server, channel, role and member identifiers it needs to work and, because the bot uses the message content intent, the content of messages in channels it can see. We store and process message content only from the ticket channels CAdmin creates and manages and, if the owner turns it on, from the channels selected for staff learning (see below). The bot works through buttons, ticket panels and messages it posts on the owner's behalf. Removing the bot from the server stops all of this; ticket data already stored follows the retention rules in this policy.
Custom map tiles
By default the maps load their images from CAdmin itself, so no third party sees anything. A network owner or administrator can set an optional map tile address of their own for the Operations map. If one is set, the browser of every person who opens that map loads the map images directly from that tile host, so the tile host sees the viewer's IP address and which map area is viewed. We do not send it anything else, and we only allow tile hosts on the platform's own list. The network owner chooses the tile host and is responsible for the licence of the imagery. If no address is set, the map uses our own images and makes no external request.
AI assistant
Staff AI assistant (only if the network owner turns it on). Staff can ask an AI assistant about the network's data, on the web or in game. It only sees what that staff member is allowed to see within the network. Before anything is sent to a model, we remove secrets and identifiers such as email addresses, IP addresses and license identifiers, and text written by players is treated as untrusted. This removal is automatic and based on known identifier formats; player names, ticket text and event details can still be sent. The assistant only proposes: every action needs a staff member's confirmation, sensitive ones need a passkey, and no automated decision is made about any player. We keep conversations for the period the network owner sets, clear tool outputs after 7 days and delete proposals after 180 days; a usage record with no content (model, tokens and cost) is kept for 400 days. All AI data is deleted when the network is purged.
When a network owner turns on the AI ticket assistant (a plan feature, when available), the ticket messages it needs are sent to AI model providers reached through the Cloudflare AI Gateway (see below), and it can answer players unattended. Its first message says it is an AI, and players can ask for a person. It learns from staff replies only in channels the owner allowlists. AI requests are routed through Cloudflare AI Gateway with request and response payload logging disabled. Model providers (OpenAI, Anthropic) do not use API data for training and may retain inputs and outputs for up to 30 days for abuse monitoring under their terms. Our triage and review model runs on Cloudflare Workers AI, so Cloudflare is the only provider involved for it. If the network owner turns on staff voice profiles, staff replies (with account identifiers redacted; names written inside a reply may still be included) are used to draft a style guide, which a person reviews before it is activated. If a network uses its own provider key, the network's own agreement with that provider governs that processing. The network owner decides whether to use the assistant, including where players may be minors.
Learning from staff messages
When a network owner enables it, CAdmin processes messages from the Discord channels the owner selects (none by default; ticket channels never), limited to messages written by the network's staff and direct replies to or from staff. The text is redacted, pseudonymized and encrypted before it is stored. Messages judged irrelevant are deleted immediately; the rest is deleted after 90 days, on request, or when the message is deleted in Discord, and everything is purged when the network is offboarded. Processing uses Cloudflare Workers AI with AI Gateway payload logging disabled. The results are suggestions for staff to review and are never used for automated decisions about anyone. The network owner is the controller of this data and we act as its processor; the owner is responsible for informing its community.
Game server database
Off by default and switched on by the network owner. We connect with a read-only user that can only SELECT (one we create, for servers we host). We check the user's grants at connect and daily and stop if it can do more than read.
- What is not read: passwords, hashes, tokens, secrets, API keys and session ids. Licence, Steam, Discord, Xbox, FiveM, hardware, IP and email columns are not read as values; for the one column that links a character to a player we store only a protected index. The owner can exclude more columns or whole tables.
- What is read: roleplay data, such as character names, dates of birth, jobs, money, items, vehicles, plates and properties. Staff the owner permits see it through Player 360, reports and the AI assistant; every read is audited.
- Analytics and investigations: every 30 minutes (adjustable) the mapped data is copied into the network's own analytics store, with the network id on every row, so staff can see money and item history and spot items or money that appeared without a matching event.
- Findings in investigations: staff can attach a flagged change (an item or money that appeared without a matching event) to an investigation. When the owner switches the integration off, or the network's owners change, those attached findings are replaced with "Removed when game database access ended"; the entry and its audit trail stay. An export the owner already downloaded is the owner's own copy and is not affected, and our platform backups age out on their own schedule (see where we keep data).
- AI assistant: staff can ask the AI assistant about this data through fixed read-only tools that run with the asking member's permissions. The model never writes SQL and cannot change or restore anything. For that answer, the rows a tool reads (such as character names, money, items and vehicles) are sent to OpenAI models and, as a fallback, Anthropic, reached through the Cloudflare AI Gateway, with the same automatic removal of known identifier formats. These rows are not kept in the conversation history. Once a day we also build a summary of counts for the network (items, money totals and spread, jobs, vehicle models). It has no per-character data, anything held by fewer than 5 characters appears only as a count of holders, and the assistant can read this summary too.
- Controller: the network owner is the controller of this data and we are the processor; the owner must inform the network's players.
- Switching off: removes the read-only user or credential at once, stops all reads and syncs, and deletes the synced copies and the digest within 24 hours. The mapping of the owner's tables stays until the network is deleted.
Logs, metrics and error tracking
We run logs, metrics and error tracking on our own servers, with no third-party observability service.
- Logs and metrics: technical records of how the service runs (requests, errors, queue and server health). Logs are kept 14 days and metrics 30 days, and are not backed up. Tokens, keys, passwords and players' IP addresses are removed from logs before they leave the application server, although a log line can still contain other technical details.
- Error tracking: errors from our software go to a self-hosted error tracker that only our staff can read.
- Owner dashboards: an owner may get dashboards of their own network's data (for example server player counts over time, which we keep 90 days, tickets and calls). The owner signs in with their CAdmin account and can query only their own network, read-only, through a database user limited to that network and to allowed columns. Owners cannot see logs, metrics or error reports, which can hold other networks' data, and nothing from another network.
Who we share it with
Sub-processors acting for us (and, for player data, for the network owner):
- OVH: hosting of our dedicated server in Canada, where the application and its databases run.
- Cloudflare: CDN, tunnel and access control in front of the service; R2 object storage for stored evidence and media files; Workers AI (our triage and review model runs on Cloudflare GPUs) and AI Gateway for the AI features; and its WARP network, through which our own self-hosted proxy for YouTube lookups sends its outbound traffic.
- AI model providers reached through the Cloudflare AI Gateway: OpenAI models and, as a fallback, Anthropic (Claude Haiku). They receive content only for AI features that a network owner has turned on.
- Mailgun (US region): transactional email (sent from no-reply@notify.cursedtech.net).
- Discord: sign-in, bot and ticket channels.
Independent controllers for payments:
- Paddle (payments, as merchant of record).
- Tebex (legacy payments and delivery of the free resource).
Where it is hosted
Our servers run on a dedicated server hosted by OVH in Canada, where the service's primary data is kept. Evidence, exports, media and ticket transcripts are stored on our servers or, where object storage is configured, in Cloudflare R2 in the United States (transcripts in our database); backups of our databases stay on our servers for at most 35 days. Transactional email is sent through Mailgun's US region. Cloudflare's global network sits in front of the service and carries AI requests through its AI Gateway, and the AI providers (OpenAI, Anthropic) process AI requests in the countries where they operate. We operate from (not specified) and serve customers worldwide, so data is transferred between these countries. Our providers offer safeguards for these transfers, such as standard contractual clauses in their data processing terms; contact us at (not specified) for details.
Retention
- Game events and movement: according to your plan (up to 30/90/180 days of events, set per event type with 30 days by default; 1/7/up to 30 days of movement).
- Voice evidence: 30 days (Operations) or 90 days (Network). Lowering the plan shortens existing evidence to the new limit.
- Discord ticket transcripts: the plan's evidence retention period (Starter 7 days, Operations 30 days, Network 90 days).
- Staff learning messages (when enabled): irrelevant messages deleted immediately; the rest after 90 days, on request, or when deleted in Discord; all purged at offboarding.
- Our backups of the service's databases: restorable for about 25 days and gone within 35 days, so deleted data and a purged network's data leave the backups within 35 days. Evidence and voice media are not in them.
- Game database copies used for analytics: kept up to 90 days by default (the owner can set 30 to 365), deleted within 24 hours when the owner switches the integration off or the network's owners change. Lowering the period stops using older copies at once and deletes them shortly after; under storage pressure we may delete copies earlier, never keep them longer. The daily summary of counts goes with them. The mapping of the owner's tables stays until the network is deleted.
- Logs 14 days, metrics 30 days, and the server availability history shown to owners 90 days.
- Database backups (when the Database Backups feature is enabled): per plan tier and never older than 35 days; deleted when the network is purged by destroying the network's key and deleting the objects.
- To prevent fraud, cheating and ban evasion across networks, we keep technical identifiers (such as IP addresses and game account identifiers) for as long as needed for that purpose, including after a network leaves CAdmin.
- When a plan ends: 30 days read-only with export, then 7 days' notice, then permanent deletion of the network's data, including cryptographic erasure of its keys. We then keep a record that the deletion happened and minimal records of our platform actions that concerned the network, without their content; the anti-abuse identifiers above are kept as described there, and billing records follow the 6-year rule.
- Support access records: request-level records 400 days (configurable); session events for the network's lifetime; both deleted when the network is purged.
- Billing records without personal data: 6 years.
- Customer identifiers in Paddle and Tebex notifications: up to 400 days.
Security
Sensitive data is encrypted, identifiers are searchable only through keyed hashes, sensitive staff actions require a passkey, and sensitive administrative actions are written to an audit log. Backups of our databases are kept on our own servers with restricted access.
Your rights
Staff can delete their own account (Security → Delete my account), which anonymizes it. You can ask us for access, correction, deletion, restriction, portability or objection at (not specified), and you may complain to your data protection authority. Network owners can export their network's data. Players should contact the server owner first; we will help them respond.