Ngena , i-akhawunti ye-smart yasungulwa futhi i-UserOperation yokuqala yasungulwa ngempumelelo ngokusebenzisa i-EntryPoint. Kule isikhathi, yonke into asebenza - kodwa ingxenye ebalulekile yekhwalithi litholakala kakhulu: i-bundler. Indawo 1 I-Bundlers iyinhlanganisela phakathi kwe-akhawunti ye-abstraction ne-Ethereum execution layer. Zihlola i-UserOperations kusuka ku-meppool eyahlukile, zitholele izindleko ze-gas ngokushesha, futhi zitholwe nge-protocol. Ukuphathelela indlela yokusebenza - izinsizakalo zokuvumelana, uhlelo lokuthumela, kanye nezincwadi zezimali - kubalulekile ukulungiselela imibuzo nokwakha izinhlelo zokusebenza ezinhle. I-UserOperation Lifecycle I-UserOperation iyinhlangano yokusebenza kwe-work bundlers. I-encapsulates konke okwenziwe ekusebenzeni isinyathelo esekelwe ku-akhawunti ye-smart - ukulawula, ukucindezeleka kwe-gas, ukucindezeleka kwe-calldata, kanye ne-optional paymaster logic. Ngo-EntryPoint v0.8, i-UserOperations isebenza on-chain ku-packed, i-gas-optimized format. Xa usebenza nge-SDK njenge-permissionless.js, zihlanganiswa njengesakhiwo esifundeni, esifundeni: type UserOperation = { sender: Address nonce: bigint factory?: Address // Account factory (for first-time deployment) factoryData?: Hex // Factory calldata callData: Hex callGasLimit: bigint verificationGasLimit: bigint preVerificationGas: bigint maxFeePerGas: bigint maxPriorityFeePerGas: bigint paymaster?: Address paymasterVerificationGasLimit?: bigint paymasterPostOpGasLimit?: bigint paymasterData?: Hex signature: Hex } On-chain, i-EntryPoint isebenzisa ifomati ephakeme ye-gas efficiency (ukudibanisa izindlu ezifana ne-EntryPoint). ). I-SDK usebenza okuzenzakalelayo - akufanele ukunakekelwa. accountGasLimits = verificationGasLimit | callGasLimit The lifecycle of a UserOperation looks like this: Ukwakhiwa: Umdlali ukwakhiwa i-UserOp nge-smart account SDK yayo (njenge permissionless.js) Ukuhlasela: Umdlali uthumele i-UserOp hash, okwenza ukuthi wahlala isinyathelo Ukuhambisa: I-UserOp iyathunyelwa ku-bundler nge-eth_sendUserOperation Ukubuyekezwa: I-Bundler ibonise i-UserOp yokubuyekeza ukuthi uzothola imiphumela I-Mempool: Uma ivuliwe, i-UserOp ivumela i-mempool yebhanki I-Bundling: I-Bundler iphakethe i-UserOps eziningana ku-HandOps Single Call Ukusebenza: I-EntryPoint i-contract i-validates ngamunye we-UserOp on-chain, bese i-executes Ukudluliselwa: I-EntryPoint ikhiqiza izindleko ze-gas kusuka ku-akhawunti ye-akhawunti ye-PayMaster. Ukubuyekezwa kubaluleke ukuthi ukuvalwa kubaluleke amabili: uma off-chain ngu-bundler (ngokusho ukuba ukuthatha i-UserOp), futhi uma on-chain ngu-EntryPoint (ngemuva kokwenza ngokuvamile). Uma iziphumo ezimbili zithumela imiphumela eyahlukile, i-bundler ithatha imali-ukudlulisela igesi nge-transaction eyenza ekugcineni. Kuyinto asymmetry ukuthi izibambisane zihlanganisa ngokufanelekileyo. Zonke umugqa wokubhalisa kunazo ukunciphisa isigaba se-attack lapho i-UserOp isitimela kodwa isixazululo-on-chain. I-Validation: Yini i-Bundlers I-Paranoid I-Bundlers ibhalisele izindleko ze-gas ngokushesha. Uma i-UserOperation ibhalisele ku-chain ngemuva kokufaka ku-Bundle, ukulahleka kuyinto yayo. Akukho ama-refunds, akukho ama-retries. Kuyinto okuhlobene okuhlobisa inkqubo ephelele ye-Bundler Threat. Phakathi kwe-simulation ne-inclusion, isimo se-Ethereum akuyona enhle. Izinqubo ze-block zihlukile, izinga zihlukile zihlukile, kanye nezinsizakalo zangaphakathi. I-UserOperation eyenziwe ngokucacileyo ingakwazi ukufinyelela kwe-simulation ye-chain futhi akuyona ngempumelelo ngesikhathi se-on-chain validation - ukuguqulwa kwe-bundler ku-gas sink. I-ERC-4337 isibuyekeza ngokuvamile ngokuvimbela ukuthi ikhodi yokubhalisa iyatholakala ukwenza. I-EntryPoint inikeza ukuxazululwa okuqhubekayo kwezingxaki: : I-account's validateUserOp isebenza ukuhlola ukubhuka kanye nokuqinisekisa umsebenzi. Le phase inesibopho ezinzima ukuthi ama-opcodes kanye ne-storage ama-code angakwazi ukufinyelela. Validation Phase : I-execute function ye-akhawunti isebenza isebenze. Akukho ukunciphisa lapha—umthamo ephelele we-EVM. Execution Phase Ukukhishwa kwe-Opcodes Izinhlelo ezithile ze-opcodes zihlukile ngesikhathi sokubhalisa ngoba izinga zabo zihlukile phakathi kwe-simulation ne-execution: TIMESTAMP, NUMBER, COINBASE, PREVRANDAO: Izinzuzo ze-block-dependent. I-akhawunti ingathola ukuba (block.timestamp > deadline) ukuguqulwa, ukuguqulwa kwe-simulation, bese isizinda lapho i-buntle ibhekwa emkhakheni elandelayo. : Returns different values for different blocks. Same attack vector. BLOCKHASH I-GASPRICE, i-BASEFEE: Ukuguqulwa ngokuvumelana nezimo ze-network. , : Only allowed from staked entities (see Staking below) per ERC-7562 [OP-080]. BALANCE SELFBALANCE I-GASLIMIT, ORIGIN: Ingaba ingahlukile phakathi kwe-simulation environment ne-execution yayo. , : EIP-4844 blob-related opcodes that vary per block. BLOBHASH BLOBBASEFEE I-SELFDESTRUCT, INVALID: I-opcodes yokuvimbela ayikwazi ngesikhathi sokuvumelana. I-GAS: I-GAS ifumaneka kuphela uma i-INSTRUCTION ye-CALL-CALL, i-DELEGATECALL, i-STATICCALL, noma i-CALLCODE (umthengisi we-gas ekuthunyelwe kumazwe amaningi). CREATE: Ngokuvamile yasekelwe ngenxa yokwenza i-contracts kwi-address engathandayo. Nokho, CREATE ivumela i-sender contract lapho usebenzisa i-factory engathandwa. CREATE2 ivumela nje ngexesha lokusebenza kwe-sender contract. Ngiyazi ukuthi kusebenza lapho akhawunti yakho usebenzisa i-opcode eyenziwe: // This validateUserOp will be rejected by bundlers function validateUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds) external returns (uint256 validationData) { // BANNED: block.timestamp can change require(block.timestamp < deadline, "Expired"); // ... rest of validation } I-bundler isebenza umzila ngesikhathi sokusebenza kwe-simulation (ukusetshenziswa with an ERC-7562 compliant tracer) and rejects any UserOp whose validation touches banned opcodes. Modern bundlers may use either a JavaScript tracer or the native Go implementation introduced with EntryPoint v0.8. The RPC response will indicate which opcode caused the rejection. debug_traceCall Izinsizakalo zokufaka Ngaphandle kwe-opcodes, ama-bundlers zihlanganisa ukuthi i-slot ye-validation ye-code ye-storage angakwazi ukucacisa nokubhala. Iziqondiso (u-ERC-7562) zihlanganisa: can only access: Unstaked entities isitoreji yayo (isitoreji ye-akhawunti) I-Storage Slots eyenziwe "ngokuxhumana" ne-akhawunti ye-A, eyenziwe njenge: I-Slot Value kune-A, noma i-Keccak256 (I-A, I-A, I-X) + n lapho i-x iyona i-byte32 futhi i-n iyatholakala ku-interval kusuka ku-0 kuya ku-128 Ngokuvamile, lokhu kubalulekile ukuba idokhumenti yakho ungazifunda / zibhekele ku-mappings lapho idokhumenti ye-akhawunti kuyinto ikhoyili. Ngokwesibonelo, i-ERC-20 i-token ibhekwa i-balances ku-mapping efana ne-mapping. . I-storage slot ephelele kuyinto Uma idilesi lakho le-akhawunti kuyinto ikhoyili, le slot iye "ngezihlanganiswa" nawe. I-offset (0-128) inikeza ukufinyelela kumalungu we-struct eyenziwe ngemva kwe-mapping input - ezisebenzayo lapho izinga le-mapping kuyinto i-struct. mapping(address => uint256) balances keccak256(address || slot_of_mapping) +n (ama-akhawunti, ama-paymasters, noma ama-factories angama-deposit-in-EntryPoint) uthole ukunemba okwengeziwe: Staked entities Ungathola noma iyiphi i-slot ku-storage yayo (STO-031) Ungathola isitoreji esebenzayo se-entity ye-UserOp (STO-032) Kunzima ukufinyelela kuphela ukunakekelwa ku-storage ku-non-entity contracts (STO-033) See the full storage access rules in . ERC-7562 Why do these rules exist? Consider two UserOperations that read from the same storage slot during validation. If the first operation mutates that slot, the second operation’s validation assumptions may no longer hold. Ukunciphisa ukufinyelela kwe-storage ngesikhathi sokuqinisekisa, ama-paker angakwazi ukufinyelela ama-UserOperations amaningi ku-paket efanayo ngaphandle kokuphindaphinda kwe-cross-operation noma izixazululo ezingama-deterministic. I-Reputation System Ngezinye izinsizakalo zokuvumelana, izinsizakalo zingathola ngokufanele. I-akhawunti ingathumela UserOps ezivamile ezivela ku-simulation kodwa akufanele ku-on-chain ngenxa ye-state changes. A paymaster ingathola UserOps ngesikhathi ku-simulation kodwa akufanele ukulayishwa ku-chain. I-Bundlers ithatha izakhi zayo nge-a Ukuze ngamunye entity (ukudluliselwa ibhizinisi, paymaster idilesi, ibhizinisi ibhizinisi), i bundler ibhizinisi: reputation system opsSeen: Ukulinganiswa kwe-UserOps eziningana ne-entity etholakalayo opsIncluded: Ngaphezulu kwezinhlayiyana ezifakwe ku-on-chain The reputation status is determined by slack-based thresholds (defined in c) Izinzuzo UKUSEBENZA 7562 maxSeen = opsSeen / MIN_INCLUSION_RATE_DENOMINATOR (10 for bundlers) status = BANNED if maxSeen > opsIncluded + BAN_SLACK (50) status = THROTTLED if maxSeen > opsIncluded + THROTTLING_SLACK (10) status = OK otherwise Izici "slack" zihlanganisa ama-tolerance buffers ezivela ama-fake positives kusuka ku-operational variance evamile. I-entity ingaba ku-up to 10 more expected-inclusions than actual-inclusions before being throttled. Ukubonisa ukuthi ezinye I-UserOps zithembisa (izimo ze-network, izimo ze-race) ngaphandle kokubonisa umzimba we-malware. THROTTLING_SLACK = 10 BAN_SLACK = 50 Uma entity kuyinto I-Bundler ivimbele inani le-UserOps kusuka ku-entity efanayo ingatholakala ku-meppool. Uma , all UserOps involving that entity are rejected immediately. throttled banned Staking Entities can improve their standing by staking ETH in the EntryPoint contract: entryPoint.addStake{ value: 1 ether }(unstakeDelaySec); I-stake ayinambuzane-on kuphela i-locked. Kodwa inikeza ukuxhaswa nokuphendula: Izinsizakalo zokufaka ukufinyelela ku-storage (njenge-described above) Imininingwane ephakeme Izingubo ze-Reputation engaphezulu Ukuze paymasters nezimboni, ikakhulukazi, ukuhambisa kubalulekile ekukhiqizeni ukusetshenziswa. Ngaphandle kwalokho, i-UserOp eyodwa esihambayo kungase ngokushesha ukuthatha isebenze. I-Meppool ye-canonical inikeza (I-chain-specific, ngokuvamile i-1 ETH noma i-equivalent) futhi of 86400 seconds (1 day). The exact stake amount varies by chain and is defined in the mempool metadata—check the bundler documentation for your target network. MIN_STAKE_VALUE MIN_UNSTAKE_DELAY Umkhakha weGas I-Bundlers iyatholakala. Zihlanganisa izindleko ze-gas ukuze zithumela ama-Bundles futhi zihlanganiswe kusuka ku-UserOps etholakalayo. I-economics isebenza nangokunye: Umhlahlandlela we-Bundler Revenue = Σ (each UserOp's payment to beneficiary) Cost = Gas used × Gas price paid for handleOps tx Profit = Revenue - Cost Konke UserOp inikeza ngokuvumelana nokusetshenziswa kwegesi yayo kanye nemikhiqizo yegesi ithi: Payment = (actualGasUsed + preVerificationGas) × min(maxFeePerGas, baseFee + maxPriorityFeePerGas) I-Bundler ibeka i- Ikheli ku Khetha ukuthatha izindleko zayo. beneficiary handleOps preVerificationGas Explained Waze Izindleko ze-field zihlanganisa ezingenalutho ezingenalutho: preVerificationGas : 16 gas per non-zero byte, 4 gas per zero byte Calldata cost I-Bundle Overhead: Izindleko ezivamile ngamakhasimende ye-HandleOps ezivela ku-UserOps Imali ye-L2 ye-data: Ngama-L2s njenge-Optimism noma i-Arbitrum, ukulayisha i-calldata ku-L1 kunezinto ezengeziwe When estimating gas, bundlers calculate preVerificationGas based on the UserOp's size: // Simplified preVerificationGas calculation const calldataCost = userOpBytes.reduce((sum, byte) => sum + (byte === 0 ? 4n : 16n), 0n ); const overhead = 38000n; // ~21000 tx base + ~10000 bundle overhead + ~7000 per-op preVerificationGas = calldataCost + overhead + l2DataFee; Overhead values vary by bundler. For reference, Alto uses Ngena ngemva Ngena ngemva . Always use rather than hardcoding. transactionGasStipend: 21000 fixedGasOverhead: 9830 perUserOp: 7260 eth_estimateUserOperationGas Ukukhishwa kwe-Gas Unused Ukuze ukunciphisa abasebenzisi abalandeli okusheshayo kwe-gas (eyenza indawo ye-block), i-EntryPoint ibonise i-penalty ye-execution gas eyenziwe. Ngokuphathelene, inkinobho ifakwe ku- (Ukuveliswa kwe-akhawunti) futhi (for paymaster post-operations): callGasLimit paymasterPostOpGasLimit If unused gas in either field exceeds (40,000), the account pays 10% ( ) of the unused amount (does NOT apply to or ) PENALTY_GAS_THRESHOLD UNUSED_GAS_PENALTY_PERCENT verificationGasLimit preVerificationGas Oku kutshintshisa ukulawula amazinga eliphezulu kakhulu yokusebenza "ngokuthi kulula" Uma ukhangela ama-gas estimation errors, ukhangela ukuba ama-limits yakho zihlanganisa. endpoint provides sensible defaults. eth_estimateUserOperationGas Izinzuzo ezivamile kanye ne-debugging When a UserOperation is rejected, the RPC error is the only signal you get. Bundlers return structured error codes that explain exactly why the operation failed — but only if you know how to read them. AA1x: Factory Errors Lezi zihlanganisa lapho usebenza i-akhawunti entsha nge-factory. Ku-EntryPoint v0.8, ushiye Waze njengezindawo ezahlukile (i-EntryPoint ibhokisi ku internally): factory factoryData initCode AA10: "I-sender already constructed" - I-address ye-sender iyatholakala ikhodi. AA13: "initCode isixazululo noma OOG" - I-factory's createAccount isixazululo isixazululo noma isixazululo. AA14: "initCode must return sender" - I-factory ivumela idilesi eyahlukile kunesithombe. AA15: "initCode must create sender" - I-factory call eyakhelwe kodwa akuyona ikhodi ku-sender address. : Qaphela ukuthi ifektri yakho function returns the expected address. Verify the factory is deployed and funded. Debugging createAccount AA2x: Izinzuzo ze-akhawunti ze-validation The most common category: I-AA20: "i-akhawunti engathintela" - I-address ye-sender ayikho ikhodi futhi ayikho initCode eyakhiwe. I-AA21: "Hhayi i-prefund" - I-akhawunti ayikho i-ETH eningi yokubeka i-max possible gas cost. I-Fond ye-akhawunti noma usebenzisa i-paymaster. : "expired or not due" - The UserOp has a timestamp that has passed, or a timestamp that hasn't arrived yet. AA22 validUntil validAfter AA23: "ukuguqulwa" - I-validateUserOp function ye-akhawunti yasungulwa. Qinisekisa isicelo se-validation ye-akhawunti yakho. : "signature error" - The returned validation data indicates an invalid signature. AA24 AA25: "invalid account nonce" - I-nonce ayikho. I-nonce ku-ERC-4337 kuyinto i-value ye-256-bit enezinhloko ezimbili: i-nonce = (keyword << 64) i-node sequence. I-key (i-192 ibithi ephakeme) ibonise i-"lane" - ungenza i-UserOps eziningana nezinhloko eziningana. I-sequence (i-64 ibithi ephakeme) kufuneka ifakwe ngokulinganayo ngaphakathi kwelinye i-lane. Izinzuzo ezivamile: Reusing a nonce okuyinto xa kuhlanganiswe Using the wrong nonce key Another UserOp with the same sender is pending in the mempool : "over verificationGasLimit" - Account validation used more gas than allocated. Increase . AA26 verificationGasLimit AA3x: Izinzuzo ze-Paymaster : "paymaster not deployed" - The paymaster address has no code deployed. AA30 I-AA31: "I-paymaster deposit kakhulu" - I-paymaster's deposit ku-EntryPoint ayikwazi ukugcina izindleko ze-gas. entryPoint.depositTo{ umthamo: 1 ether }(paymasterAddress); : "paymaster expired or not due" - Similar to AA22, but for the paymaster's validation data. AA32 AA33: "paymaster reverted" - I-paymaster's validateI-PaymasterUserOp ifunyenwe. : "paymaster signature error" - Bad signature in the paymaster data. AA34 I-AA36: "Over paymasterVerificationGasLimit" - I-Paymaster Validation isetshenziselwa i-gas eningi kunezinto. Ukwandisa i-PaymasterVerificationGasLimit. Ukusebenza nge-Bundlers Izindlela ze-RPC Konke i-Bundler ye-ERC-4337 isebenza ngezindlela ezijwayelekile: : Submit a UserOp ukuze kuhlanganisa eth_sendUserOperation const userOpHash = await bundler.request({ method: 'eth_sendUserOperation', params: [userOp, entryPointAddress] }); : Thola izinga lokuphakama kwe-gas limit eth_estimateUserOperationGas const gasEstimate = await bundler.request({ method: 'eth_estimateUserOperationGas', params: [userOp, entryPointAddress] }); // Returns: { preVerificationGas, verificationGasLimit, callGasLimit, ... } : Look up a UserOp by its hash eth_getUserOperationByHash const userOp = await bundler.request({ method: 'eth_getUserOperationByHash', params: [userOpHash] }); : Thola i-receipt ngemuva kokufaka eth_getUserOperationReceipt const receipt = await bundler.request({ method: 'eth_getUserOperationReceipt', params: [userOpHash] }); // Returns: { success, actualGasUsed, receipt: { transactionHash, ... } } : Ukubuyekeza ukuthi Izinhlelo ze-EntryPoint ezisekelwe ku-Bundler eth_supportedEntryPoints const entryPoints = await bundler.request({ method: 'eth_supportedEntryPoints', params: [] }); // Returns: ['0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108'] The Shared Mempool Originally, each bundler maintained its own private mempool. This created problems: I-Censorship Risk: I-Bundler ye-UserOps ye-UserOps ye-UserOps I-Fragmentation: Abasebenzisi akufundisa ukuthi ama-buntlers abalandela : If your bundler went down, your UserOps were stuck Single points of failure The solution is the , a P2P network where bundlers gossip UserOps to each other. It works similarly to how Ethereum nodes gossip transactions: ERC-4337 shared mempool I-User submits i-UserOp ku-bundler ye-UserOp I-Bundler ivumela futhi ivumela ku-mppool yendawo I-Bundler broadcasts ku-peers ezihambelana Yonke bundler ku-network kungaba kuhlanganisa i-UserOp. The protocol uses libp2p for networking. Bundlers advertise which mempools they support (identified by IPFS CIDs that reference mempool metadata files), and only propagate UserOps that pass validation. For example, a mempool metadata file looks like: chainId: '1' entryPointContract: '0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108' description: Canonical ERC-4337 mempool for Ethereum Mainnet minimumStake: '1000000000000000000' The IPFS CID of this file becomes the mempool identifier used in P2P topic names. The mempool metadata defines validation rules: which opcodes are banned, storage access patterns, gas limits, and reputation thresholds. When a bundler receives a UserOp via P2P gossip, it re-validates against its own rules before adding to its local mempool. Advanced Topics Ukuhlobisa Signature verification is expensive on-chain. The ecrecover precompile costs 3,000 gas per call, but smart account signature verification typically costs more due to additional validation logic—often 6,000-10,000 gas total. For 100 UserOps in a bundle, that's 600,000+ gas just for signatures. Aggregators enable batch signature verification—verify all 100 signatures in a single operation for a fraction of the cost. What problem do aggregators solve? Instead of each account verifying its own signature, accounts can delegate to an aggregator contract. The aggregator implements a batch verification algorithm (like BLS signatures, where multiple signatures can be combined into one). How it works: Account's returns an aggregator address in its validation data validateUserOp Bundler groups all UserOps using the same aggregator Bundler calls once for the group aggregator.validateSignatures(userOps, aggregatedSignature) If verification passes, all UserOps in that group are considered valid : The return value from Ukupakisha amayunithi ezintathu ku-value ye-256-bit eyodwa: The validationData encoding validateUserOp validationData = uint160(aggregator) | // bits 0-159: aggregator address (uint256(validUntil) << 160) | // bits 160-207: expiration timestamp (uint256(validAfter) << 208) // bits 208-255: earliest valid time aggregator (i-bits 0-159): I-address ye-aggregator contract, noma ama-values ezizodwa: 0 = inkinobho olufanele, 1 = inkinobho olufanele validUntil (i-bits 160-207): I-timestamp lapho le UserOp ivuliwe (0 = akukho ukuhlaziywa) validAfter (i-bits 208-255): I-Timestamp ngaphambi kwe-UserOp ayikho (0 = iyahambisana ngqo) Ukucaciswa okuvumela i-akhawunti ukunqoba kanye ne-validation ye-signature kanye ne-time-limited ku-validity e-return eyodwa. Ukubuyekezwa Paymasters abstract gas payment from users. Instead of the account paying for gas, a paymaster can: : Pay on behalf of users (gasless UX) Sponsor transactions : Let users pay in stablecoins or other tokens Accept ERC-20 tokens : Rate limiting, subscription models, etc. Implement custom logic Ukusebenza kwe-validation flow ye-paymaster ngexesha le-validation phase: function validatePaymasterUserOp( PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost ) external returns (bytes memory context, uint256 validationData); Waze Kuhlolwe lapha Kuhlolwe lapha after execution completes, allowing the paymaster to perform final accounting (like charging an ERC-20 token): context postOp function postOp( PostOpMode mode, bytes calldata context, uint256 actualGasCost, uint256 actualUserOpFeePerGas ) external; Paymasters should be staked for production use. Staking provides relaxed storage access rules and better reputation—unstaked paymasters face strict limitations and can be quickly throttled by bundlers. While unstaked paymasters technically function with basic operations, staking is practically required for any serious paymaster implementation. can Ukuhlolwa Lokuposa This section assumes you have Anvil running with EntryPoint v0.8 deployed. We'll use , Pimlico's TypeScript bundler, and , a viem-based library for ERC-4337 interactions. Ngaphansi permissionless.js Ukubuyekeza Factory Kwi-Part I, sinikeza i-akhawunti ye-smart ephakeme. Kodwa kanjani abasebenzisi zithunyelwe? Abanikeze ukuxhumana okuzenzakalelayo — akukwazi ukuthola i-ETH ye-gas. I-ERC-4337 inikeza lokhu nge-factory contracts. For , the reference implementation includes . Ukusebenza ku-EntryPoint ngaphambi kokushesha izibonelo ezilandelayo. SimpleAccount SimpleAccountFactory Account Deployment via UserOp Uma i-EntryPoint ithatha i-UserOp nge-factory ne-factoryData fields: Checks if has code—if yes, skip deployment sender Calls factory.createAccount(owner, salt) nge factoryData Verifies the deployed address matches sender Continues with validation on the newly-deployed account Running Alto alto \ --rpc-url http://localhost:8545 \ --entrypoints 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 \ --executor-private-keys 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d \ --utility-private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \ --safe-mode false \ --api-version v1,v2 \ --bundle-mode auto Key flags: --executor-private-keys: Key for submitting bundles (kufuneka abe ETH) --safe-mode false: I-Anvil ayikho i-JavaScript tracer yokubhalisa kwe-ERC-7562 ephelele : Accept both UserOp formats (v1 for 0.6, v2 for 0.7/0.8) --api-version v1,v2 Sending UserOperations with permissionless.js Install dependencies: npm install viem permissionless Step 1: Set up clients Thina ufuna amaklayenti ezintathu: omnye for reading chain state, omnye for bundler-specific RPCs, futhi omnye for smart account owner. import { http, createPublicClient, createWalletClient, parseEther } from "viem" import { privateKeyToAccount } from "viem/accounts" import { foundry } from "viem/chains" import { toSimpleSmartAccount } from "permissionless/accounts" import { createSmartAccountClient } from "permissionless/clients" import { createPimlicoClient } from "permissionless/clients/pimlico" const ENTRYPOINT = "0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108" const publicClient = createPublicClient({ chain: foundry, transport: http("http://localhost:8545") }) const pimlicoClient = createPimlicoClient({ chain: foundry, transport: http("http://localhost:4337"), entryPoint: { address: ENTRYPOINT, version: "0.8" } }) const owner = privateKeyToAccount(process.env.PRIVATE_KEY) Waze isixhumanisi ne-Alto's RPC futhi inikeza ukucaciswa kwegesi nge . pimlicoClient pimlico_getUserOperationGasPrice Step 2: Create the smart account instance const simpleAccount = await toSimpleSmartAccount({ client: publicClient, owner, entryPoint: { address: ENTRYPOINT, version: "0.8" } }) const accountAddress = await simpleAccount.getAddress() console.log("Account:", accountAddress) This computes the counterfactual address using the factory's isicelo. I-akhawunti ayikho futhi - kodwa siphinde esifanele lapho kuyatholakala. getAddress Step 3: Fund the account I-akhawunti ye-smart inikeza i-ETH yokukhokha kwe-gas (noma usebenzisa i-paymaster). Sinikeza i-ETH ku-address ye-contrafactual: const walletClient = createWalletClient({ account: owner, chain: foundry, transport: http("http://localhost:8545") }) await walletClient.sendTransaction({ to: accountAddress, value: parseEther("1") }) The ETH sits at that address. When the account is deployed, it can access those funds immediately. Step 4: Create the smart account client const smartAccountClient = createSmartAccountClient({ client: publicClient, account: simpleAccount, bundlerTransport: http("http://localhost:4337"), userOperation: { estimateFeesPerGas: async () => (await pimlicoClient.getUserOperationGasPrice()).fast } }) The usebenzise UserOp ukwakhiwa, nonce ukulawula, gas ukubuyekeza, futhi ukubheka. The I-callback ikhiqiza izindleko zokusebenza ze-gas kusuka ku-bundler. smartAccountClient estimateFeesPerGas Step 5: Send a UserOperation const hash = await smartAccountClient.sendUserOperation({ calls: [{ to: "0xa0Ee7A142d267C1f36714E4a8F75612F20a79720", value: parseEther("0.01"), data: "0x" }] }) const receipt = await smartAccountClient.waitForUserOperationReceipt({ hash }) console.log("Success:", receipt.success) For the first UserOp, the SDK automatically includes Waze I-EntryPoint ivumela i-akhawunti, bese ivumela ukulayishwa — konke ku-transaction eyodwa. factory factoryData Yini sifundile Bundlers are the execution layer of ERC-4337. They are what turns Account Abstraction from a specification into a production-ready mechanism. Ukuphathelene izinzuzo zabo - izicelo zokubhalisa, imikhiqizo yokuzonwabisa, kanye ne-reputation mechanics - kubalulekile ekuklanyeni ama-accounts emangalisayo. Imibuzo lapha akuyona ku-Solidity code, kodwa emzimbeni we-Mepool, ama-simulations, ne-execution economics. I-ERC-4337 ivimbela ukucindezeleka kusuka ku-protocol futhi ku-infrastructure. Uma izivakashi zihlala ngokushesha ngokuphathelene nezinhlangano, izinhlelo zayo ziye zikhuthazayo kakhulu ekukhiqizeni.
