> For the complete documentation index, see [llms.txt](https://sdk.metamarket.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sdk.metamarket.tech/architecture-and-trust/product-overview.md).
# Architecture Overview
MetaMarket runs games and interactive modules on one shared backend, under one shared player identity and the platform's shared currencies (GG plus loyalty points), while each game keeps its own local economy and state. A game talks to it over HTTP, through the .NET SDK or directly; everything behind that call is the platform. This page is the system view: the layers, where data lives, and who owns what.
One foundation carries identity, actions, quests, progression, rewards, inventory, and the economy. Studios combine those parts into [engagement and loyalty](/use-cases/engagement-and-loyalty-use-cases.md), [game economies](/use-cases/game-economy.md), [marketplace workflows](/use-cases/marketplace.md), and [operational data](/use-cases/engagement-data-and-operational-insights.md), and [Product Availability](/overview/current-scope.md) records where each of those stands today.
## One engine, many tenants
Instead of building a separate backend per game, MetaMarket registers each game as a tenant ("app") on top of a single shared engine. Quest evaluation, action tracking, reward fulfillment, and resource regeneration all run through the same code path for every tenant. A game developer configures actions, resources, quests, and rewards as JSON; the engine interprets that config at runtime.
```mermaid
flowchart TB
subgraph Tenants["Tenants: each keeps its own local data"]
A["game-a"]
B["game-b"]
C["sandbox"]
end
Engine["One shared engine: actions, quests, rewards"]
Shared["Shared across every tenant: player identity + GG"]
A --> Engine
B --> Engine
C --> Engine
Engine --> Shared
```
Every tenant keeps its own local economy and local player state, isolated by an `app_id` on every tenant-scoped record. What is shared across all tenants is the player's identity (one account, many devices) and a platform-level currency called GG (Global Gold/Gems). A connected game reads the shared identity (id and display name) but does not read or spend GG, loyalty points, tiers, or badges; the object-by-object permissions are in [Local and Shared Economies](/core-concepts/shared-economy.md).
Each game and module is registered as a tenant with its own app id, and every tenant-scoped record carries it. New tenants are onboarded directly with the team today; self-serve registration is on the [Roadmap](/releases-and-reference/roadmap.md).
## A game is registered at two levels
The same game has two registrations, and they carry different permissions.
At the per-game engine it is registered with its full action vocabulary: every action id the game may report, its resources, its quests, and its rewards. This is the list an integrator works against day to day.
At the Hub it is registered again, with a much shorter list: only the milestone keys the platform will honour from that game. Nothing else it does can reach the shared layer, whatever its client sends.
The second list is agreed with MetaMarket at onboarding and is deliberately narrow. It is the reason a game cannot mint shared value: the permission to affect the shared layer is granted per milestone, not per game.
## The three layers
Three pieces make up the running platform:
* **The Hub** owns global identity end to end (accounts, devices, sessions) and the shared balance (GG, platform quests). It is the only place cross-game data lives.
* **The per-game engine** runs each tenant's own quests, actions, and local economy. It is one multi-tenant process, not one deployment per game: every request names its tenant with `X-App-Id`, and the engine scopes the work to that tenant's data.
* **The edge gateway** is the proxy an external game's client talks to; it forwards player-facing calls to the per-game engine and translates event-tracking calls into an authenticated call to the engine on the game's behalf, so the client never holds the game's own credentials.
```mermaid
flowchart LR
Client["External game client"] --> Gateway["Edge gateway"]
Gateway --> Engine["Per-game engine
(one tenant's quests, actions, economy)"]
Engine -->|"auth calls, proxied"| Hub["Hub
(global identity + GG balance)"]
Engine -->|"platform value"| Hub
```
Which of these a client talks to, and how, depends on the app's trust archetype; see [Integration Overview](/evaluate-and-integrate/integration-overview.md) for the concrete door mechanics an SDK integrator needs.
## The platform runs on its own engine
MetaMarket's own built-in modules, a shop and a wheel-of-fortune, are ordinary tenants that run with elevated privilege. They go through the same registration path as any third-party game.
The shared engine mechanics, meaning quest, action, reward, and resource evaluation, are the same code path for both, with no special-cased shortcuts. If the engine is good enough for a third-party game, it is good enough for the platform's own features.
What differs is trust, not the engine. First-party modules run with elevated privilege and reach the engine through a direct path. Every app is registered under one of three trust archetypes, which decide what it can reach and which door its clients use. [Roles](/architecture-and-trust/users-and-actors.md) has the full breakdown.
An app's registry row also carries a status field (`active`/`suspended`): the platform can suspend a tenant without deleting it.
## One identity, one wallet, and platform quests
A player's account is anchored to a device keypair, and the player carries it into another game by linking that game's install through a handoff (a fresh install starts as its own guest until linked; see [Players and identity](/core-concepts/players-and-identity.md)).
```mermaid
flowchart LR
Player["One Player identity"]
D1["Device A"]
D2["Device B"]
G1["Game A"]
G2["Game B"]
Player --> D1
Player --> D2
D1 --> G1
D2 --> G2
```
Two kinds of value exist side by side:
* **Local currency**: tenant-specific soft currency (pet coins, tickets, energy), earned and spent entirely inside one game, invisible to every other tenant.
* **GG (Global Gold/Gems)**: the platform-owned currency, held on the shared balance. A game never credits it. The only route from in-game activity to GG runs through a milestone the game declares in its own configuration, which a platform-owned quest turns into a grant. That single control point is what stops any one title minting platform currency, and it is paired with the matching read restriction: a connected game cannot see or spend a balance either. [Local and Shared Economies](/core-concepts/shared-economy.md) gives the permissions object by object.
Layer placement is decided by the scope of the data: global or cross-game data lives on the platform's shared balance; anything local to one game lives on that game's own layer.
Loyalty points sit on the same shared balance as a second platform currency: earned the same way GG is (the bridge quest, plus a daily bonus). A player spends them through platform surfaces, not inside a connected game, which cannot read or move them. A player's loyalty tier and badges are platform-owned and carried into every game, for the same reason their identity is. See [Local and Shared Economies](/core-concepts/shared-economy.md) for the full mechanic.
On top of the wallet, the platform can define platform-owned quests that watch a specific game's activity and reward GG or a reward package. A player sees these inside that game's own quest list, next to the game's local quests, with the platform origin shown openly. A first-party portal, the Meta App, is the platform's own surface for moving between a platform home and individual games under one login. It runs on the same platform-door path as the other first-party modules.
For where each layer stands today, see [Product availability](/overview/current-scope.md); to build on it, [Evaluate MetaMarket](/evaluate-and-integrate/evaluate.md).