# Security, Privacy & Data Integrity PaperMarket is a paper trading environment that runs entirely off chain.\ It never holds real USDC and never sends orders to Polymarket, but it still maintains long lived accounts and trading histories for its users. This section describes how the system thinks about security, what kind of data it stores about users and which guarantees it aims to provide around consistency and integrity of that data. The focus is on three areas * account and access security * user privacy and data scope * integrity of balances, orders, trades and positions ### Account and access security PaperMarket uses a standard account model based on email and password.\ Accounts are created and authenticated on the server side; the browser never sees or stores any secret credentials beyond what the user types into the login form. Key properties: * **Credential storage**\ Passwords are not stored in plain text. The server stores only password hashes created with an industry standard, one way hashing algorithm.\ On login the submitted password is checked against the stored hash. The original password cannot be recovered from the database. * **Session management**\ After successful authentication the server issues a session that represents the user’s identity for subsequent requests.\ The session token is sent with each request from the browser and is validated on the server before any account state is loaded or modified. * **Server side authorization**\ Every API endpoint that reads or changes balances, orders, trades or positions checks the authenticated user identity first.\ The application ensures that: * a user can only see their own simulation account * a user can only modify their own state * **No direct database access from the browser**\ The browser interacts only with high level HTTP endpoints.\ It never connects to the database directly and never sees database credentials or internal schema details. ### User privacy and data scope PaperMarket is intentionally conservative about the data it keeps. **Minimal identity** * The system identifies users by an internal user id and a login email. * Optional display names are used only inside the interface. * No wallet addresses, seed phrases or private keys are collected or stored. **No real money data** * The only balances stored are virtual cash balances used for simulation. * No credit card data, bank details or real USDC balances are part of the model. * PaperMarket never requests signatures for on chain transactions and never links a simulation account to an on chain identity. **Trading history as simulation data** * Orders, trades, positions and PnL are treated as simulation artefacts. * They are stored to help the user analyse their paper trading behaviour. * They are not shared with other users or with Polymarket. **Scope of data sharing** * Market data (order books, prices, history) is pulled from Polymarket. * Simulation data (balances, orders, trades, positions) stays inside PaperMarket. * The system is not designed to expose per user trading histories to third parties via public APIs. ### Integrity of balances, orders and trades The internal consistency of the simulation state is critical.\ A user should be able to look at their account and understand how every number was produced. To support this, PaperMarket follows several discipline rules. **Append oriented history** * Trades are written once and never overwritten. Orders are created once; the matching engine only updates their status and fill statistics. Positions and cash balances are derived from these underlying records rather than being patched manually. * When an action occurs, the engine adds new records instead of mutating old ones. * Positions and cash balances are derived from these underlying records. **Reconstructable state** Given access to the database, it is always possible to: * recompute a user’s net position in any token from their trades * recompute their average entry price from the same trades * see how each trade affected the virtual cash balance The engine does not “patch” history to hide bad trades or adjust PnL. **Balance invariants** The simulation enforces simple invariants at all times: * virtual cash is never negative * net position per token is never negative * every trade that reduces cash or position size has a clear, matching record If an operation would violate these invariants, it is rejected or automatically truncated before any state is written. **Atomic updates per event** For each simulation event (for example a new order): * the engine computes the full effect of that event * persists the order, trades, balances and positions as a coherent set * only then exposes the new state to the user This avoids half updated accounts where orders exist without trades, or positions change without a corresponding history entry. ### External dependencies and failure handling PaperMarket depends on external services for market data, most importantly Polymarket’s public APIs.\ Failures in those services are treated as normal conditions that must be handled explicitly. The engine follows conservative rules: * if Polymarket’s order book or history endpoints are unavailable or return invalid data, the simulation does not fabricate prices or fills * in these cases, trade simulation is rejected and the user is informed that the action cannot be performed with current data * existing simulation state (balances, orders, trades, positions) is never altered as a side effect of external data failures This approach keeps a clear line between “data we control” (simulation state in the database) and “data we consume” (Polymarket market data). PaperMarket’s guarantees apply only to the state it owns.\ It does not attempt to correct or reinterpret Polymarket’s view of markets; it uses that view as is and clearly separates it from the user’s off chain simulation record. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://papermarket.gitbook.io/papermarket/technical/security-privacy-and-data-integrity.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.