> For the complete documentation index, see [llms.txt](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/smart-contracts/week-11-aa-erc-4337-and-smart-wallets-final.md).

# Week 11 : AA, ERC-4337 and Smart Wallets (Final)

This week wasn’t about learning account abstraction from scratch, it was more of a revision and consolidation week.

I’ve already worked through ERC-4337, UserOperations, bundlers, etc., but this time the focus was on making sure everything actually connects and makes sense as a full system.

<figure><img src="/files/jHZ9aAOXIkQKt6sHEfUA" alt=""><figcaption></figcaption></figure>

***

### 1. SDKs — what they actually are (and why I still care)

Even though I’ve seen SDKs before, they came up a lot again this week.

SDK = Software Development Kit.

The way I think about it:

* It’s a toolbox I use so I don’t rebuild everything from scratch.

Without it:

* I’d manually construct transactions
* handle signatures
* deal with gas + bundlers
* manage edge cases

With it:

* wallet connection is simple
* transactions are abstracted
* gas + bundler logic is handled
* I can implement gasless flows easily

So the trade-off is still:

* no SDK → more control, more complexity
* SDK → faster dev, fewer mistakes

***

### 2. Signature validation — more flexible than EOAs

With EOAs:

* one private key
* one signature method (ECDSA)

Smart wallets remove that limitation.

Now validation can be:

* **ECDSA** → standard
* **multi-sig** → multiple approvals
* **Schnorr / BLS** → efficient multi-signatures
* **passkeys (WebAuthn)** → biometrics

What stuck with me again:

* Passkeys remove the need for seed phrases, which is a huge UX improvement.

***

#### Social recovery

Instead of losing everything if access is lost:

* guardians can help recover access

Flow:

* assign trusted guardians
* majority can reset access

Trade-off:

* guardians could collude

So:

* diversify guardians
* don’t rely on a single trust group

***

### 3. Session keys, permissions, factories

#### Session keys — fixing UX

Without session keys:

* every action = user approval

That doesn’t scale.

Session keys act like:

* a temporary, restricted key given to an app.

They:

* limit what contracts can be called
* limit spending
* expire after time
* can be revoked

***

#### Permission policies

Session keys are controlled by rules:

* contract restrictions
* spending caps
* expiry
* whitelists

So access is controlled, not open-ended.

***

#### Factories + CREATE2

This is still one of the most important concepts.

Normally:

* deploy → then know address

With CREATE2:

* address is known before deployment

Inputs:

* factory address
* salt
* bytecode

Because it’s deterministic, the result is predictable.

***

#### Counterfactual wallets

Key idea:

* The wallet address exists before the contract is deployed.

So:

* funds can be sent before deployment
* contract later “appears” at that address

***

### 4. Bundlers — core to ERC-4337

#### What a bundler is

In ERC-4337:

* no direct transactions
* only UserOperations

Bundler handles execution.

***

#### What it actually does

Steps:

1. receives UserOps
2. simulates them
3. selects valid/profitable ones
4. bundles them
5. sends `handleOps()` transaction
6. gets paid

Important:

> Bundler pays gas upfront → must avoid failed ops.

***

#### Bundler economics

Bundlers only operate if profitable:

> (user fees + MEV) > (costs)

So:

* low gas → ignored UserOp

***

#### RPC methods (bundler-specific)

These only exist because of ERC-4337:

* `eth_sendUserOperation`
* `eth_estimateUserOperationGas`
* `eth_getUserOperationByHash`
* `eth_getUserOperationReceipt`

Standard nodes don’t support these.

***

#### Attacks on bundlers

Because they pay gas:

* gas griefing
* spam attacks
* front-running
* storage conflicts

Defences:

* simulation
* rate limiting
* reputation systems

***

### 5. Security — main risks

Smart wallets increase flexibility, but also attack surface.

#### Key vulnerabilities

**Signature not validated**

* anyone can execute
* fix → always verify

**Replay attacks**

* same op reused
* fix → nonce

**Authorisation issues**

* unrestricted execute()
* fix → only EntryPoint

**Reentrancy**

* unexpected callbacks
* fix → proper execution order + guards

***

#### Paymaster risks

* no limits → drained funds
* wrong timing (charging too early)
* no replay protection
* inefficient storage

Fixes:

* limits
* postOp charging
* proper validation

***

#### Cross-chain replay

Same wallet across chains = risk.

Fix:

> include chain ID in signed data

***

#### My checklist

Before deployment:

* signature validation
* nonce correctness
* EntryPoint-only execution
* reentrancy protection
* chain ID included
* paymaster limits

***

### 6. How everything connects

Full flow:

1. user initiates action
2. app builds UserOperation
3. operation is signed
4. optional paymaster added
5. sent to bundler
6. bundler validates + queues
7. bundler sends `handleOps()`
8. EntryPoint processes
9. smart wallet executes
10. fees settled

***

### 7. SDKs in practice

What SDKs give me:

* **Alchemy** → easiest setup + built-in paymaster
* **Biconomy** → strong multi-chain + gaming UX
* **ZeroDev** → customizable plugins
* **Pimlico** → fast + flexible tooling

How I think about choosing:

* simplicity → Alchemy
* UX/multi-chain → Biconomy
* custom logic → ZeroDev
* performance → Pimlico

***