Account abstraction (AA) replaces signed EOA transactions with a more expressive primitive: the UserOperation. With the Startale AA SDK you build on top of an ERC-7579 modular account that is settled through SCS bundler and paymaster infrastructure, so you can deliver gas sponsorship, ERC-20 gas payment, social recovery, smart sessions, batched calls, and EIP-7702 delegation without operating any of that infrastructure yourself.Documentation Index
Fetch the complete documentation index at: https://docs.startale.com/llms.txt
Use this file to discover all available pages before exploring further.
The UserOperation lifecycle
A UserOperation is the ERC-4337 payload that describes intent for a smart account. Wallets sign UserOperations and submit them to a bundler, which validates and packages them into a single onchain transaction sent to the EntryPoint contract. The EntryPoint then drives execution against your account. Every step in that diagram is exposed as a typed action onStartaleAccountClient, which is the object returned by createSmartAccountClient.
What is a UserOperation, really
Where an EOA transaction is(to, value, data, signature), a UserOperation is (sender, nonce, callData, gasLimits, paymasterAndData, signature, ...). The extra fields unlock four things that EOAs cannot do:
- Custom signature validation. Any module installed as a validator can decide whether the signature is valid, so you are not bound to a single ECDSA key.
- Gas sponsorship and token gas. A paymaster can co-sign the UserOp to pay gas on the user’s behalf, or to accept an ERC-20 token as payment.
- Batched execution. A single UserOp can carry multiple calls and they all succeed or revert together.
- Programmable execution. Modules hook into the validation and execution flow of every UserOp.
How modules hook into the execution flow
Startale smart accounts implement ERC-7579, which defines a small contract surface for plugging in independent modules. When a UserOperation reaches your account, it walks through this pipeline:| Module type | What it controls | Examples |
|---|---|---|
| Validator | Decides whether a signature is valid for this UserOp. | ECDSA validator, Smart Sessions validator, Social Recovery validator |
| Prevalidation hook | Runs before the validator and can short-circuit validation. | Spending limits, rate limits |
| Hook | Runs around every execution to enforce invariants. | Allowlists, transfer caps |
| Executor | Triggers calls on behalf of the account, outside of the validator path. | Scheduled transfers, automated strategies |
| Fallback | Handles arbitrary function selectors that the account does not implement. | Token receivers, callback adapters |
toStartaleSmartAccount accepts each of these as a parameter (validators, prevalidationHooks, hook, executors, fallbacks), and StartaleAccountClient exposes ERC-7579 actions (installModule, uninstallModule, isModuleInstalled, getInstalledValidators, getInstalledExecutors, getActiveHook) so you can install or remove modules at runtime.
What you can build
The SDK and modular account together give you a small but powerful set of primitives. Everything below is a first-class capability of@startale-scs/aa-sdk:
Sponsored transactions
Pay gas for your users via a managed or self-funded SCS paymaster, with optional gas policies that scope sponsorship by user, contract, or rate limit.
ERC-20 gas payment
Let users pay gas in ASTR, USDC, or other supported tokens through the Startale Token Paymaster. Quote tokens with
getTokenPaymasterQuotes.Batched and parallel calls
Send multiple contract calls atomically in one UserOperation, or use two-dimensional nonces to run independent UserOps in parallel.
Smart sessions
Issue scoped, time-bound session keys so users do not have to re-sign every action. Backed by the Smart Sessions validator module.
Social recovery
Add an ERC-7579 recovery module that lets a guardian set with a configurable threshold rotate the account’s signer.
EIP-7702 delegation
Upgrade an existing EOA into a Startale Smart Account without changing the address, then use it like any other modular account.
SCS infrastructure
The SDK alone is not enough to send a UserOperation onchain; you also need a bundler and a paymaster. SCS hosts both behind a single API key issued from the SCS Portal, so you do not need to operate them yourself.| Component | What it does | SDK entry point |
|---|---|---|
| Bundler RPC | Receives signed UserOperations, validates and simulates them, and submits handleOps transactions to the EntryPoint. | transport: http(BUNDLER_URL) on createSmartAccountClient |
| Paymaster RPC | Returns paymaster data for sponsored or ERC-20 UserOperations, and exposes token quote endpoints. | createSCSPaymasterClient({ transport: http(PAYMASTER_URL) }) |
| Onchain contracts | The deployed EntryPoint, account implementation, factory, paymasters, and validator modules used by the SDK. | See Contracts and audits. |
Paymaster models
SCS exposes two paymaster modes from the same RPC. Both pass apaymasterId through paymasterContext; the difference is who issues the id and how it is funded.
| Mode | Funding | Who passes the paymasterId | When to use it |
|---|---|---|---|
| Self-funded (prepaid) | You top up an ETH balance on the paymaster contract; gas is debited from that balance. | You pass your own paymasterId from the client. | Predictable budgets, dapps that want to cap their own exposure. |
| Managed (postpaid) | SCS fronts gas and bills you in fiat on a monthly cycle. | Your paymasterId is issued in the SCS Portal and used the same way. | Production apps that prefer billing over treasury management. |
paymasterId for token:
Where to go next
Quickstart
Send your first UserOperation in a single Node.js script.
Portal setup
Provision an API key, create a paymaster, and set gas policies.
Installation
Install dependencies and choose a signer for any framework.
Smart account setup
Create the account, wire up the client, and persist it across renders.