Skip to main content
A smart account is a programmable account implemented as a smart contract. It holds assets, validates authorizations, and executes calls onchain. Unlike a traditional externally owned account (EOA), whose transactions are authorized by a single private key, a smart account defines its authorization rules in code. Those rules can support passkeys, multiple signers, scoped permissions, and recovery mechanisms.

​
Accounts and signers

The account and its signer serve different purposes:
  • The account holds assets and interacts with other contracts.
  • The signer produces a signature that the account checks before allowing an action.
For example, a passkey can authorize a vault deposit without holding the deposited tokens itself. The tokens belong to the smart account, and the account calls the vault. This separation lets you change how an account is controlled without moving its assets to a new address. Depending on its configuration, an account can accept a new signer, require multiple approvals, or grant a session key permission to perform specific actions. An external wallet or an embedded signing provider can also supply a signer. In that setup, the signer’s address and the smart account’s address are distinct; assets sent to one do not automatically appear at the other.

​
Extending an account with modules

Rhinestone uses modular smart accounts compatible with ERC-7579. Modules are contracts that extend account behavior through standardized interfaces.
  • Validators check authorization, such as a passkey signature, a multisig threshold, or a session key’s permissions.
  • Executors provide execution paths through which installed modules can instruct the account to perform calls. Rhinestone’s Intent Executor is one example.
  • Hooks run checks or custom logic before or after execution.
  • Fallbacks extend the account’s interface with additional functionality.
Modules carry authority, not just features. The installed modules and their configuration determine which actions are permitted and who can change account control.

​
Smart accounts across chains

A smart account’s address can be calculated before its contract is deployed. This is called a counterfactual address: you can receive assets there before the account’s first transaction. Compatible deployments can use the same address across supported chains, but deployment and state remain separate on each chain. Installing a module or changing a signer on one chain does not automatically update the others. The address depends on the account implementation and deployment configuration. Do not assume that different account types or configurations produce the same address.

​
Smart accounts and intents

Smart accounts provide programmable authorization and execution. Intents coordinate how an authorized operation is funded and carried out. Together, they let an application use assets across chains while executing destination calls through the user’s smart account.

​
Next steps