In short
Your Minecraft network runs Cortex; the network operator decides what happens to player data and is the controller. On the managed service, Prioxy processes that data on the operator's behalf and never for its own purposes. On a self-hosted install, Prioxy processes nothing. Data lives in the EU. Players prove who they are by joining a Mojang-authenticated server and can then download everything or have it erased, with a signed certificate.
Who we are and what this policy covers
Cortex is operated by Prioxy, a game design and build studio established in the Netherlands (“Prioxy”, “we”, “us”). You can reach us at [email protected].
This policy covers:
- the marketing site at cortex.prioxy.io, including the onboarding wizard and plugin downloads;
- the managed Cortex service (“SaaS”), where each customer network gets a workspace at <slug>.cortex.prioxy.io and the staff portal at /portal;
- the Cortex ingest API that the cortex-paper and cortex-velocity plugins send data to;
- the Cortex Sentinel Discord bot and the two-way staff chat bridge;
- the Cortex Staff mobile app for iOS and Android when it is connected to the SaaS;
- the player verification server at verify.cortex.prioxy.io and the privacy portal it links to.
It does not govern a self-hosted Cortex installation. When a network runs the Docker stack on its own infrastructure, no player or staff data flows to Prioxy: the plugins, the bot, the portal and the mobile app all talk to the operator's own URL. The operator is responsible for its own privacy notice. The only data Prioxy holds about a self-hosted customer is the purchase record kept by our payment provider and any support correspondence.
Where this policy talks about “players” it means anyone who joins a Minecraft server or proxy that runs a Cortex plugin. “Staff” means people with an account in a Cortex workspace (roles helper, moderator, developer, admin, owner). “Operator” means the organisation or person who owns the workspace.
Controller and processor roles
Under the General Data Protection Regulation (GDPR) the roles are split as follows.
- Player data
- The operator is the controller. It decides to install Cortex, which servers report into it, which staff can act on it, and what its rules are. On the SaaS, Prioxy is the processor: we store and process player data only to provide the service and only on the operator's documented instructions, which are the Terms of Service and the workspace configuration. A data processing agreement forming part of the Terms governs this relationship. On a self-hosted installation Prioxy is neither controller nor processor.
- Staff activity inside a workspace
- Staff actions, notes and team chat are processed by Prioxy as processor for the operator, in the same way as player data.
- Workspace owner and billing data
- Prioxy is the controller. We need it to run the service, invoice you and keep the platform secure (Article 6(1)(b) and 6(1)(f) GDPR).
- Staff authentication data
- Prioxy is the controller for the minimum needed to authenticate a person to the platform (username, password hash, TOTP secret, sessions), because we must be able to secure access regardless of the operator's instructions (Article 6(1)(f) GDPR, security of processing).
- Marketing site visitors and support requests
- Prioxy is the controller. Processing is limited to serving the pages, answering you and keeping server logs for security.
The lawful basis for processing player data is determined by the operator. In practice it is normally the operator's legitimate interest in running a safe, fair service and enforcing its own rules (Article 6(1)(f) GDPR), balanced against the players' interests, which is why Cortex is built with retention limits, keyed hashing and a self-service rights flow rather than indefinite raw storage.
What the platform stores about players
Cortex plugins report events from the game server or proxy to the ingest API over HMAC-SHA256-signed requests. Each game server has its own hashed ctx_live_ credential, and an embedded H2 write-through buffer on the server holds events while the API is unreachable, so events are delivered late rather than lost. The following categories are stored in the operator's workspace.
| Category | What it contains | Why it is kept |
|---|---|---|
| Identity | Minecraft username and account UUID, first and last seen timestamps, which server or proxy the player was on. | To attach every other record to the right account. |
| Network fingerprint | IP address at connection time, its autonomous system (ASN) and a hash of the subnet, plus client and hardware identifiers exposed during login. | Anti-evasion: recognising a banned player who returns on a new account. |
| Alt-correlation graph | Links between accounts that the fingerprinting engine considers likely to belong to the same person, with the evidence type for each link. | Anti-evasion and staff review of ban appeals. |
| Chat logs | Public chat, private messages and commands that the operator has configured its plugins to report, with timestamps and server tags. | Moderation, evidence for punishments and appeals. |
| Punishments | Bans, mutes, kicks and warnings: reason, duration, the staff account that issued them, and whether they are active, expired or lifted. | Enforcing the operator's rules and handling appeals. |
| Staff notes | Free-text notes staff attach to a player record. | Context for future moderation decisions. |
| Session telemetry | Join and leave events, session length and server transfers. | Operational dashboards and alt correlation. |
Cortex does not collect payment details, real names, email addresses or physical addresses of players, and it has no way to obtain them from a Minecraft account. Anything a player types into chat is stored as typed, which may include personal data the player chose to share; the operator's rules and the retention limits below are the safeguards for that.
Retention and anonymisation
Retention is fixed per plan and enforced by the platform, not left to the operator to remember.
| Plan | Retention window | Applies to |
|---|---|---|
| Starter | 30 days | Chat logs, session telemetry and raw IP addresses |
| Network Pro | 1 year | Chat logs, session telemetry and raw IP addresses |
| Enterprise / BYO | 10 years | Chat logs, session telemetry and raw IP addresses (operator-controlled on self-hosted installs) |
When a record reaches the end of its window:
- Raw IP addresses are replaced with a keyed-salt hash. The hash lets the anti-evasion engine still recognise a returning connection from the same network, but the address itself can no longer be read out of the database, and the key is held separately from the data.
- Chat logs and session telemetry are deleted.
- Punishment records are kept for the retention window, or for as long as the punishment is still active if that is longer, because the record is what enforces the ban. Once expired or lifted they fall under the normal window.
- Audit ledger entries (see section 5) are kept for the retention window. Because each entry is SHA-256 chained to the previous one, entries are never edited in place; expired entries are removed from the head of the chain.
When a workspace is cancelled it enters a seven-day grace period, is then suspended, and the workspace data is deleted 30 days after suspension unless the operator asks for earlier deletion or an export in the meantime. Backups roll off within a further 30 days. Self-hosted operators control their own retention and backups.
Data about staff and workspace owners
Staff accounts
For every staff account Cortex stores the username, a salted password hash (never the password itself), the role assigned by the operator, and, once two-factor authentication is enrolled, the TOTP secret together with hashed single-use recovery codes. If a staff member links their Discord account for the staff chat bridge, their Discord user id is stored so messages can be attributed. Session records (identifier, issue and expiry time) are kept in Redis so that a JSON Web Token can be revoked before it expires; signing keys are rotated.
The Cortex Staff mobile app keeps its session in the device's secure storage. The Face ID or fingerprint lock is performed entirely by iOS or Android on the device; Cortex never receives biometric data, only the operating system's yes-or-no answer.
Audit ledger
Every staff action — bans, mutes, kicks, note edits, setting changes, role changes, credential rotations — is written to an audit ledger with the acting account, the target, a timestamp and a SHA-256 hash that chains it to the previous entry. This exists so that a compromised or dishonest staff account cannot rewrite history, and so that operators can verify the chain. Ledger entries about a staff member are processed on the operator's behalf; a staff member cannot have them deleted while the workspace's retention window is running, because the integrity of the chain is the point of it.
Workspace owners and billing
The workspace owner additionally provides an email address, the workspace name and slug, and, when billing is enabled, becomes the customer of record with our payment provider. Card details are entered on the payment provider's hosted pages and never reach Prioxy's servers; we store the provider's customer and subscription identifiers, the plan, seat count and invoice history. Only the owner role can see or change billing.
The Discord bridge
When an operator invites the Cortex Sentinel bot and runs /cortex link <code> followed by /cortex setup, the bot creates a “Cortex” category with #staff-alerts, #appeals, #audit-log and #staff-chat and stores the guild id, those channel ids and the webhook URLs it created. Setup is idempotent: running it again does not create duplicates.
The bridge is two-way. Messages sent with /sc in game, in #staff-chat on Discord, in the web TeamChat or in the mobile app are the same conversation and are stored as staff chat in the workspace under the plan's retention window. Alerts and audit events the operator chooses to mirror into Discord are copies: once in Discord they are also subject to Discord's own privacy policy, which Prioxy does not control. The bot only reads the channels it created and slash commands addressed to it.
Cookies, the marketing site and the portal session
The marketing site sets no cookies and runs no analytics, tag managers, pixels or third-party scripts. There is nothing to consent to, so there is no cookie banner. The onboarding wizard keeps its progress in your browser's session storage, which is cleared when you close the tab and is never sent anywhere except as the data you submit at the end.
Fonts are loaded from Google Fonts. Your browser therefore makes a request to Google's servers, which receive your IP address and browser details to serve the font files. Google states that it does not use Fonts requests for profiling; if you prefer to avoid the request, a content blocker will leave the site readable in your system fonts.
The staff portal sets one strictly necessary cookie: the session token that keeps you signed in. It is marked HttpOnly, Secure and SameSite, is scoped to your workspace's subdomain, and is invalidated server-side when you sign out or an admin revokes your sessions. The portal uses no other cookies.
Our edge and origin servers keep standard access logs (IP address, requested URL, user agent, timestamp) for security and abuse prevention. They are retained for up to 30 days. Plugin downloads from /downloads/ are logged in the same way.
Sub-processors and third parties
Prioxy uses a deliberately short list of sub-processors for the SaaS. We will give operators at least 30 days' notice by email before adding one.
| Provider | Purpose | Data involved |
|---|---|---|
| Stripe | Subscription billing, invoices and the hosted checkout and billing portal. | Owner name and email, workspace name, plan and seat count, payment method (held by Stripe only). |
| Cloudflare | Edge network: DNS, TLS termination, DDoS protection and caching in front of the marketing site, the API and workspace subdomains. | All traffic transits Cloudflare's edge; request metadata is processed, content is not retained by Cloudflare beyond cache and security logs. |
| Discord | Hosting the Cortex Sentinel bot's messages and the #staff-chat bridge. | Whatever the operator chooses to mirror: staff chat, alerts, audit events; Discord user ids of linked staff. |
Two further parties are involved but are independent controllers, not our sub-processors:
- Mojang / Microsoft. When a player joins verify.cortex.prioxy.io, the standard Minecraft online-mode handshake takes place with Mojang's session servers. Prioxy receives the authenticated UUID and username from that handshake and nothing else; Mojang processes the login under its own terms.
- Google Fonts, as described in section 7.
Prioxy does not sell personal data, does not share it with advertisers or data brokers, and does not use player or staff data to train models or for any purpose other than providing the service to the operator.
Where data is stored and international transfers
Workspace databases, the Redis session store, backups and the verification server run on infrastructure located in the European Union. Cloudflare's edge is global by nature; a request is answered from the point of presence nearest to the visitor, but data is stored at rest only at the EU origin. Stripe processes billing data in the EU and the United States under the EU-US Data Privacy Framework and standard contractual clauses. Discord processes bridged content in the United States under its own transfer mechanisms.
Operators who need a specific location or who cannot accept any transfer can run the self-hosted stack, in which case no data leaves the infrastructure they choose.
Security
Security controls in the platform include:
- Tenant isolation at a single chokepoint. Every database query in the API passes through one tenant-scoped layer (461 call sites at the time of writing). A request without a resolved tenant is refused rather than falling through to an unscoped query: the design fails closed.
- Signed ingest. Plugins sign every request with HMAC-SHA256 over a timestamp and the body using a per-server key. Keys are stored hashed and can be revoked one server at a time without affecting the rest of the network.
- Authentication. Salted password hashing, TOTP two-factor authentication with hashed recovery codes, JWT sessions with Redis-backed revocation, rotating signing keys, and sensitive routes that require a two-factor-verified session.
- Tamper-evident audit ledger. Staff actions are SHA-256 chained so that deletion or edit of a past entry is detectable.
- Transport. TLS on every public endpoint; HttpOnly, Secure, SameSite session cookies.
- Minimisation by default. Time-boxed retention, keyed hashing of IP addresses after the window, and no collection of data the moderation use case does not need.
No system is perfectly secure. If we become aware of a personal data breach affecting a workspace, we will notify the operator without undue delay and in any case within 72 hours of becoming aware, with the information the operator needs for its own notification obligations. Security reports can be sent to [email protected].
Your rights and the self-service verification flow
Everyone whose data is processed has the rights in Articles 15 to 22 GDPR: access, rectification, erasure, restriction, portability, objection, and the right not to be subject to solely automated decisions with legal or similarly significant effects. You also have the right to lodge a complaint with a supervisory authority; in the Netherlands that is the Autoriteit Persoonsgegevens.
For players: Article 15 and 17 without an email address
A Minecraft account has no email address that Cortex knows about, so a web form claiming to be a given player cannot be trusted. Instead, Cortex proves ownership of the account using Minecraft itself:
- Join verify.cortex.prioxy.io with the Minecraft account in question. The server runs in online mode, so Mojang authenticates the account during the normal login handshake.
- Run /privacy. The server issues a short-lived, single-use link signed for your authenticated UUID.
- Open the link. The privacy portal shows every record Cortex holds for that UUID across all SaaS workspaces that have seen the account.
- Choose Export to download the full data set as JSON (Article 15), or Erase to request deletion (Article 17).
Erasure runs a redaction pipeline: raw and hashed IP addresses and location metadata are wiped, chat messages are replaced with a redaction marker, alt-correlation links that rested solely on IP evidence are removed, and staff notes are cleared of personal detail. The existence and status of an active punishment may be retained by the operator as its overriding legitimate ground under Article 17(1)(c) — the ban itself has to remain enforceable — but stripped of everything except the account identifier, the sanction and its expiry. When the pipeline completes you receive a certificate of erasure: a SHA-256 receipt signed by the platform listing the date, time and truncated UUID of the redacted records.
Requests are fulfilled by the platform immediately. If a request cannot be completed automatically it is escalated to the operator, who as controller has one month to respond, extendable by two months for complex cases; Prioxy assists the operator as its processor.
For staff and owners
Staff can change their username, password, two-factor enrolment and Discord link in the portal. Owners can export or delete their workspace from the settings page. For anything else, or if you no longer have access to your account, email [email protected] from the address on the account. We will answer within one month.
For self-hosted networks
Direct your request to the network operator. The same export and erasure tooling ships with the self-hosted stack, but it runs on the operator's infrastructure and Prioxy has no access to it.
Children
Minecraft is played by children. Cortex does not ask players for their age and does not need to: it processes only what the game already exposes to any server they join, and it does so on behalf of the operator whose server they chose to play on. Operators are responsible for complying with the rules that apply to their audience, including the age of digital consent in their country where they rely on consent. Staff and owner accounts require the holder to be at least 16 years old. If you believe a child's data has been processed in a way that this policy does not allow, contact us and we will help the operator resolve it.
Changes to this policy and how to contact us
We will update this policy when the platform changes in a way that affects what is described here, and we will change the effective date at the top. Material changes to the SaaS — a new sub-processor, a new category of data, a change of storage region — are announced to workspace owners by email at least 30 days in advance. This is version 0.9 and is marked as a draft pending legal review; the wording may change before it is adopted, but the facts about how the system works are current.