# Smart Accounts
Source: https://docs.chain.link/crec/concepts/smart-accounts
Last Updated: 2026-08-31

> For the complete documentation index, see [llms.txt](/llms.txt).

A **Smart Account** is the on-chain identity that executes your [Operations](/crec/concepts/operations). Each Smart Account is:

- **Tenant-owned.** The Account is provisioned by your CRE Connect tenant and configured with an explicit list of authorized signer keys.
- **Per-chain.** A Wallet is created on a specific chain (identified by its CCIP chain selector). To operate on multiple chains, create one Wallet per chain.
- **Signature-verifying.** Every Operation submitted to the Account must carry a valid EIP-712 signature from one of the Account's authorized signers.

In the SDK and REST API, the resource that represents a Smart Account is called a **Wallet**. The two terms refer to the same thing: a Wallet is the off-chain record, and the Smart Account is its on-chain instantiation.

## Account abstraction model

CRE Connect Smart Accounts implement a Chainlink-native account abstraction model. They are **not ERC-4337 accounts**: there is no EntryPoint, UserOperation, paymaster, or bundler in the picture. The model is:

- **Account creation** is performed through an on-chain factory contract that deterministically deploys a Smart Account per (tenant, wallet ID) pair.
- **Authorization** lives entirely inside the Account contract. It accepts a payload `(operation, signature)` and verifies the EIP-712 signature against its configured signer list before executing.
- **Execution** is invoked by the Chainlink DON. A Chainlink-operated writer EOA broadcasts the transaction on the Account's behalf, so on-chain `tx.origin` is the DON writer (not the user). The Account contract authorizes the call by recovering the EIP-712 signer from the supplied signature and checking it against the wallet's allow-list. `msg.sender` is only used to enforce that the call comes from one of the approved Chainlink writer addresses.

This keeps the on-chain footprint small (one factory + one Account contract per wallet) and removes the need for any 4337 infrastructure on the chains you operate on.

## Signer model

A Wallet's authorization rules are fixed at creation time. You declare them through one of two `WalletType` values:

| `WalletType` | Allowed signer field                                              | Signer payload                                                                                  |
| ------------ | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `ecdsa`      | `AllowedEcdsaSigners`: `[]string` of EVM addresses                | The recovered EIP-712 signer address must be in this list.                                      |
| `rsa`        | `AllowedRsaSigners`: list of `{ E, N }` RSA public-key components | Used by Smart Accounts that verify RSA-signed payloads (selected workflows / KMS integrations). |

A Wallet is **either ECDSA or RSA**, never both. The SDK enforces this at create time:

- For `ecdsa`, `AllowedRsaSigners` must be `nil` and `AllowedEcdsaSigners` must contain at least one valid hex address.
- For `rsa`, `AllowedEcdsaSigners` must be `nil` and every entry in `AllowedRsaSigners` must have non-empty `E` and `N`.

The signer set is fixed once the Wallet is created. There is currently no SDK method to add or remove signers after the fact. To rotate keys, create a new Wallet and migrate.

## Wallet lifecycle

A Wallet is provisioned asynchronously: the SDK returns immediately and the on-chain Smart Account is deployed in the background.

(Image: Image)

| Status      | Meaning                                                                                                           |
| ----------- | ----------------------------------------------------------------------------------------------------------------- |
| `pending`   | The Wallet record was created in CRE Connect; on-chain deployment has not started yet.                            |
| `deploying` | The deployment workflow is awaiting on-chain inclusion.                                                           |
| `deployed`  | The on-chain Account is live and able to execute Operations. The deployed address appears in the Wallet response. |
| `archived`  | The Wallet is read-only; new Operations are rejected.                                                             |
| `failed`    | Deployment failed. The latest `wallet.status` event includes the reason.                                          |

Lifecycle transitions are emitted as `wallet.status` events into the channel that owns the Wallet. Subscribe to them to drive your provisioning state machine; see [Create and Manage Wallets](/crec/guides/wallets/create-and-manage).

## Constraints and limits

| Setting                                           | Value                                     | Source                                                                                                                     |
| ------------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Wallet name maximum length                        | 255 characters                            | `wallets.MaxWalletNameLength`.                                                                                             |
| Maximum allowed signers per list (ECDSA *or* RSA) | 10                                        | `maxItems: 10` on `ECDSASignersList` / `RSASignersList` in the OpenAPI spec.                                               |
| Wallet types per Wallet                           | One (`ecdsa` *xor* `rsa`)                 | SDK validation.                                                                                                            |
| Status update channel                             | Optional `StatusChannelId` at create time | The channel that receives `wallet.status` events. The SDK rejects a zero-UUID value with `wallets.ErrStatusChannelIDZero`. |

For a comprehensive list of service-side limits, see [Service Limits](/crec/reference/service-limits).

## Predicting addresses

The on-chain Account address is derived deterministically from the factory, the unique account ID (the Wallet's UUID), the initial owner, and config data. The Wallet record exposes the predicted address before deployment finishes, so applications can reference the address (e.g. for funding or RBAC setup) without waiting for the `deployed` event.

> **TIP: One Wallet, one chain**
>
> A Wallet is bound to a specific chain. Cross-chain workflows compose multiple Wallets, one per chain, into a single
> business flow. Use the channel-level event stream to coordinate state across them.

## Related

- [Operations & Transactions](/crec/concepts/operations) · [EIP-712 Signing](/crec/concepts/eip712-signing): what the Smart Account executes and verifies.
- [Create and Manage Wallets](/crec/guides/wallets/create-and-manage) · [Manage Wallet Signers](/crec/guides/wallets/manage-signers): the SDK and REST workflows.
- [Account Abstraction & Gas Sponsorship](/crec/concepts/account-abstraction): why these accounts cost no gas to drive.