> 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/core-concepts/players-and-identity.md).

# Players and Identity

A player builds up progress in one game, opens a second game on the same phone, and can carry the same identity into it. On MetaMarket that continuity is possible because identity does not belong to any single game or device. It belongs to the player, and the player links their devices to it.

## One player, many devices

A Player is a durable, cross-game record: one identity a person carries between games, the anchor that progress, inventory, currency, and loyalty standing attach to. A game never creates its own account for them, and per-game data is addressed as the pair of the player and the game, so the same person keeps a distinct save in each game while remaining one identity underneath.

The platform only knows that two installs belong to the same person once the person links them. A brand-new install starts as its own guest Player, because there is nothing yet to tie it to an existing one. So a person can hold more than one guest Player at first, one per unlinked install, and linking them into a single identity is a deliberate step: the handoff described below. Under the current guest credential, continuity runs through handoff from a device the player still has signed in. Durable recovery of an account without that, through passkey or a linked social login, is planned, not available today.

A device is how a player proves who they are, not the identity itself. Each device generates a key pair on first use and keeps the private key locally; the platform only ever sees the public key. The device signs a short challenge with that private key when it signs in or refreshes a session, and the server checks the signature against the key on file; ordinary API calls after that carry the session's access token rather than a fresh signature. A device identifier on its own is never enough to obtain a session, which is what stops one device from impersonating another.

## Signing in

The first time a device connects, there is nothing to prove yet, so the platform registers the new device and issues a guest player on the spot. No password, no email, no external account. Guest identity is the credential the platform issues today; the model is built to add passkey and social sign-in later without changing how a game integrates.

From then on, the same device signs in by proving it still holds its key. Sessions are short-lived access tokens backed by a longer-lived refresh token, and the SDK renews them for you just before a request when the access token has expired, guarded so concurrent calls do not each refresh, so a game does not manage token lifetimes by hand. A `401` returned mid-request is surfaced as an auth failure rather than retried automatically.

## Moving between installs

Two games on the same phone look like two separate devices to the platform. Each app keeps its own key in its own sandbox, and a fresh install of either starts as its own guest.

To make both resolve to one player, the platform uses a one-time handoff. A signed-in install issues a short-lived code, the new install exchanges it, and from that point both are the same player. The same mechanism moves a player onto a genuinely new device, as long as they still have a signed-in one to issue the code.

A device can also be unbound. Its refresh token and future logins are revoked at once, so it cannot renew a session, and its current access token stops working when it expires, within 15 minutes.

## What the platform handles

Managed identity, device authentication, session handling, and cross-device handoff sit with the platform. A game keeps everything that makes the player theirs in that game: the profile, the progress, the local economy. The identity underneath is shared, and each game builds its own world on top of it.

The exact signing scheme, token lifetimes, and handoff calls are in [Authentication](/evaluate-and-integrate/authentication.md).