> ## 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.
# Introduction
> Account abstraction fundamentals, the SCS infrastructure stack, and the Startale modular account model.
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](https://eips.ethereum.org/EIPS/eip-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.
## 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.
```mermaid theme={null}
sequenceDiagram
autonumber
participant App as Your dApp
participant SA as Startale Smart Account
participant PM as SCS Paymaster
participant B as SCS Bundler
participant Signer
participant EP as EntryPoint v0.7
participant Chain as Soneium
App->>SA: prepare UserOperation (calls, nonce)
SA->>PM: getPaymasterStubData
PM-->>SA: stub paymasterAndData
SA->>B: eth_estimateUserOperationGas
B-->>SA: gas limits
SA->>PM: getPaymasterData
PM-->>SA: paymasterAndData
SA->>Signer: request signature on populated UserOp
Signer-->>SA: signed UserOp
SA->>B: eth_sendUserOperation
B->>EP: handleOps([userOp])
EP->>Chain: validate + execute
Chain-->>App: UserOperationEvent
```
Every step in that diagram is exposed as a typed action on `StartaleAccountClient`, 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](https://eips.ethereum.org/EIPS/eip-7579), which defines a small contract surface for plugging in independent modules. When a UserOperation reaches your account, it walks through this pipeline:
```mermaid theme={null}
flowchart LR
UO[UserOperation] --> V[Validators]
V --> PH[Prevalidation hooks]
PH --> EX[Execution]
EX --> H[Hook]
EX --> EXEC[Executors]
EX --> FB[Fallbacks]
```
| 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`:
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.
Let users pay gas in ASTR, USDC, or other supported tokens through the Startale Token Paymaster. Quote tokens with `getTokenPaymasterQuotes`.
Send multiple contract calls atomically in one UserOperation, or use two-dimensional nonces to run independent UserOps in parallel.
Issue scoped, time-bound session keys so users do not have to re-sign every action. Backed by the Smart Sessions validator module.
Add an ERC-7579 recovery module that lets a guardian set with a configurable threshold rotate the account's signer.
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](https://scs.startale.com), 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](/aa-sdk/resources/contracts-and-audits). |
## Paymaster models
SCS exposes two paymaster modes from the same RPC. Both pass a `paymasterId` 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. |
In both modes, the call site looks the same:
```ts theme={null}
paymasterContext: {
paymasterId: "",
}
```
For ERC-20 gas payment, swap `paymasterId` for `token`:
```ts theme={null}
paymasterContext: {
token: "",
}
```
The full list of supported tokens per network is in [Supported networks](/aa-sdk/resources/supported-networks).
## Where to go next
Send your first UserOperation in a single Node.js script.
Provision an API key, create a paymaster, and set gas policies.
Install dependencies and choose a signer for any framework.
Create the account, wire up the client, and persist it across renders.