Oasis is a web platform with four functional layers: a relic and location catalogue, a hunt engine that controls what unlocks when, a verification layer that proves a participant was really there, and a reward layer that settles what they earned. This page describes each as documented in internal architecture material.
01Catalogue and spatial registry
The content layer holds the relics and the places they belong to. Platform documentation records a catalogue of more than one hundred relics organised across sixty-nine categories and twenty-two tiers, with tiering used to express rarity. On the infrastructure side, the corresponding store is described as a spatial registry holding relic metadata, backed by a geospatially indexed database.
Tiering is not decoration. It is the input to the reward inventory rules described below, and it is what makes a given relic scarce rather than merely themed.
02Hunt engine
Hunts are time-structured rather than open-ended. Documentation describes a progressive fourteen-day mechanic in which participants collect timed clues, with clue release windows and hunt schedules governed by shared ecosystem timing policy rather than hardcoded per campaign. Real-time leaderboards run alongside.
Solve validation is multi-factor. Participants submit a solve or passphrase, which is checked against the expected value, and platform notes describe cryptographic phrase generation as part of that check. A correct answer alone is not sufficient, because the location and integrity checks below run in the same path.
03Location verification and anti-cheat
This is the layer that distinguishes Oasis from a quiz. Documented behaviour runs in three steps.
First, location-gated unlocks combine a geofence check with device attestation before any location-locked content is revealed. On success the platform issues an ephemeral location token that rotates and is tamper-checked, and that token validates the participant's live position for each interaction cycle rather than once per session.
Second, on solve submission, anti-cheat routines run against movement data and device signatures to detect teleporting, GPS spoofing, and duplicate claims.
Third, a successful solve produces a single-use claim token bound to both the participant and the specific hunt. AR photo validation at real landmarks via WebXR is documented as an additional proof-of-presence mechanism.
04Reward settlement
Claiming consults a reward ledger that determines availability, rarity class, and distribution limits for each relic. The platform then grants mint or redeem rights in line with that inventory and rarity governance. The documented end-to-end path runs: participant enters the geofence, location and device are validated, an ephemeral location token is issued, the hunt is completed, a single-use claim token is issued and validated, the reward is minted, and it is stored in the participant's ecosystem wallet.
05Integration surface
Oasis is designed as an execution hub inside a larger estate. Internal integration plans describe a per-platform route family for relic data, a general API namespace, and a console sync path, with traffic reaching the platform through a gateway over mutually authenticated TLS and scoped access tokens covering hunt, claim, and reward operations. No public developer documentation for these interfaces has been published.