Background

In order to support these new RWAfi use cases, we explored various concepts that were specifically tied to the notion of yield as a first-class citizen, using custom precompiles on top of our existing stack to add explicit functionality that would support various ways that users could interact with yield. These initial explorations were useful for creating a proof-of-concept that allowed yield to be freely combined, divided, etc. between users and smart contracts but we soon realized that the same concepts we were building that specifically allowed users to interact with yield could be extended to allow users to interact with any real-world concept, however they want.

Therefore, we came up with the revolutionary technical innovation of making custom modifications to go-ethereum ("geth") that support native account abstraction using the concept of "smart wallets". Unlike existing account abstraction solutions, which give users a separate "smart account" with code controlled by third-party AA wallet providers, Plume is the only chain with smart wallets that store custom code directly in the existing storage of each EOA. Users have full control over what code they want to store and any custom extensions they want to install to support new features. This includes all functionality covered by existing account abstraction frameworks, such as gasless transactions, batched transactions, and automated transactions, but baked directly into the chain rather than added on as an afterthought like the ERC-4337 implementation.

If you look at a diagram of the current state of account abstraction, there are a small number of centralized providers like Biconomy and Etherspot that dominate the market. This is because ERC-4337 was designed to be implemented on top of Ethereum without needing any changes that would require a hard fork, so there has to be a new area to aggregate pending UserOperations (the "alt mempool") where all the infrastructure with proposer-builder separation and MEV must be redeployed but to a smaller subset of transactions given the limited adoption of account abstraction enabled wallets.

This is a clunky and over-complicated system that is not necessary in a new chain where account abstraction can be implemented directly in the execution client from genesis. Rather than using the storage of smart contracts that have no relationship to the EOA that relies on them for their account abstraction functionality, we use the storage of the EOA directly so that you can upgrade your smart wallet with any extensions you like, then wrap your EOA address in the appropriate interface to call the corresponding code. This avoids the need for an alt mempool entirely as we can completely rely on the existing execution client to execute the smart wallet instructions deterministically, and the resulting transactions are sent sequentially to the Plume sequencer. We chose to make these custom modifications on go-ethereum ("geth"), the most popular Ethereum client, with over 45% market share on Ethereum mainnet. All of the code is currently being audited by Trail of Bits, the main auditor for the core Arbitrum codebase.

Imagine that you are the user that owns the smart wallet in the diagram below—your EOA's wallet address is 0x01, and your smart wallet's address is also 0x01. The technical details for the flow of control is:

1. Any EOA ("initiator") can initiate a transaction to the smart wallet (0x01)

   1. Either directly;

   2. Or by calling a contract, which then calls the smart wallet; the actual contents of the transaction could come from another smart wallet too

2. Plume's custom implementation of geth detects that this is a call to a smart wallet, so it loads and executes the code in the hardcoded address (0xFE) of the immutable WalletProxy contract

   1. We decided not to build in functionality to access the storage of the WalletProxy contract as it introduces additional surface area for attack vectors, which means we can only read the code from WalletProxy and not its storage

3. The WalletProxy contract is a proxy that stores a single public immutable constant, which is the hardcoded address (0xFF) of the WalletFactory contract

   1. The address of the WalletFactory must be immutable so that we can read it directly from the deployed bytecode as we cannot read from the WalletProxy storage

   2. The WalletProxy code is executed with a delegatecall to WalletFactory

4. The WalletFactory contract is a proxy that stores the implementation of the PlumeWallet framework in its storage (0xFF)

   1. The WalletFactory code is executed with a delegatecall to PlumeWallet

5. The PlumeWallet contract is a proxy that stores the custom implementation of the smart wallet in the user's storage (0x01)

   1. The PlumeWallet code is executed with a delegatecall to the user's implementation of their own smart wallet

6. The user (0x01) can upgrade their smart wallet implementation with custom extensions whenever they want

7. The Plume Foundation multisig (0xE1..97) can upgrade the PlumeWallet implementation following a formal governance vote

As an example of how this genericized framework applies to more than just the concept of yield, we demonstrate a vastly simpler flow for the archetypal use case for account abstraction—sponsored or "gasless" transactions. One of the first custom extensions that we have built and will be available day one on mainnet is the ability for EOAs to sign EIP-712 compatible typed data which can then be sent to a paymaster for execution:

1. The user (0x01) constructs a bundle of typed data, formatted and signed according to EIP-712 compatible specs, and packaged into a list of SignedOperations

   1. This custom extension gives users the ability to bundle multiple transactions together, each represented by a single SignedOperation

   2. Each SignedOperation in Plume corresponds to a UserOperation in ERC-4337

2. The user sends these signed operations to a paymaster (0x0B), e.g. through an offchain API call

3. The paymaster calls executeSignedOperations on the smart wallet (0x01) and pays for the gas

   1. The user has their SignedOperations execute without doing any onchain transactions and without paying for any gas

Because the user (0x01) has full control over the code in their own smart wallet, they can define any set of custom hooks to execute before or after each SignedOperation, unlike traditional account abstraction approaches where the logic is handled by the AA wallet and not by the user themselves. The flexibility of allowing anyone to add any code into their smart wallets gives developers limitless potential to develop entirely new categories of applications like self-sovereign smart custody solutions, individualized automated trading strategies using onchain algorithms and oracles, chained smart wallet function calls, and more—all only possible due to Plume's custom modifications of geth.