> 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-7-account-abstraction-erc-4337-and-smart-wallets.md). # Week 7 : Account Abstraction, ERC-4337 and Smart Wallets(Introduction) #### UUPS Upgradable Multi-Signature Escrow Assessment * Starting the week on a high note. Today I wrote an assessment where I built a UUPS Upgradable Multi-Signature Escrow contract. It actually felt like everything we've been learning is starting to come together, especially around upgradeable contracts and how they apply in real world scenarios. * The escrow logic required both the buyer and seller to confirm before funds are released, which really helped me understand multi-party authorization better. I also worked on the dispute flow, where either party can escalate and an arbiter makes the final decision. Writing the `_authorizeUpgrade` function made me realise how important it is to properly secure upgrades, especially in UUPS where the upgrade logic lives in the implementation contract itself. * I wrote tests to cover the full flow, from deposits all the way to dispute resolution, and also tested upgrading to V2 while keeping the state intact. I did struggle a bit with the upgrade tests, specifically understanding how state is preserved and how the proxy interacts with the new implementation, but I'll keep working on that until it clicks. Deploying to Sepolia and interacting with the contract on Etherscan made everything feel more real, like this is actual production type work. *** #### Introduction to Account Abstraction and ERC-4337 **What is Account Abstraction?** To understand why Account Abstraction exists, you first have to think about the limitations of a normal Ethereum wallet, also called an EOA or Externally Owned Account. EOAs are very rigid. You need a seed phrase or private key to access your wallet, you have to manually approve every single transaction, you can only send one transaction at a time, and you always have to pay gas fees yourself. If you lose your private key, your wallet is gone forever with no way to recover it. Account Abstraction is the idea of removing those strict rules and replacing them with something more flexible and user friendly. Instead of needing a seed phrase, you could set up a wallet with just your Gmail or phone number. Instead of always paying gas yourself, a paymaster can cover your fees. Instead of losing everything if you lose your key, you can set up social recovery, where trusted people or devices can help you regain access. **Why Did Previous EIPs Fail?** The idea of Account Abstraction is not new. There were earlier EIPs that tried to make it happen, but they all failed for the same reason. They tried to change Ethereum's core protocol, the fundamental rules that govern how transactions are validated and processed at the network level. Changing the core protocol requires consensus from the entire Ethereum network and risks breaking things that already work. Those proposals never made it through. **Why ERC-4337 Was Approved** ERC-4337 took a completely different approach. Instead of changing the core protocol, it built on top of Ethereum using an alternative mempool and smart contracts. A mempool is where transactions wait before being added to the blockchain, and ERC-4337 creates a separate one just for smart wallet transactions. This meant no core protocol changes were needed, which is why it was finally approved. It introduced four key components: * **UserOperation** - a pseudo transaction that describes what the user wants to do. * **Bundler** - a node that collects UserOperations and submits them to the blockchain. * **EntryPoint** - the single smart contract that all UserOperations must pass through. * **Paymaster** - an optional contract that can cover gas fees on behalf of the user if certain conditions are met. *** #### Improving the Voting System With a Frontend * Today I worked on improving the voting system we started at ABC. The goal was to add time-based voting sessions, make it upgradeable using the skills we learned over the past few weeks, and build a proper frontend interface for it. * I deployed VotingV1 with basic voting functionality, then upgraded to VotingV2 using the UUPS proxy pattern. V2 added `duration` and `startTime` state variables to enforce time-limited voting periods. The contract now only allows votes during an active session and displays the winner after voting ends. I adjusted the `__gap` from `uint256[50]` to `uint256[48]` to make room for the two new state variables and avoid storage collisions. * The frontend was built with Next.js and includes a connect wallet button, a live countdown timer that updates every second, and conditional rendering based on the voting state. While voting is active, users see clickable options with current vote counts. When time expires the UI automatically switches to display the winner and final results. Building a frontend that talks directly to a smart contract was something I hadn't done properly before, and seeing the wallet, contract and UI all working together felt like a big step forward. **Deployment Details:** Proxy Address: `0x641f8474953E6b1Df07aD198262bf5775347De49` **Updated Functionality:** * Time-Based Sessions: Voting limited to a specified duration in minutes. * Restart Voting: Owner can start new sessions without redeploying. * Live Countdown: Frontend displays a real-time timer. * Automatic Winner Display: UI switches when voting ends. **GitHub Repository:** * ***