In this edition of our ongoing tech series we will take a look at the Mass Smart Account (MSA). The Mass Smart Account is the glue that holds the Mass app together, while also providing advanced Account Abstraction features.

Interacting with apps directly with your EOA (Externally Owned Account) wallet is hurting the UX of DeFi. Not only is it time-consuming and dangerous, but the scope of what is possible has long since been reached. Two of the biggest pain points we see are:

• Approving and disapproving spending amounts. These actions are time-consuming and can lead to a dramatic and permanent loss of funds.
• Not being able to batch transactions, or said differently, execute multiple operations in one atomic signature.

To make Mass as flexible and limitless as possible, we have created the Mass Smart Account, which, coupled with the HyVM, gives our users an infinite scope of actions.

An MSA is what you will need to interact with all protocols and services on the Mass app. Don't worry, we take care of this for you: your MSA will be created the first time you interact with Mass, and you won't even notice it!

Basics:

• Your MSA is a smart contract.
• Your MSA acts as storage. All funds you deposit on Mass are stored in your MSA.
• Your EOA/wallet owns your MSA.
• You can create multiple MSAs attached to a single EOA/wallet by calling the SmartAccountFactory contract; users can create an infinite number of MSAs. While it is possible at the protocol level, we did not authorize it from our web/mobile app.
• Your EOA/wallet serves as a point of access to Mass. You will sign transactions and fund your MSA through your EOA/wallet.
• Your MSA has an address on the blockchain: by sending funds from your wallet to this address, you're sending funds to your MSA. This address is different from the address of your EOA/wallet.

Now let's dive further into the details and specifications that make the MSA so unique!

Multiple Networks - One MSA Address

Do you remember the sad story that happened to Wintermute and the Optimism Foundation?

Wintermute provided an address to receive $OP tokens. The Optimism Foundation sent the funds. Unfortunately, Wintermute later discovered they could not access these tokens because they had provided an address for an Ethereum (L1) Safe multi-sig that they had not yet deployed to Optimism (L2) => $20M of loss.

When you deploy a multi-sig on Safe, you must be careful as the address attached to this multi-sig is valid only on the network you created it. If you deploy a multi-sig on Ethereum and send funds to this address on Arbitrum thinking it acts like your Metamask wallet, you will send your funds into the abyss and they will be permanently lost.

On Mass, you don't have to worry about this. Your MSA will always have the same address, whatever the EVM-compatible network you're deploying.

At Mass, we pre-compute MSA addresses by providing a bytes32 salt value as an input during the creation of the MSA. The salt is used in the CREATE2 process to ensure the uniqueness of the smart account address.

CREATE2

The whole idea behind CREATE2 is to make the resulting address independent of future events. Regardless of what may happen on the blockchain, deploying the contract at the precomputed address will always be possible.

New MSA addresses are a function of:

• The EOA/wallet that is deploying and will own the MSA.
• A salt (an arbitrary value provided by the EOA/wallet)
• The to-be-deployed contract’s bytecode. This can be seen as all of the recipes that will make the MSA unique. It corresponds to the rules and characteristics we want to give to the MSA.

A positive externality is that you can send funds to this address even if you have not deployed your MSA yet. Let's look at an example:

Alice has only used Mass on Optimism and so, only deployed an MSA on Optimism.

She wants to use Mass on Arbitrum and has to bridge funds, but has no MSA on Arbitrum yet. Does Alice need to deploy an MSA on Arbitrum before bridging? NO! Regardless of what may happen on Arbitrum, she will always be able to deploy an MSA at the precomputed address - which will be the same as on Optimism and any other EVM chains.

Nb: Some layer 2s apply address aliasing when doing L1 to L2 messaging. This needs to be taken into account when interacting with contracts and, more importantly, when creating a MassSmartAccount. Users should use the SmartAccountFactoryof the target chain instead of L1 to L2 Messaging. When using the Mass web/mobile dApp or our playground, users will not have to worry about this.

On-demand Upgradability

Contract upgradability breaks decentralization, in a sense. If you don’t have the choice to upgrade as a user, you're subject to the will of protocol developers without being able to do much about it. However, non-upgradable contracts can also be broken in various ways, as you might need flexibility at the early stage of a project. In addition, it is painful for users to migrate funds to new contracts every time a project needs to deploy a new version.

However, there is a middle ground: On-demand upgradability.

You being the sole owner of your MSA enables us to let you choose whether or not to upgrade.

You can choose to upgrade and benefit from the new features we develop as we deploy them. But you can also choose to not upgrade and stick with an older version, or even to switch to a completely new implementation that has not been written by us.

Your funds, your MSA, your choice.

This ensures that Mass cannot in any way fiddle with your ability to stay in control of your funds.

💡 MassSmartAccount and SmartAccountFactory are the two contracts we use that are upgradable.

Gasless

MassSmartAccount and SmartAccountFactory support the ERC-2771 standard, allowing meta-transactions through Trusted Forwarder Contracts. This allows the contracts to accept calls from externally owned accounts that do not have ETH to pay for gas.

Remember, your EOA/wallet is still the account signing all transactions, your MSA is merely the storage owned by your EOA/wallet.

In other terms, even if you don't own any gas tokens, your EOA will still be able to sign transactions, and funds stored in your MSA will be used to pay gas fees.

The HyVM: the Swiss army knife of execution

HyVM is an Ethereum Virtual Machine (EVM) Hypervisor written in Huff, allowing for the execution of arbitrary EVM Bytecode.

The HyVM acts as the execution operator and is the only contract that is authorized to be called in delegatecall.

What is a delegatecall?

Academic definition

delegatecall is a low-level Solidity opcode that allows a contract to execute code from another contract, however it uses the state (the account's balance in native token such as ETH on Ethereum) and the storage (every asset secured by the smart contract) of the calling contract.

Simple Definition

delegatecall is like asking a friend to do something for you, but your friend pretends to be you while doing it. Your friend can access your stuff and act on your behalf, but you have to trust your friend completely, as any mistakes or mischief they make will affect you directly. This is a powerful tool in blockchain, but it must be used carefully to avoid problems.

When we say: "The HyVM is the only contract that is authorized to be called in delegatecall."

This simply means the HyVM is the only contract that the MSA can call to perform actions. In exchange, the HyVM can use the storage and the state of the MSA and act on its behalf with the approval of the MSA's owner (you).

Your MSA equipped with the HyVM is like a Swiss army knife and is now the most flexible tool in DeFi.

To learn more about the HyVM and its role, you can read the thread below and the attached article:

Conclusion

We make sure to implement the latest and most useful cutting-edge EIP standards to make sure the MSA stays the most agile smart account known to DeFi.

To illustrate our commitment to staying up-to-date, we recently implemented EIP-1271.

Your EOA wallet can sign messages with its associated private keys, but smart contracts cannot. ERC-1271 is a standard way for any contract to verify whether a signature is valid on behalf of a given account. This means your MSA can now sign your limit orders on 1inch, TWAP orders on CowSwap, or any other intent-based transaction you throw at it. Your MSA will abstract away all of the signatures, finally giving DeFi the UX it deserves.