Modular Accounts (MSA) at Haust Network: A Game Changer for Web3
Last updated
Last updated
At Haust, we initially implemented, tested, and launched abstract accounts (AA) in our testnet. However, as we explored the long-term vision for our project, it became clear that the functionality of AAs simply wouldn’t be enough to support the dynamic growth and requirements we had in mind.
The difference might seem small if you assume that all the necessary functions and use cases can be predicted during the initial project phase. But when a project plans to leverage AI agents as actively as we do, and these agents evolve rapidly every few months, it’s impossible to predict every possible scenario. Therefore, the traditional abstract accounts (AA) model becomes insufficient.
Previously, adding any extra feature to a wallet — such as multisig, session access, or social recovery — required separate implementation or even a new contract for generating a new abstract account.
But with Modular Accounts (MSA), this functionality can be simply “plugged in” as a module.
MSA is like a wallet with customizable settings, where each feature can be added, removed, or replaced without deploying new smart contracts, meaning no new address creation or asset transfer is necessary.
The account is like a “constructor,” where each module handles a specific task:
1️⃣ Transaction validation
2️⃣ Role and permissions distribution
3️⃣ Support for multisig or biometrics
4️⃣ Built-in limits for tokens or transaction volumes
5️⃣ Specific actions for GameFi or DAO participation
For us, as a project, this is crucial because it allows us to evolve iteratively, gradually adding more and more features for our users.
🔒 In the context of security, we can integrate two-factor authentication, biometrics, social recovery, or any combination of these features — which is exactly what we plan to do.
🗳 In governance, we can enable things like delegating one’s vote, creating a "representative democracy" for one or all subsequent decisions, adaptive voting depending on the subject, or setting vote limits per user.
💼 In the corporate segment, we can use it to segment permissions within a corporate account — one corporate account, but with different functions implemented by different external addresses: accountant, operator, C-level executive.
🤖 But most importantly, for us, MSA facilitates integration with AI agents. Personally, I’m not yet ready to hand over control of my account to an agent, and I think most aren’t either. But what about giving an agent limited authority, just for a predefined amount or for specific actions? Now that’s a different story.
For example: If the price of an asset reaches a certain threshold, the agent could take out a loan from the lending protocol for a specific amount, provide it as liquidity to a DEX, and buy an option as insurance. Such a complex action can only be executed through an agent with the right to do exactly that — and nothing more — at the blockchain level. No asset withdrawals, no sequence violations, no partial executions.
The most important thing is that the user won’t notice all this complexity. It will simply “just work” as it should.
⚙️ How It Works Under the Hood:
The ERC-7579 standard sets the rules for modular accounts. Each account has three interfaces — for logic calls, configuration management, and module interaction. Instead of numerous functions, a universal mechanism (execute(mode, calldata)) is used, where mode dictates how to process the call (single, batch, delegatecall, etc.).
Modules are divided into four categories:
Validation (signature verification)
Execution (action logic)
Hooks (pre/post-execution processing)
Fallback (support for non-standard calls)
Ultimately, MSA surpasses AA in the same way the IBM PC surpassed the Macintosh. They unlock new possibilities:
➡️ For users — more control and convenience
➡️ For developers — flexibility, updates, and reusability
These are the architectural approaches Web3 needs to mature into a full-fledged technological ecosystem. And it is with this approach that we are building Haust Network.
Written by Andrew Nalichaev (CTO at Haust Network).