Salt & Steel: Security and Integrity

Document type: Technical Architecture — Canonical
Status: Canonical
Last updated: 2026-04
See also: Server Architecture | Networking Model | Economy

Overview

Salt & Steel's security model is built on a single architectural principle that provides stronger anti-cheat guarantees than any external cheat-detection system: the server computes everything that matters. A client that lies is ignored. A client that cheats receives the same experience as a client that plays correctly, because the client's beliefs about game state are not used to advance the simulation.

This is not a novel insight — Path of Exile demonstrated this model's effectiveness over a decade of operation. But Salt & Steel has additional security surfaces that PoE does not: a naval combat layer with ship positioning, cannon accuracy, and crew management; a dual-scale simulation that must maintain integrity at both scales simultaneously; a persistent sea economy without the fresh-start of league resets; and the GURPS 3d6 bell curve whose statistical validity is a core gameplay promise.

This document covers the full security and integrity architecture across all systems: anti-cheat by design, economy monitoring, trade integrity, account security, and operational security.

Anti-Cheat by Design: Server Authority

The Fundamental Guarantee

The client is a rendering terminal. It sends input; it receives state. It does not compute outcomes, generate loot, or resolve combat. Any client that attempts to manipulate game state by sending false inputs receives either a corrected server state (the cheater's manipulated input was ignored) or a protocol violation detection (the manipulated packet was malformed and detected).

What the client cannot do:

Modify its reported HP or FP — these values are server-owned and re-transmitted each tick
Skip the GURPS 3d6 roll — rolls are generated server-side using a CSPRNG seeded with server entropy
Force a critical hit — the roll result is server-generated; the client cannot inject a fake critical hit packet
Extend the active defense window — defense window validation uses server-received timestamp with RTT compensation; a client that artificially inflates its timestamp is detectable
Reveal entity positions outside AoI — the server enforces AoI at the transmission level; entities outside AoI are never transmitted to the client
Generate loot items — all item creation occurs server-side using the server's RNG
Modify item modifiers — item records are stored in the Account Authority; the client holds display data, not authoritative item state
Instantly reload cannons — cannon reload state is server-owned; a broadside fire command received before the reload timer expires is rejected
Teleport ships — position validation rejects ship positions that require movement beyond the maximum physics-possible distance from the last confirmed position

Position Validation

Character position (land instances):

The server tracks each character's confirmed position and maximum movement speed
Each position update from the client is validated: distance_from_confirmed ≤ (max_speed × time_since_last_confirmation) × 1.2 (20% tolerance for legitimate network timing variance)
Positions failing validation are rejected; the server sends the authoritative position correction to the client

Ship position (sea instances):

Ships have physics-constrained movement: maximum speed, maximum turn rate, acceleration curve
Position updates are validated against the physics model: a ship cannot instantaneously change from 5 knots northward to 12 knots eastward
Wind state is server-owned; a ship cannot report traveling faster than the current wind-limited maximum
Validation tolerance: 10% of maximum physics-possible displacement (accounts for numerical integration variance)

Underwater position:

Diving depth is validated against the bathymetry model for the current sea instance (sea floor depth map)
A character cannot report being 200m underwater if the sea floor is 50m down

GURPS 3d6 Roll Integrity

The GURPS dice system is the mathematical heart of Salt & Steel. Its bell-curve probability distribution is a design promise — players build characters with specific probability expectations. Any manipulation of this curve (always rolling low for attacks, always rolling high for defenses) would be both a cheating vector and a design violation.

Implementation:

The server uses a cryptographically secure pseudo-random number generator (CSPRNG): ChaCha20 in counter mode seeded with /dev/urandom entropy at server startup
Each 3d6 roll consumes three 8-bit samples from the CSPRNG output, each reduced modulo 6 and incremented (producing uniform 1-6 distributions)
The three results are summed — producing the characteristic 3-18 bell curve
The roll result, the skill target, and the outcome (hit/miss/critical) are all transmitted to the client in the combat resolution packet
The client has no ability to pre-compute, modify, or replay rolls — each roll is generated for a specific combat interaction at the moment of resolution

Roll auditing: All combat rolls for a session are logged server-side to an immutable audit log with millisecond timestamps. Statistical analysis of the audit log can detect anomalous roll distributions — if an account consistently rolls within 1-2 of skill target on attack rolls, this is a statistically implausible pattern that may indicate roll manipulation (which should be impossible by design, but statistical monitoring provides a defense-in-depth layer).

Loot Generation Integrity

All loot is generated server-side:

Item base type selection: server RNG applied to area's drop table
Item rarity determination: server RNG vs. rarity thresholds
Modifier selection: server RNG walking the affix pool for the item level and base type
Modifier roll value: server RNG within the affix's minimum-maximum range
Currency drop type and quantity: server RNG applied to currency drop table

The client never sees the RNG state. It receives fully-formed item descriptions from the server, not seeds that it resolves locally. A client that attempts to display items that weren't transmitted by the server (packet injection) will either be rejected at the protocol layer (sequence number mismatch) or will display items that exist only on the client — they will not exist in the Account Authority and cannot be traded or persisted.

Economy Monitoring and RMT Detection

Salt & Steel's economy — particularly the persistent economy that does not reset between Voyages — is a high-value target for real-money trading (RMT) operations. RMT harms the player community by inflating prices beyond what legitimate players can afford and by devaluing the effort of honest play. The monitoring architecture is designed to detect RMT at scale and respond with bans that disrupt RMT operations economically.

Transaction Monitoring

Every trade, vendor sale, and currency exchange is logged to the economy telemetry pipeline (Kafka topic, immutable, retained for 90 days). The telemetry pipeline feeds real-time analysis systems:

Velocity anomaly detection:

Accounts that transfer currency or high-value items at rates inconsistent with their play history are flagged
A new account transferring 50,000 Doubloons to an established account within 2 hours of creation is a strong RMT indicator
Accounts whose currency acquisition rate is in the top 0.01% of the player population are automatically reviewed

Network analysis:

Currency and item flow is modeled as a directed graph: accounts are nodes, transactions are edges with value weights
RMT operations often create hub-and-spoke patterns: many source accounts funneling currency to a small number of distribution accounts, which then transfer to buyer accounts
Graph centrality analysis identifies distribution hubs automatically
Accounts with more than 50 unique trade partners in 24 hours are flagged for review (legitimate trading is high-volume but typically involves a narrower range of counterparties)

Price anomaly detection:

Items traded at prices dramatically below market value (under 10% of median market price for the item type) are flagged
Below-market trades are a common RMT pattern: the buyer transfers value through the RMT website, then receives goods through an in-game trade at a nominal price

Cross-account item movement:

Items that move through more than 3 accounts within 48 hours are flagged (item laundering pattern)
Items moved from accounts that are subsequently banned are automatically flagged for review on the recipient accounts

Response to RMT Detections

Detections feed a tiered response system:

Detection Confidence	Automatic Action	Human Review
Low (1-2 signals)	Flag for monitoring, no action	Queued for weekly batch review
Medium (3-4 signals)	Temporary trade restriction (48h), alert player	Reviewed within 72 hours
High (5+ signals or definitive pattern)	Account suspension, currency/item hold	Emergency review within 24 hours
Definitive (ban wave criteria)	Permanent ban, currency/items removed from economy	Post-hoc audit for false positives

Ban waves: Rather than banning RMT accounts individually as they are detected, Salt & Steel follows PoE's approach of accumulating confirmed detections and banning in waves at intervals of 4-8 weeks. This strategy:

Prevents RMT operators from learning their detection methods by banning incrementally (they cannot see which specific behavior triggered detection)
Maximizes disruption to RMT operations by eliminating multiple accounts simultaneously
Preserves player experience during active Voyage periods (large ban waves near Voyage start draw community attention to the problem and demonstrate enforcement)

Economy correction: Currency and items removed from banned RMT accounts are not redistributed to other players — they are destroyed. Injection of "found" goods creates its own economy distortion. The destruction of ill-gotten goods slightly reduces currency supply, which is a mild deflationary correction that benefits legitimate players.

Crew Salary as Anti-Accumulation Sink

The crew salary system is not only a gameplay mechanic — it is an economy security feature. The ongoing operational cost of a large fleet creates a natural ceiling on currency accumulation by any single account. An account that acquires currency at a superhuman rate (consistent with automated farming tools) will still incur crew salary costs proportional to their fleet; accounts that cannot sustain reasonable salary-to-income ratios are flagged.

Trade Fraud Prevention

Trade Window Integrity

The trade window is server-validated at both confirmation steps:

Offer submission: When a player submits their side of a trade, the server validates that all offered items are in their inventory and not in an "in-use" state (equipped and locked, already in another pending trade)
Trade confirmation: Both players must confirm within a 30-second window. If either player's inventory changes between offer and confirmation (an item disappears, currency is spent), the trade is automatically cancelled and both players are notified

Anti-bait-and-switch: The trade window locks the displayed items and currencies for both parties from the moment of first confirmation. Any attempt to modify the offered contents after first confirmation cancels the trade immediately. The client cannot display different items from those validated by the server.

Trade Window Display Consistency

A known social engineering attack in ARPGs: displaying an item that looks similar to a valuable item but is actually a different item (e.g., a normal ring that superficially resembles a rare ring with the same name). Salt & Steel mitigates this:

Item tooltips in the trade window are rendered from the server-transmitted item record, not from the client's display cache
Rare items (Rare rarity tier and above) display their full modifier list in the trade window, not just their name
Items with unusual properties (cursed, blessed, corrupted equivalents) display a prominent visual indicator that cannot be hidden by item naming

Market Listing Integrity

Items listed in the port marketplace are validated at listing time:

The item must exist in the player's inventory or cargo hold
The item is "soft-reserved" (cannot be traded or used) while listed
If the player disconnects without cancelling a listing, the listing remains active but the item remains reserved until either the listing is cancelled (on reconnect) or a buyer completes the purchase
Players cannot list items they do not own — the server validates ownership against the Account Authority before accepting a listing

Ship Combat Validation

Naval combat has unique validation requirements because the ship physics model creates a large state space that is harder to validate than simple character positions.

Cannon Fire Validation

When a client sends a broadside fire command:

Server checks cannon reload state: all cannons in the broadside must be at ≥ 100% reload completion
Server checks crew assignment: sufficient crew must be assigned to cannon operation (crew below minimum operational count disables that broadside)
Server checks target AoI: the target ship must be within the firing ship's area of interest (can't fire at ships you can't see through fog)
Server computes cannon accuracy using the crew's Gunnery skill + relevant modifiers — the fire command is accepted but the accuracy of each cannon is server-computed
Server generates projectile trajectories server-side; clients receive projectile spawn packets, not trajectory computations

A client cannot fire cannons before reload is complete, cannot fire at targets outside AoI, and cannot control cannon accuracy (accuracy is a function of server-computed crew skill rolls).

Ship Capture Validation

Ship capture (taking over a defeated enemy ship) is a high-value event. Validation:

Target ship must be genuinely defeatable: hull integrity below 25% OR crew count at 0 OR captain killed
Attacking ship must be within boarding range (100m) at the moment of capture attempt
An active boarding action must have been resolved in the attacking ship's favor (prevents "capture without boarding" exploits)
Ship capture creates a new ship record in the Account Authority for the capturing player, with the captured ship's class and current damage state — it does not grant a perfect copy of the enemy ship

Fleet Command Validation

Fleet commands (orders to NPC-captained player ships) are validated:

Player must own the commanded ship (fleet ownership validated against Account Authority)
Ships being commanded must be in the same sea instance as the commanding player
NPC captain behavior cannot be directly overridden to produce impossible actions (NPC captains obey physics constraints identical to player-commanded ships)

Account Security

Authentication

OAuth 2.1 with PKCE for all authentication flows:

Access tokens: 1-hour lifetime, signed with server-side HMAC-SHA256
Refresh tokens: 30-day lifetime, single-use (each refresh issues a new token pair and invalidates the old refresh token)
Refresh token binding: tied to the IP subnet and device fingerprint of the issuing session. Cross-subnet refresh requires re-authentication.

Two-Factor Authentication (2FA):

TOTP (Time-based One-Time Password, RFC 6238) using any standard authenticator app
2FA is optional but strongly encouraged at account creation via a visible prompt
2FA is required for: any trade above 10,000 Doubloons value, any change to account email or password, any access from a new device type
Backup codes provided at 2FA enrollment (8 single-use codes, printable)
2FA cannot be disabled without re-authentication to the registered email address

Email verification: All accounts require verified email. Unverified accounts cannot trade, access chat, or participate in PvP.

Session Management

One active game session per account. A second login from a new location displays an alert to the account holder and requires CAPTCHA or 2FA to proceed, disconnecting the original session.
Sessions are tracked by (token, IP subnet, device fingerprint) tuples. A session token used from a different IP subnet requires re-authentication (prevents token theft from local network interception).
Session tokens are never transmitted in plaintext — all connections use TLS 1.3 minimum. TLS 1.2 fallback is permitted for console platforms with constrained TLS stacks.

Account Protection Features

Trade hold: Newly created characters cannot participate in player-to-player direct trades for 72 hours. This prevents immediately-created accounts from being used as RMT mules.
Login anomaly detection: Logins from new geographic regions trigger an email notification. Logins from IP addresses in the known-VPN/proxy database trigger additional verification.
Account lock: Three failed password attempts in 10 minutes locks the account for 30 minutes. Ten failed attempts in 24 hours locks the account and triggers an email notification to the registered address.
Item protection: High-value items (above a configurable threshold) display a confirmation prompt before trade or deletion. Bulk item actions (deleting full cargo tabs) require a secondary confirmation.
Legacy Character Protection: Account Record elements (ship names, reputation history, Voyage achievements) cannot be deleted — they are append-only. A player cannot be deceived into destroying their Account Record.

Password Security

Minimum 12 characters required; no maximum (up to 1024 characters supported)
Passwords checked against the HaveIBeenPwned database of known compromised passwords at creation and change. Compromised passwords are rejected with a plain-language explanation.
Passwords stored as Argon2id hashes with per-account salt. Server never stores plaintext passwords or reversible representations.
Password change requires the current password OR 2FA + email verification. Prevents attackers with a stolen session token from changing the password.

DDoS Mitigation and Network Security

Architecture-Level DDoS Resistance

The gateway tier provides the primary DDoS defense:

Upstream scrubbing: Traffic is routed through a DDoS mitigation provider (Cloudflare or equivalent) before reaching the game network. Volumetric attacks (UDP floods, SYN floods, ICMP floods) are absorbed at the scrubbing layer before reaching game servers.
IP reputation filtering: Known DDoS botnet source IPs are blocked at the scrubbing layer using regularly updated threat intelligence feeds.
Rate limiting at gateway: Per-IP connection rate limiting prevents connection exhaustion. Login endpoints are rate-limited at 5 attempts per 10 seconds per source IP.
Game server isolation: Game simulation servers are on a private network segment not directly reachable from the internet. All traffic routes through the gateway tier. A DDoS targeting a specific simulation server IP is ineffective because the IP is not publicly accessible.

Session-layer DDoS protection: Even if the gateway is degraded by a DDoS attack, already-connected player sessions (communicating on established TCP connections with valid session tokens) are protected. The gateway processes authenticated sessions on a separate higher-priority queue from new connection attempts. This ensures existing players experience minimal disruption even if the attack degrades new player login capacity.

Protocol Security

All game protocol packets require a valid session token. Packets without valid tokens are dropped at the gateway, never reaching simulation servers.
Packets include a sequence number. Out-of-sequence packets are dropped (prevents replay attacks using captured valid packets).
The binary protocol format is not publicly documented. Reverse engineering resistance is not relied upon as a primary security control (reverse-engineering is assumed possible and expected), but it adds a layer of effort that filters unsophisticated attacks.
Protocol fuzzing is performed in internal testing environments to identify parsing vulnerabilities before deployment. All packet parsing code is written in memory-safe Rust (gateway and networking layer) or uses bounds-checked array access with static analysis enforcement (C++ simulation server).

Exploit Detection and Response

Automated Exploit Detection

Beyond RMT detection, the analytics pipeline monitors for gameplay exploits:

Impossible kill rates: A character kills more monsters per hour than the maximum possible given movement speed and combat resolution speed → potential bot or speed-hack
Impossible item acquisition: An account receives items that have never been drop-table-valid for any zone they have visited → item duplication exploit or injection
Dungeon reset abuse: An instance is created and destroyed by the same account more than N times within a short window → farming exploit (specific mechanics)
Economy manipulation: A single account or coordinated group artificially controls the price of a currency or item type by buying out listings → detected by price time-series analysis

Response Framework

Exploit Type	Automated Response	Manual Escalation
Speed hack (position validation failure)	Session termination	If persistent across reconnects: ban
Combat roll manipulation (statistical anomaly)	Flag, continue monitoring	If confirmed: ban + audit neighboring accounts
Item injection (impossible item in inventory)	Item quarantine (visible but unequipable/untradeable)	Immediate human review, ban if confirmed
Economy manipulation (coordinated)	Temporary market restriction	Coordinated group ban if confirmed
Dungeon reset abuse	Rate-limit instance creation for account	Review threshold/legitimacy, ban if clearly exploitative

Exploit communication: Exploits that are patched (not ban-worthy in isolation) are not publicly announced in patch notes with specific exploit descriptions — detailed exploit disclosure helps bad actors understand what they were doing before the patch. Patch notes acknowledge a "fix for an exploit" without specifics. Exploits that were actively and knowingly used for economic gain result in bans and confiscation of gained goods, with the reasoning communicated privately to the banned account.

Data Privacy and Compliance

Player Data

Salt & Steel collects and retains:

Account data: email, hashed password, 2FA configuration
Session data: IP addresses, device fingerprints (retained 30 days)
Gameplay data: all game state, transaction history (retained for account lifetime)
Telemetry data: anonymized performance metrics (retained 90 days)
Economy audit log: all transactions with timestamps and account IDs (retained 2 years for fraud investigation)

GDPR / privacy compliance:

Account holders may request export of their personal data (email, account history) via a self-service portal. Export is delivered within 72 hours.
Account deletion: players may request account deletion. Account deletion is processed within 30 days. Account Record data (reputation, ship names — the append-only legacy record) is anonymized rather than deleted, as it may be referenced in other players' game histories (a legendary captain's reputation may persist in the world even after account deletion). Players are notified of this specific retention at signup.
Data processing is subject to the relevant regional privacy regulations (GDPR for EU players, CCPA for California players). The privacy policy explicitly documents all data collection categories and their retention periods.

Security Review Process

Pre-launch security audit: An independent penetration testing firm is engaged 6 months before launch to audit:

Authentication and session management
Protocol security (network-level penetration testing)
Account security features (2FA bypass attempts, session fixation, CSRF)
Economy integrity (trade fraud scenarios, item generation validation)
Server-authority bypass attempts (proof-of-concept cheat tool development to identify vulnerabilities)

Ongoing security posture:

Monthly internal security review of new features before deployment
Bug bounty program for security vulnerabilities (responsible disclosure rewarded with in-game cosmetics or, for critical vulnerabilities, financial reward)
Post-incident reviews for any security event affecting 100+ accounts

Cross-references: design/10-technical-architecture/server-architecture.md, design/10-technical-architecture/networking-model.md, design/05-economy/currency-system.md, design/05-economy/trade-system.md