DOCUMENTATION · SYSTEM EDITION

Tavyq Documentation

A detailed, plain-language guide to the Tavyq product, movement sync, game systems, evidence, privacy, and operations.
Version 1.1 · Updated 25 July 2026 · Private alpha
PLAIN LANGUAGE BY DEFAULT
18
system chapters
02
health adapters
01
source of truth
Tavyq is an independent product for the Robinhood Chain ecosystem and is not endorsed by Robinhood Markets, Inc. Tickets and points currently have no cash or token value.
IN THIS EDITION
01 What exists in the current product
02 Authentication and session ownership
03 Apple Health and Health Connect
04 How a step interval becomes eligible movement
05 Honest movement and anti-abuse decisions
06 Tickets and points are append-only
07 Assets and prediction windows
08 Prediction lifecycle
09 Reference data and void rules
10 From result to public evidence
11 Points, badges, leagues, and referrals
12 Useful prompts with a quiet default
13 Access, retention, export, and deletion
14 Administration and support boundaries
15 Validation, idempotency, and ownership
16 Deployment, recovery, and release gates
17 What the private alpha does not claim
18 Public resources and support
01
SYSTEM MAP

What exists in the current product

Tavyq is a cross-platform Expo application backed by a Fastify API and PostgreSQL. The private alpha includes onboarding, authentication, optional movement sync, tickets, market predictions, result history, points, badges, leagues, referrals, notifications, account controls, and public proof pages.
↗
The server is authoritative for eligibility, tickets, results, and progression.
02
IDENTITY

Authentication and session ownership

Email sign-in uses verified server workflows and short-lived access sessions.
Refresh secrets use native secure storage; browser sessions are limited to the current tab.
Every protected route derives ownership from the authenticated session, never from a client-supplied user ID.
Session revocation, device logout, export, and deletion are available from account controls.
Sensitive responses and logs exclude passwords, tokens, health samples, and private evidence.
03
MOVEMENT ADAPTERS

Apple Health and Health Connect

iOS reads Apple Health Step Count only after explicit permission.
Android reads Health Connect READ_STEPS only after explicit permission.
Web has no health connection and labels demonstration data clearly.
The app explains the benefit before opening the operating-system permission dialog.
Revocation clears local connection state and updates server-side provider state.
04
SYNCHRONIZATION

How a step interval becomes eligible movement

The client requests bounded changes from the health provider and submits normalized intervals with source evidence. The server validates time range, overlap, source, duplicates, manual-entry flags, and configured speed limits.
A local anchor or change token is committed only after the API accepts the batch. Network failure therefore cannot silently skip movement. Replayed intervals are idempotent and cannot issue a second reward.
05
ELIGIBILITY

Honest movement and anti-abuse decisions

Provider-reported manual entries are excluded from eligibility.
Duplicate source records and overlapping intervals are normalized or rejected.
Unrealistic accumulation is quarantined for review rather than immediately rewarded.
Daily eligible totals and daily ticket caps are enforced on the server.
A player-facing reason explains why movement is pending, excluded, or accepted.
06
LEDGER

Tickets and points are append-only

Balances are derived from immutable ledger entries such as issue, spend, return, win, correction, or administrative adjustment. A mutation requires an idempotency key and a documented reason.
Clients display the server balance and never calculate an authoritative value locally. A correction creates an opposite ledger entry so the original event remains auditable.
↗
No silent balance edits.
07
CATALOGUE

Assets and prediction windows

Only configured assets with a supported market-data source are shown.
Each window has opening, closing, resolution, and expiry times.
The UI disables submission before opening and after closing.
Asset status, market state, and freshness are visible in plain language.
Maintenance can pause one asset without disabling the rest of the game.
08
STATE MACHINE

Prediction lifecycle

Open — the market window accepts an Up or Down call.
Locked — the direction and active rules version can no longer change.
Resolving — opening and final evidence are being validated.
Won or Lost — deterministic comparison produced a valid result.
Void — a trustworthy comparison was impossible and the ticket is returned.
Corrected — a later verified issue created compensating ledger events.
09
RESOLUTION

Reference data and void rules

Submission preserves the asset, direction, rules version, and opening reference. Resolution selects a final reference under the same documented source and timing rules.
Equal values, missing data, stale data, conflicting source timestamps, or a failed integrity check produce Void. A temporary provider failure never becomes an automatic player loss.
10
PROOF LAYER

From result to public evidence

Canonical privacy-safe fields are serialized in a stable order.
Each result becomes a deterministic hash leaf.
Daily leaves are grouped into a Merkle tree.
The root and publication metadata are written to the evidence registry on Robinhood Chain testnet.
A public proof page recomputes the leaf and path without receiving identity, steps, sessions, or balances.
11
PROGRESSION

Points, badges, leagues, and referrals

Correct predictions create point ledger entries. Badge rules evaluate auditable events such as streak length, eligible movement, prediction accuracy, referral milestones, or tournament placement.
Weekly leagues reset the competitive window while preserving long-term identity. Referral rewards are capped and based on accepted activity so invitations cannot manufacture unlimited movement.
12
NOTIFICATIONS

Useful prompts with a quiet default

Permission is requested only after the user understands the benefit.
Categories include ticket ready, window closing, result available, streak risk, and league update.
Every non-essential category can be disabled.
Notifications avoid sensitive health totals on the lock screen.
Delivery failures do not change the underlying game state.
13
PRIVACY CONTROLS

Access, retention, export, and deletion

Pause synchronization without deleting the account.
Disconnect the health provider and revoke local access.
View active sessions and revoke individual devices.
Export account data in a readable format.
Request guarded transactional account deletion.
Read the public privacy policy and current data-use boundary before connecting health.
14
OPERATOR SAFETY

Administration and support boundaries

Operator access uses role-based permissions, protected sessions, and privacy-safe audit events. Support views the minimum evidence required to investigate a ticket, prediction, or access problem.
Raw health samples, authentication secrets, and unrestricted database tools do not appear in routine operator screens. High-risk corrections require a reason and remain visible in the audit trail.
15
API CONTRACT

Validation, idempotency, and ownership

OpenAPI defines request and response contracts.
Generated mobile schemas validate responses before they enter application state.
Normalized request IDs connect safe logs across services.
Idempotency protects sync, prediction, ledger, and deletion workflows.
Rate limits and abuse controls are stricter on authentication and sensitive mutations.
Owner-scoped queries prevent cross-account data access.
16
OPERATIONS

Deployment, recovery, and release gates

Production-like builds validate type safety, lint, tests, contracts, permissions, and public pages.
Database migrations are versioned, reviewed, and verified before serving traffic.
Backups require encrypted off-server copies and a tested restore procedure.
Health endpoints distinguish process availability from dependency readiness.
Rollback artifacts and migration compatibility are checked before release.
SBOM, secret management, incident response, and store declarations are release requirements.
17
CURRENT LIMITS

What the private alpha does not claim

Tavyq is not a broker, exchange, investment adviser, health provider, or guaranteed reward product. Tickets and points are non-transferable game units with no current cash, token, or redemption value.
Public beta still requires physical-device evidence, independent security and privacy review, managed production secrets, off-server recovery validation, app-store approval, and measured cohort performance.
18
HELP

Public resources and support

Privacy policy and controls: /privacy and /privacy/choices
Prediction rules: /prediction-rules
Community rules: /community-rules
Account deletion guide: /account-deletion
Service information: /status
Support: support@tavyq.com
CONTINUE EXPLORING
Read the complete product thesis.
Open whitepaper →