> For the complete documentation index, see [llms.txt](https://docs.alignedlayer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.alignedlayer.com/wallet-as-a-service/introduction.md).

# Introduction

Aligned Wallet is a developer platform for embedding non-custodial crypto wallets into applications. It is wallet-as-a-service with a security model that does not depend on trusting the service.

Every Aligned account is a smart account: a regular EOA delegated via [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) to dedicated smart-contract code. That code enforces a **2-of-2 rule** — a transaction is valid only with one signature from the end user and one from Aligned's backend, over a digest bound to the chain, the account, its nonce, and the call parameters.

## Why the 2-of-2 rule matters

The rule is publicly deployed bytecode at a known address, not a service-side promise. Two properties follow from that directly.

**Breach containment.** Compromising Aligned's infrastructure does not compromise user funds. The contract refuses any call lacking a valid user signature, whatever the backend does. The blast radius of a server-side incident is bounded by code rather than by operational trust.

**Auditability.** The guarantee is a specific contract you can read. There is no enclave attestation to take on faith and no proprietary cryptography to reverse-engineer.

## How it fits together

Three layers, with the security invariant in the lowest one:

* **Smart contracts.** `AlignedAccountProxy` is deployed once per chain, and every user EOA delegates to it. It routes each call through the app's own beacon to the current `AlignedAccount` implementation, which verifies the 2-of-2 signature on `execute` and `executeBatch`. There is no ERC-4337 EntryPoint, bundler, or paymaster.
* **Backend.** A Phoenix service that authenticates users, issues JWTs, holds the second signing key, evaluates policy before signing, and relays transactions. It is one of two signers, never a custodian.
* **SDKs.** Client libraries that applications embed, so the wallet is part of the host app's experience rather than an external one.

Because the backend relays and pays gas, end users never need to hold the chain's native token.

## What is supported

* **User keys:** ECDSA, P-256, and WebAuthn passkeys.
* **Chains:** Ethereum L1, and L2 rollups built with [ethrex](https://github.com/lambdaclass/ethrex). EIP-7702 requires the Pectra hardfork, so a target chain must have it.
* **Recovery:** an optional timelocked guardian, configured per account.

## Status

Pre-alpha. The architecture is defined and an internal MVP exists and has migrated to EIP-7702, but the platform is not generally available and interfaces are still changing. Treat anything here as subject to change until a release says otherwise.

## Next

[Quickstart](/wallet-as-a-service/quickstart.md) builds a working wallet in a web app. [How it works](/wallet-as-a-service/how-it-works.md) covers the account model and what the contracts guarantee.