Smart Accounts
A Smart Account is the on-chain identity that executes your 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.originis 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.senderis 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,AllowedRsaSignersmust benilandAllowedEcdsaSignersmust contain at least one valid hex address. - For
rsa,AllowedEcdsaSignersmust beniland every entry inAllowedRsaSignersmust have non-emptyEandN.
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.
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.
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.
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.
Related
- Operations & Transactions · EIP-712 Signing: what the Smart Account executes and verifies.
- Create and Manage Wallets · Manage Wallet Signers: the SDK and REST workflows.
- Account Abstraction & Gas Sponsorship: why these accounts cost no gas to drive.