> 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/how-it-works.md).

# How it works

## The account

Each user gets a smart account at their own EOA address. The EOA is delegated with [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) to Aligned's account code, so the user's address is the same on every chain. Each chain needs its own one-time delegation, which Aligned submits, and there is nothing else to deploy per user.

The EOA key that signs the delegation is generated in memory by the SDK, used for the authorization and the init payload, and dropped before wallet creation returns. It is never stored or sent anywhere. That matters: EIP-7702 leaves the original key valid, and a key that survived could sign ordinary transactions that skip the rules below.

## Two signatures, checked on chain

A transaction from an Aligned account is valid only with two signatures:

1. the user's key, held on their device, and
2. Aligned's server key for your app.

The account contract verifies both before it executes anything. They sign a digest built from the chain id, the account address, its current nonce, the destination, the value, and a hash of the calldata, so a signature cannot be replayed on another chain, another account, another nonce, or with different parameters.

Two things follow:

* **A breach of Aligned's backend does not move funds.** The contract refuses any call without a valid user signature, whatever the backend does.
* **A stolen device is not enough on its own either.** Every transaction also needs Aligned's signature, and the backend can refuse to give it.

The rule is deployed bytecode at a public address, so anyone can read it. There is no enclave attestation to take on trust and no ERC-4337 EntryPoint, bundler, or paymaster in the path.

## Gas

Aligned submits the transaction and pays the gas. Your users never hold the chain's native token. That includes the one-time delegation transaction that creates the account.

## The contracts

Three pieces, from the outside in:

* **`AlignedAccountProxy`**, deployed once per chain. Every user EOA delegates to this one address. It forwards each call to the implementation its beacon names.
* **`AlignedBeacon`**, one per app. It holds the app's server signer, its guardian signer, and the account implementation its wallets run. The owner can rotate the signers and repoint the implementation without touching individual accounts.
* **`AlignedAccount`**, the implementation. It verifies the 2-of-2 signature on `execute` and `executeBatch`, answers `isValidSignature` (ERC-1271) for off-chain message signing, and manages the account's user keys.

## User keys

An account holds up to 10 keys, of three kinds:

* **WebAuthn passkeys**, the default for apps, one per device, verified on chain as P-256 with the WebAuthn envelope.
* **P-256** raw keys.
* **ECDSA** (secp256k1) keys.

Keys are added and removed by the account itself, which means each change is a transaction carrying the same 2-of-2 signature as any other. See [Keys and recovery](/wallet-as-a-service/keys-and-recovery.md).

## Recovery

An account can be created with a guardian and a timelock, between 1 and 14 days, fixed at creation and immutable afterwards. The guardian key is the one configured for your app on its beacon, and Aligned's backend signs with it once the user has passed a second email confirmation.

The guardian can add a key, but that key cannot sign until the timelock expires, which leaves the owner a window to cancel it from any device that still works. An account created without a timelock has no guardian path at all.

## Chains

Ethereum L1 and L2 rollups built with [ethrex](https://github.com/lambdaclass/ethrex). A chain must have the Pectra hardfork, since that is what brings EIP-7702.