Warpkeep experimental Alpha
Privacy Notice
This notice describes the personal data the current Warpkeep Alpha is designed to use, why it is used, where it goes, and the limits of retention and deletion.
Alpha Privacy Notice revision 2026-07-19-v1 · Last updated 19 July 2026
This is a factual, project-authored Alpha notice, not a legal-compliance certification or legal advice. Formal privacy review and a dedicated legal contact remain future work.
1. Who is responsible and how to contact the project
Warpkeep is an independent, single-developer project maintained through the ael-dev3/Warpkeep repository. For this Alpha, the project maintainer determines the uses described here and is the privacy contact where applicable. This notice does not represent that Warpkeep is a separately incorporated company, and the repository does not currently publish a postal address, dedicated privacy email, or data-protection officer.
To make a privacy request, contact the public ael-dev3 GitHub profile or open a content-free repository issue titled Privacy contact request, then wait for a private channel. Do not post your FID, proof, token, cookie, QR payload, wallet information, or identity evidence publicly. Report security issues through the Security Policy.
2. When data processing begins
Loading the title or menu does not make the Warpkeep application start Farcaster authentication, read a Warpkeep session cookie, or connect to SpacetimeDB. Selecting Enter Realm first opens one unchecked entry-agreement gate. Authentication begins only after you check the box and continue. That one box accepts the current Alpha Terms and Hegemony Social Contract, not this Privacy Notice as blanket privacy consent. The gate state exists only in component memory and is not itself an identity record or consent to unrelated data uses. After an admitted player authenticates, the game records separate private, versioned acceptance evidence as described below.
Hosting and network providers may still receive ordinary request data when your browser loads the public site, under their own notices.
3. Data, sources, and purposes
- Farcaster sign-in: your browser and Farcaster provide a signed sign-in message, signature, request identifiers, and public FID so Warpkeep can verify account control. The authentication bridge accepts, stores, and issues only the verified FID as session identity. Separately, trusted Farcaster network data may supply the admitted player's current public username, display name, avatar, bio, custody address, and verified EVM addresses. Presentation fields may be copied into public realm state; wallet associations remain private operator state and are never accepted from the browser as authoritative.
-
Entry-agreement acceptance: after an admitted player checks the gate,
authenticates, and requests entry, SpacetimeDB stores private, immutable evidence
containing the verified FID, exact entry-agreement bundle version, and acceptance
time. The Alpha Terms incorporate Hegemony Social Contract version
2026-07-19-HEGEMONY-SOCIAL-CONTRACT-V3in entry-agreement bundle2026-07-19-hegemony-entry-agreement-v3; the published browser policy cryptographically binds the exact visible Terms and Social Contract texts to their reviewed hashes. This evidence is used to enforce the current entry agreement and preserve an audit trail. It is not a public projection and does not contain the checkbox state, QR payload, proof, signature, token, cookie, or wallet information. -
Browser and session security: Warpkeep uses an origin, challenge
timestamps, a one-attempt browser-binding digest, an opaque session-family
reference, remember-device choice, rotation state, and admission epoch to prevent
replay and maintain the session you request. After a fresh signature and a
same-FID bridge exchange, the browser may keep a tab-scoped presentation cache in
sessionStorage. It contains only the sanitized public FID, username, display name, and HTTPS avatar URL. It cannot grant or restore access and is read only after a successful bridge refresh, then displayed only for the exact same FID. It never contains a proof, token, JWT, cookie, custody or verification address, or verification data. If storage is unavailable, Warpkeep shows the verified FID without cached presentation. - Server-to-server admission resolution: during proof exchange and each session refresh, the bridge can mint an exact one-FID resolver credential with a 15-second maximum authority window. It is used only to connect to the fixed SpacetimeDB service and database and call the fixed admission procedure. Warpkeep is designed not to persist it, return it to the browser, or place it in logs. A public-table subscription opened while that credential is fresh can remain open until its transport disconnects; credential expiry does not itself close that subscription.
- Network abuse prevention: Cloudflare supplies the connecting IP. Warpkeep immediately converts IPv4 or an IPv6 /64 into a versioned SHA-256 bucket name and stores only that bucket with request timestamps for rate limiting, not the raw address in application storage.
- Realm data: SpacetimeDB stores admission, ownership, world, player, castle, and administrative state needed to operate and secure the shared Alpha. Active public player/game projections can expose an admitted player's FID, trusted Farcaster presentation, castle, and gameplay presentation to connected clients. After the player's first intentional Alpha entry, public presentation may also include aggregate SNAP burned and Mark earned, spent, and balance figures. The opaque-identity ownership mapping, allowlist, slot claim, authoritative Mark account, and administrative audit rows are private. A frozen legacy public player schema still contains its original public opaque-identity column for wire compatibility. Browsers and gameplay paths never write or subscribe to that table. Private deployment checks read only its aggregate row count and require it to remain empty.
- SNAP burns and Marks: a privacy-bounded operator process may read finalized public Ethereum mainnet events for the pinned SNAP contract and current public Farcaster wallet associations for admitted FIDs. It credits an event only when one eligible sender address maps to exactly one admitted FID. Private state can retain the wallet attribution, transaction and block references, scan cursor, and immutable credit receipt needed for deduplication, correction, and audit. The browser never scans wallets and never receives wallet addresses or individual burn receipts. Warpkeep does not connect a wallet, request a signature or token approval, submit a transaction, take custody, or receive a payment through this process. Marks are experimental game-only accounting units: non-transferable, non-redeemable, without cash value, and subject to correction or reset.
- Operations: Warpkeep emits a closed list of generic security and availability event names. Application logs are designed not to contain FIDs, profiles, proofs, signatures, tokens, cookies, QR payloads, private keys, or raw upstream responses. Service providers may keep their own infrastructure logs.
These data are used only to deliver requested Alpha access and gameplay, verify and authorize players, keep sessions, prevent abuse, protect the service, diagnose safe operational failures, reconcile the published game-accounting policy, and meet applicable legal obligations. Warpkeep's code does not currently add advertising or analytics and the project does not sell player data.
4. Legal bases where applicable
Which legal basis applies depends on the jurisdiction and purpose. Where a legal basis is required, the project relies on steps needed to provide the Alpha you request and perform the current entry agreement; legitimate interests in authentication, service security, abuse prevention, and reliable operation; and legal obligations where they apply. The entry-agreement checkbox is not intended as blanket privacy consent. If a future optional use relies on consent, it must be separately explained and that consent may be withdrawn without changing earlier lawful processing.
5. Retention and deletion limits
| Data | Current limit |
|---|---|
| Unchecked entry-agreement-gate state | Component memory for one entry attempt; cleared on cancel, completion, retry, navigation, or unmount. |
| Versioned entry-agreement acceptance evidence | No fixed Alpha deletion schedule yet. The private FID, exact entry-agreement bundle version, and acceptance time remain while needed to enforce entry terms, resolve disputes, protect the service, and preserve the Alpha audit trail, unless reset or manually deleted. |
| Sign-in challenge and browser-binding digest | Usable for at most five minutes and consumed on a definitive exchange. Expiry makes it unusable and schedules durable cleanup; physical deletion can be subject to provider cleanup and backup retention. |
| Signed proof and private binding verifier | Used transiently for the exchange; not intentionally placed in application logs or persistent browser storage. |
| Access token | Authority expires after at most ten minutes. It is held only in JavaScript memory and cleared when expiry/lifecycle handling runs, on logout, or on cancellation; browser suspension can delay cleanup without extending token authority. |
| FID-bound resolver credential | Authority is valid for at most fifteen seconds, used server-to-server only for the fixed admission lookup, and designed not to be persisted, returned to the browser, or logged. Expiry does not terminate a public-table subscription opened while it was fresh; that subscription can persist until transport disconnect. |
| Hashed rate-limit bucket and timestamps | Accepted requests are counted in a rolling five-minute window. The object schedules cleanup after the window; physical deletion can be subject to provider cleanup and backup retention. The raw address is not retained in Warpkeep application storage. |
| Server session family and HttpOnly cookie | Authority expires after at most thirty days. The cookie is a browser-session cookie unless you opt into “Keep me signed in”; server authority still expires after thirty days either way. Expiry makes the family unusable and schedules durable cleanup, subject to provider cleanup and backup retention. |
| Tab-scoped Farcaster presentation cache | Expires no later than the related server family and never after thirty days; sessionStorage normally clears when the tab closes. Warpkeep purges corrupt, expired, or FID-mismatched data when it is next examined after a validated refresh, and clears it immediately on sign-out or cross-tab logout. Storage denial leaves FID-only presentation. |
| Local logout-intent marker | Active for up to thirty days and then treated as stale. On a later read or explicit sign-in, Warpkeep attempts best-effort removal. Storage denial may leave the physical key; an explicit activation can proceed, but a later reload may continue to treat an unexpired leftover marker as logout intent. It contains only a version marker and time, with no FID, proof, token, cookie, family ID, or profile. |
| Game, ownership, admission, and administrative state | No fixed Alpha deletion schedule yet. It remains while needed for the shared realm, security, and audit, unless reset or manually deleted. |
| Trusted Farcaster profile and wallet-attribution snapshot | No fixed Alpha deletion schedule yet. Current public presentation may remain in replicated game state; wallet associations remain private and are retained only while needed for attribution, correction, security, and audit. |
| Finalized SNAP burn receipts, scan cursor, and Mark account | No fixed Alpha deletion schedule yet. Private receipts and chain references may remain for deduplication, reproducibility, correction, security, and audit. Only privacy-bounded aggregate figures become public game state. |
The limits above are authority and active-use windows, not promises that every storage copy or provider backup is physically erased at that instant. Logout revokes the server family when storage is available and expires the current cookie. A copied cookie may remain usable until the bounded family expires if durable revocation fails. Deletion requests may also be limited by public replicated game state, security or legal needs, and provider backup schedules; the project should explain any limit that applies rather than promise instant or universal deletion.
6. Services, recipients, and locations
The Alpha depends on GitHub Pages for the public site, Cloudflare for the auth bridge and durable session/security state, Farcaster network services and an Optimism RPC service for account verification, Ethereum RPC providers for bounded finalized-event reconciliation, and Clockwork Labs' SpacetimeDB Maincloud for shared realm state. Connected clients receive the public game projections described above. A public Farcaster avatar may be loaded from its HTTPS host with a no-referrer browser policy; that host still receives ordinary request data such as the connecting IP. These independent services handle data under their own terms and privacy notices.
These are global online services, so information may be processed in multiple countries, including outside the country where you live or access the Alpha. The Alpha cannot promise one storage country. Review provider notices before continuing if cross-border processing is a concern.
7. Your choices and rights
You can decline the entry-agreement gate and avoid starting Warpkeep authentication. Remember device defaults off. You can sign out, close the application, and ask the project to access, correct, erase, restrict, or provide applicable personal data, or object to certain processing. Depending on applicable law, some rights—including portability or withdrawal of consent—may apply only in particular circumstances. The project may need to verify control of the FID without collecting unnecessary identity evidence.
You may also complain to the privacy or data-protection authority that applies where you live, work, or where you believe an infringement occurred, when applicable. Contacting the project first is welcome but does not remove any complaint right.
8. Automated checks and no financial decisions
Automated rules validate challenges, apply rate limits, check Alpha admission, and revoke invalid sessions. Deterministic rules can also quarantine ambiguous burn attribution and apply the published 1:1 decimal-unit conversion to eligible finalized events. Those rules affect only technical access and experimental game accounting. Warpkeep does not use player data for credit scoring, behavioral advertising, or automated decisions that award, promise, or determine financial rewards, airdrops, or guaranteed gains. Alpha participation earns none of those benefits.
9. Changes
The date and version above identify this notice. The link in the pre-sign-in gate points to the current document. Material data-flow changes should be reflected here before the related feature is enabled; because the project is experimental, review the notice again when it changes.