> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sumvin.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Safe smart accounts and identity

> How Safe multisig wallets anchor a user's on-chain identity.

# Safe smart accounts and identity

Every Sumvin user has a **Safe smart account** — a multisig contract deployed on their primary chain. The Safe is the user's on-chain identity anchor. It is the address that appears in their user <Tooltip headline="SRI" tip="Sumvin Resource Identifier — URI-style identifier for users and capabilities." cta="Glossary →" href="/glossary">SRI</Tooltip>, the address that signs their PINTs (via the Safe's signer set), and the counterparty for any on-chain action the user authorises.

## Why Safe rather than an EOA

An externally owned account (EOA) is a single keypair — lose the key, lose the identity. A Safe is a contract with a configurable signer set, which gives three properties that matter for identity:

* **Programmable ownership.** Owners can be added and removed without changing the address. Today a Safe's owners are the user's [agent signer](/identity/agent-signers) and, where a developer registers one, a CLI mandate key held locally by the Sumvin CLI; passkeys and recovery keys follow the same mechanism later.
* **Contract-based signature verification.** Safes implement [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271), so any party can verify a signature against the Safe without knowing which signer produced it.
* **Multi-device resilience.** A user can authorise multiple devices and agents against the same identity without spraying addresses across surfaces.

## How a Safe binds to an SRI

The Safe's address is the identifier in the user's SRI and in any PINT they sign:

```text theme={null}
sr:us:person:safe:0xE23c9A70BC749EBddd8c78a864fd911D04E9e992
```

The same address appears as the `verifyingContract` in the [EIP-712 domain separator](/identity/pint) on every PINT the user signs, and as the `wallet` claim on the exchanged JWT.

## Chain considerations

A Safe is deployed on a specific chain. The user's **primary EOA** determines their **primary chain**, and the Safe is deployed on that chain asynchronously after user creation. The Platform API returns `202 Accepted` during that window and exposes a poll link — see [the wallets guide](/guides/wallets) for the full flow.

Cross-chain operations require deploying Safes on additional chains; the deterministic deployment means the same address is reachable on each. Every on-chain action originating from a Safe is dispatched as a [sponsored UserOperation](/concepts/sponsored-user-operations) — Sumvin pays gas, the user signs.

## See also

* [Wallets guide](/guides/wallets) — Safe creation, chain selection, ownership verification
* [Sponsored UserOperations](/concepts/sponsored-user-operations) — the lifecycle and status vocabulary for every on-chain action a Safe takes
* [Submitting UserOperations](/guides/safe-user-operations) — end-to-end worked example with request/response payloads
* [EIP-712 & Purchase Intents](/identity/pint) — the Safe address as `verifyingContract`
* [Sumvin Identity overview](/identity/overview) — Safe as the identity anchor

## Referenced from

* [Purchase Intents](/identity/pint)
* [Signing keys](/concepts/signing-keys)
* [Card issuing](/concepts/card-issuing)