I am starting the research phase for this paper today, on December 1st 2024. I am applying for the Ethereum Foundation’s 2025 Software Engineering Internship, with a specific interest in improving Ethereum’s UX. Therefore, writing this paper will be an effective way to get an in-depth understanding of AA. I am already familiar with the concepts of ERC4337, including bundlers and entry-point contracts, paymasters and transaction sponsoring…

I will now go deeper, by reading EIPs 86, 101, 1613, 2771, 2938, 3074, 4337, 7701, 7702, RIP 7560 and other related sources.

“The goal with Account Abstraction has always been to solve the cross-chain UX problem” - Yoav Weiss

Account Abstraction (AA) involves three parts of a transaction flow:

1. Authorization Logic (how the transaction is approved)

2. Execution Logic (what the transaction does)

3. Fee Payment (how the validator is paid)

Following years of exploration with the EIPs described in this paper, EIP-4337 condenses the key goal of Account Abstraction into: allowing users to not have EOAs, and instead “use smart contract wallets containing arbitrary verification logic”. This is a technical, practical, operational view of the goal.

On the other hand, the normative end goal has always been to improve UX. Specifically, the three improvements listed in the Pros and Cons tables in this paper are:

• Signing UX

• Wallet Recovery

• Gas Payments

This can be further abstracted into the real final goals:

• Improving onboarding and usage friction by reducing the number of steps and concepts users need to understand when using dApps.

• Giving users peace of mind regarding fears of having their seed phrase lost or stolen.
  

EIP-4337 presented a clever way to address the UX goals of AA without the coordination effort and additional work required by infrastructure-layer changes. It can be seen as a workaround based on the constraint of avoiding consensus-layer changes.

Following EIP-4337, newer proposals push Native AA to the forefront. Native AA refers to embedding functionality into the infrastructure-layer, as opposed to aiming to address AA. RIP-7560 adopts many of the concepts from ERC-4337, but instead of relying on higher-layer infrastructure, it combines them with concepts from EIP-2938, thereby requiring consensus-layer protocol changes.

While this is the current state of collective brainstorming and development, to fully understand the problem being faced, one must look at the full history of AA, which began in 2015 and has seen many proposals since.

Before delving into the evolution of AA ideas brought forth, we must understand what transactions are and the traditional flow of transactions on Ethereum.

A transaction is a write operation - i.e. an action that alters the onchain state. There are two types of transactions on Ethereum: Ether transfers (from EOA to EOA) or function calls (from EOA to Contract).

The diagram below illustrates the standard transaction flow on Ethereum.

This section presents a comprehensive picture of the evolution of Account Abstraction, describing each relevant improvement proposal in a chronological order.

Each improvement proposal will have a table of pros and cons within a structured set of relevant categories:

• Signing UX

• Wallet recovery

• Gas payments

• Security

• Dev overhead

• Future proofing

• Validator incentives

• Implementation

Furthermore, similar to the transaction flow diagram above, each improvement proposal below will have a similar illustration depicting the difference under each approach. The colours yellow and blue represent proposals requiring, and not requiring, infrastructure-layer changes respectively.

https://eips.ethereum.org/EIPS/eip-101

EIP-101 redefines EOAs to no longer store Ether, i.e. only store code and storage. Transactions are simplified to include only the recipient, gas limit, data, and optional code for contract creation, eliminating fields like msg.value.

Ether is instead managed by a unique premined contract at address 0, which handles transfers and balances for all accounts.

https://eips.ethereum.org/EIPS/eip-86

EIP-86 introduces the idea of abstracting transaction origin (who sent it) and signature validation (how it’s authorized), or in other words, “abstracting account security”

It also introduces the CREATE2 opcode, for deterministic contract creation. Although EIP-86 was never implemented, CREATE2 was later re-proposed and finalized as EIP-1014 and introduced in the Constantinople upgrade (February 2019).

*Ethereum was still running Proof of Work at the time of this proposal, hence the miners

https://eips.ethereum.org/EIPS/eip-1613

EIP-1613 proposes the Gas Stations Network (GSN), a decentralised offchain network of relayers, which enables users to make “collect calls”, i.e. transactions paid for by the recipient.

The relayers pay the gas fee upfront and then get reimbursed by the receiver contract (can’t be an EOA). A singleton contract RelayHub manages relayers, ensuring their authorization and reputation, and handles reimbursements.

https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020

This proposed scheme builds on the concept of account abstraction by introducing a two-step process for transaction validation: lightweight verification and execution. This approach allows for custom account logic while maintaining network efficiency and miner incentives.

It avoids creating a new account type, relying instead on a unique ENTRY_POINT contract to route transactions and manage gas payments. It does not require major protocol changes and focuses on making advanced features accessible without sacrificing backward compatibility.

Gas payment is handled by a ney PAYGAS opcode, which deducts gas fees dynamically during transaction execution, locks payment to miners, and ensures unused gas is refunded.

Several subsequent EIPs draw inspiration from this approach, adopting the concepts of the ENTRY_POINT contract and the PAYGAS opcode.

https://eips.ethereum.org/EIPS/eip-2771

N.B. ERCs are a subset of EIP. More specifically, ERCs are EIPs that define application level standards - in this case, an interface and behaviour for contracts to enable meta-transactions.

ERC-2771 introduces Forwarders as an onchain and offchain entity used to sponsor transactions. Users can send a free offchain meta-transaction to a dApp’s forwarder, which then sends the tx onchain to the recipient, including the sender’s address in the tx data.

This allows users to interact with decentralized applications (dApps) without holding Ether for gas fees. This approach simplifies user interactions and enhances accessibility without requiring changes to the Ethereum protocol.

https://eips.ethereum.org/EIPS/eip-2938

EIP-2938 proposes integrating account abstraction directly into the Ethereum protocol, allowing smart contracts to function as top-level accounts capable of initiating transactions and paying fees. Users can use these smart contracts, known as Smart Contract Wallets, in place of their EOAs.

Gas payments are handled by a new PAYGAS opcode, which deducts gas fees dynamically during transaction execution, locks payment to miners, and ensures unused gas is refunded.

This enables features like multisigs, social recovery, time locks, and quantum-resistant signing schemes, while maintaining miner incentives and network security.

https://eips.ethereum.org/EIPS/eip-3074

EIP-3074 introduces two new EVM opcodes, AUTH and AUTHCALL, enabling externally owned accounts (EOAs) to delegate transaction control to smart contracts called Invokers. This allows EOAs to execute complex operations and batch transactions without deploying individual smart contracts, enhancing functionality and user experience.

Invokers can batch multiple operations into a single transaction, sponsor gas fees, allowing users to interact without holding ETH. This reduces the technical and financial burden on users, as Invokers can handle batch transactions, gas sponsorship, conditional execution, atomic operations, cross-contract interactions…

https://eips.ethereum.org/EIPS/eip-4337

EIP-4337 is one of the strongest approach to date to introduce AA without many of the drawbacks. It does not require consensus-layer changes, instead introducing a higher-layer pseudo-transaction object called a UserOperation, which replaces the traditional transaction format.

Users no longer need an EOA. Instead, they manage a Smart Contract Wallet, through which they submit UserOperations to a separate mempool, distinct from regular Ethereum transactions. Any block builder can take on the role of a Bundler, a specialized aggregator that collects UserOperations and packages them into a single transaction.

The bundled transaction is sent to a singleton EntryPoint contract, which validates UserOperations, executes their logic, and manages gas payments. Gas fees can be sponsored by a Paymaster smart contract or paid directly by the user’s wallet contract, with both reimbursing the Bundler.

To mitigate the risk of malicious Paymasters causing DoS, a reputation system ensures only reliable actors are prioritized. “To prevent attackers from cheaply clogging the mempool, nodes in the P2P network need to check if an operation will pay a fee before they are willing to forward it.”

The official EntryPoint contract for EIP-4337 was deployed on the Ethereum mainnet on March 1, 2023, by a consortium of Ethereum developers and contributors, including members of the Ethereum Foundation and the broader AA community. GitHub repo:

https://github.com/eth-infinitism/account-abstraction

https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7560.md

A Rollup Improvement Proposal (RIP) is a type of proposal that focuses on improving Ethereum’s rollup technologies, addressing changes that may impact both the execution and consensus layers. Unlike EIPs, which encompass a broader range of updates—including networking protocols and application-level standards—RIPs are specifically targeted at standardizing and documenting advancements in Layer 2 scaling solutions like rollups.

RIP-7560 integrates EIP-4337-like functionality into the protocol itself, rather than directly using EIP-4337’s application-layer implementations, which is why it is referred to as Native AA.

RIP-7560 makes several arguments for Native AA over EIP-4337:

• UserOperations require twice the gas overhead as basic transactions (42k vs 21k)

• crLists and other censorship resistance techniques address transactions but not UserOperations

• UserOperations rely on a separate mempool and a subset of block builders. They also rely on non-standard RPC methods like eth_sendRawTransactionConditional. This significantly smaller set of participating nodes and their reliance on different RPC methods decreases reliability.

• Tx.origin is no longer useful, since using it on a bundled transaction would return the meaningless address of the bundler.

Specifically, RIP-7560 proposes similar execution-layer changes as first introduced by EIP-2938, involving splitting the Ethereum transaction scope into multiple steps (validations, execution and post-transaction logic), thereby eliminating the need for EOAs entirely. It does so while attempting to maintain backward-compatibility with the year and a half of ecosystem adoption of EIP-4337 concepts, such as UserOperations, Bundlers and the Entry Point contract.

The new transaction type adopted is that first described by EIP-2718 (not described in this paper), called AA transaction. The transaction receipt object is also changed to accommodate AA concepts such as paymasters and the multiple phases of the transaction.

https://eips.ethereum.org/EIPS/eip-7701

EIP-7701 looks at RIP-7560 and proposes adopting the EVM Object Format (EOF) to distinguish between validation and execution code sections. The EOF, first defined in EIP-3540, is a structured framework for organizing smart contract bytecode, separating code, data, and metadata to improve modularity, validation, and execution efficiency within the EVM.

This approach introduces multiple entry points within smart contracts, each designated for specific roles such as sender validation, paymaster validation, and deployment. By embedding these roles into the contract's structure, EIP-7701 aims to enhance transaction validation efficiency and security, reducing reliance on external encoding schemes and improving compatibility with various account abstraction mechanisms.

https://eips.ethereum.org/EIPS/eip-7702

EIP-7702 gives EOAs some of the AA benefits: EOAs can use paymasters, i.e. pay gas with tokens or get gas sponsorship.

The proposal introduces a new transaction type, which includes temporary one-time code. This is executed with the transaction, giving EOA temporary smart contract functionality, like transaction batching and gas sponsorship.

While EIP-7701 assumes full adoption of smart contract wallets, which can be costly and complex, 

EIP-7702 allows EOAs to temporarily adopt AA features, bridging the gap for users and dApps not yet ready for full smart contract wallet adoption.

The evolution of Account Abstraction (AA) in Ethereum demonstrates an ongoing journey to enhance flexibility, security, and usability in account management. Early proposals like EIP-86 and EIP-2938 sought to integrate AA directly into the protocol by introducing new transaction types and modifying both the execution and consensus layers. While these proposals introduced powerful concepts like deterministic contract creation and native gas sponsorship, they were ultimately shelved due to the complexity and disruption of the required infrastructure-layer changes.

In response to these challenges, EIP-4337 took a different approach, implementing AA at the application layer. By using a higher-layer object, UserOperation, processed via an EntryPoint contract, it enabled features like custom verification logic, multisigs, gasless transactions, and social recovery—all without changing Ethereum’s core infrastructure. This proposal was successfully deployed as a set of smart contracts, marking a practical and incremental step toward realizing account abstraction.

However, the pursuit of deeper integration didn’t stop with EIP-4337. Recent proposals like EIP-7701 and EIP-7702, as well as Native AA (RIP-7560), revisit the idea of making infrastructure-layer changes. These proposals aim to integrate AA into the protocol itself, addressing execution and consensus layers to reduce gas overhead, improve security, and make features like paymasters and multi-phase transactions more efficient. For example, the Pectra upgrade is set to implement EIP-7702, introducing temporary code execution for EOAs to access AA-like features without deploying permanent smart contracts.

This progression highlights Ethereum’s adaptive approach to account abstraction: moving from bold infrastructure-layer proposals to pragmatic application-layer solutions and now back to refining protocol-layer designs. These efforts aim to balance innovation with Ethereum’s stability and scalability goals.

I am starting the research phase for this paper today, on December 1st 2024. I am applying for the Ethereum Foundation’s 2025 Software Engineering Internship, with a specific interest in improving Ethereum’s UX. Therefore, writing this paper will be an effective way to get an in-depth understanding of AA. I am already familiar with the concepts of ERC4337, including bundlers and entry-point contracts, paymasters and transaction sponsoring…

I will now go deeper, by reading EIPs 86, 101, 1613, 2771, 2938, 3074, 4337, 7701, 7702, RIP 7560 and other related sources.

“The goal with Account Abstraction has always been to solve the cross-chain UX problem” - Yoav Weiss

Account Abstraction (AA) involves three parts of a transaction flow:

1. Authorization Logic (how the transaction is approved)

2. Execution Logic (what the transaction does)

3. Fee Payment (how the validator is paid)

Following years of exploration with the EIPs described in this paper, EIP-4337 condenses the key goal of Account Abstraction into: allowing users to not have EOAs, and instead “use smart contract wallets containing arbitrary verification logic”. This is a technical, practical, operational view of the goal.

On the other hand, the normative end goal has always been to improve UX. Specifically, the three improvements listed in the Pros and Cons tables in this paper are:

• Signing UX

• Wallet Recovery

• Gas Payments

This can be further abstracted into the real final goals:

• Improving onboarding and usage friction by reducing the number of steps and concepts users need to understand when using dApps.

• Giving users peace of mind regarding fears of having their seed phrase lost or stolen.
  

EIP-4337 presented a clever way to address the UX goals of AA without the coordination effort and additional work required by infrastructure-layer changes. It can be seen as a workaround based on the constraint of avoiding consensus-layer changes.

Following EIP-4337, newer proposals push Native AA to the forefront. Native AA refers to embedding functionality into the infrastructure-layer, as opposed to aiming to address AA. RIP-7560 adopts many of the concepts from ERC-4337, but instead of relying on higher-layer infrastructure, it combines them with concepts from EIP-2938, thereby requiring consensus-layer protocol changes.

While this is the current state of collective brainstorming and development, to fully understand the problem being faced, one must look at the full history of AA, which began in 2015 and has seen many proposals since.

Before delving into the evolution of AA ideas brought forth, we must understand what transactions are and the traditional flow of transactions on Ethereum.

A transaction is a write operation - i.e. an action that alters the onchain state. There are two types of transactions on Ethereum: Ether transfers (from EOA to EOA) or function calls (from EOA to Contract).

The diagram below illustrates the standard transaction flow on Ethereum.

This section presents a comprehensive picture of the evolution of Account Abstraction, describing each relevant improvement proposal in a chronological order.

Each improvement proposal will have a table of pros and cons within a structured set of relevant categories:

• Signing UX

• Wallet recovery

• Gas payments

• Security

• Dev overhead

• Future proofing

• Validator incentives

• Implementation

Furthermore, similar to the transaction flow diagram above, each improvement proposal below will have a similar illustration depicting the difference under each approach. The colours yellow and blue represent proposals requiring, and not requiring, infrastructure-layer changes respectively.

https://eips.ethereum.org/EIPS/eip-101

EIP-101 redefines EOAs to no longer store Ether, i.e. only store code and storage. Transactions are simplified to include only the recipient, gas limit, data, and optional code for contract creation, eliminating fields like msg.value.

Ether is instead managed by a unique premined contract at address 0, which handles transfers and balances for all accounts.

https://eips.ethereum.org/EIPS/eip-86

EIP-86 introduces the idea of abstracting transaction origin (who sent it) and signature validation (how it’s authorized), or in other words, “abstracting account security”

It also introduces the CREATE2 opcode, for deterministic contract creation. Although EIP-86 was never implemented, CREATE2 was later re-proposed and finalized as EIP-1014 and introduced in the Constantinople upgrade (February 2019).

*Ethereum was still running Proof of Work at the time of this proposal, hence the miners

https://eips.ethereum.org/EIPS/eip-1613

EIP-1613 proposes the Gas Stations Network (GSN), a decentralised offchain network of relayers, which enables users to make “collect calls”, i.e. transactions paid for by the recipient.

The relayers pay the gas fee upfront and then get reimbursed by the receiver contract (can’t be an EOA). A singleton contract RelayHub manages relayers, ensuring their authorization and reputation, and handles reimbursements.

https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020

This proposed scheme builds on the concept of account abstraction by introducing a two-step process for transaction validation: lightweight verification and execution. This approach allows for custom account logic while maintaining network efficiency and miner incentives.

It avoids creating a new account type, relying instead on a unique ENTRY_POINT contract to route transactions and manage gas payments. It does not require major protocol changes and focuses on making advanced features accessible without sacrificing backward compatibility.

Gas payment is handled by a ney PAYGAS opcode, which deducts gas fees dynamically during transaction execution, locks payment to miners, and ensures unused gas is refunded.

Several subsequent EIPs draw inspiration from this approach, adopting the concepts of the ENTRY_POINT contract and the PAYGAS opcode.

https://eips.ethereum.org/EIPS/eip-2771

N.B. ERCs are a subset of EIP. More specifically, ERCs are EIPs that define application level standards - in this case, an interface and behaviour for contracts to enable meta-transactions.

ERC-2771 introduces Forwarders as an onchain and offchain entity used to sponsor transactions. Users can send a free offchain meta-transaction to a dApp’s forwarder, which then sends the tx onchain to the recipient, including the sender’s address in the tx data.

This allows users to interact with decentralized applications (dApps) without holding Ether for gas fees. This approach simplifies user interactions and enhances accessibility without requiring changes to the Ethereum protocol.

https://eips.ethereum.org/EIPS/eip-2938

EIP-2938 proposes integrating account abstraction directly into the Ethereum protocol, allowing smart contracts to function as top-level accounts capable of initiating transactions and paying fees. Users can use these smart contracts, known as Smart Contract Wallets, in place of their EOAs.

Gas payments are handled by a new PAYGAS opcode, which deducts gas fees dynamically during transaction execution, locks payment to miners, and ensures unused gas is refunded.

This enables features like multisigs, social recovery, time locks, and quantum-resistant signing schemes, while maintaining miner incentives and network security.

https://eips.ethereum.org/EIPS/eip-3074

EIP-3074 introduces two new EVM opcodes, AUTH and AUTHCALL, enabling externally owned accounts (EOAs) to delegate transaction control to smart contracts called Invokers. This allows EOAs to execute complex operations and batch transactions without deploying individual smart contracts, enhancing functionality and user experience.

Invokers can batch multiple operations into a single transaction, sponsor gas fees, allowing users to interact without holding ETH. This reduces the technical and financial burden on users, as Invokers can handle batch transactions, gas sponsorship, conditional execution, atomic operations, cross-contract interactions…

https://eips.ethereum.org/EIPS/eip-4337

EIP-4337 is one of the strongest approach to date to introduce AA without many of the drawbacks. It does not require consensus-layer changes, instead introducing a higher-layer pseudo-transaction object called a UserOperation, which replaces the traditional transaction format.

Users no longer need an EOA. Instead, they manage a Smart Contract Wallet, through which they submit UserOperations to a separate mempool, distinct from regular Ethereum transactions. Any block builder can take on the role of a Bundler, a specialized aggregator that collects UserOperations and packages them into a single transaction.

The bundled transaction is sent to a singleton EntryPoint contract, which validates UserOperations, executes their logic, and manages gas payments. Gas fees can be sponsored by a Paymaster smart contract or paid directly by the user’s wallet contract, with both reimbursing the Bundler.

To mitigate the risk of malicious Paymasters causing DoS, a reputation system ensures only reliable actors are prioritized. “To prevent attackers from cheaply clogging the mempool, nodes in the P2P network need to check if an operation will pay a fee before they are willing to forward it.”

The official EntryPoint contract for EIP-4337 was deployed on the Ethereum mainnet on March 1, 2023, by a consortium of Ethereum developers and contributors, including members of the Ethereum Foundation and the broader AA community. GitHub repo:

https://github.com/eth-infinitism/account-abstraction

https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7560.md

A Rollup Improvement Proposal (RIP) is a type of proposal that focuses on improving Ethereum’s rollup technologies, addressing changes that may impact both the execution and consensus layers. Unlike EIPs, which encompass a broader range of updates—including networking protocols and application-level standards—RIPs are specifically targeted at standardizing and documenting advancements in Layer 2 scaling solutions like rollups.

RIP-7560 integrates EIP-4337-like functionality into the protocol itself, rather than directly using EIP-4337’s application-layer implementations, which is why it is referred to as Native AA.

RIP-7560 makes several arguments for Native AA over EIP-4337:

• UserOperations require twice the gas overhead as basic transactions (42k vs 21k)

• crLists and other censorship resistance techniques address transactions but not UserOperations

• UserOperations rely on a separate mempool and a subset of block builders. They also rely on non-standard RPC methods like eth_sendRawTransactionConditional. This significantly smaller set of participating nodes and their reliance on different RPC methods decreases reliability.

• Tx.origin is no longer useful, since using it on a bundled transaction would return the meaningless address of the bundler.

Specifically, RIP-7560 proposes similar execution-layer changes as first introduced by EIP-2938, involving splitting the Ethereum transaction scope into multiple steps (validations, execution and post-transaction logic), thereby eliminating the need for EOAs entirely. It does so while attempting to maintain backward-compatibility with the year and a half of ecosystem adoption of EIP-4337 concepts, such as UserOperations, Bundlers and the Entry Point contract.

The new transaction type adopted is that first described by EIP-2718 (not described in this paper), called AA transaction. The transaction receipt object is also changed to accommodate AA concepts such as paymasters and the multiple phases of the transaction.

https://eips.ethereum.org/EIPS/eip-7701

EIP-7701 looks at RIP-7560 and proposes adopting the EVM Object Format (EOF) to distinguish between validation and execution code sections. The EOF, first defined in EIP-3540, is a structured framework for organizing smart contract bytecode, separating code, data, and metadata to improve modularity, validation, and execution efficiency within the EVM.

This approach introduces multiple entry points within smart contracts, each designated for specific roles such as sender validation, paymaster validation, and deployment. By embedding these roles into the contract's structure, EIP-7701 aims to enhance transaction validation efficiency and security, reducing reliance on external encoding schemes and improving compatibility with various account abstraction mechanisms.

https://eips.ethereum.org/EIPS/eip-7702

EIP-7702 gives EOAs some of the AA benefits: EOAs can use paymasters, i.e. pay gas with tokens or get gas sponsorship.

The proposal introduces a new transaction type, which includes temporary one-time code. This is executed with the transaction, giving EOA temporary smart contract functionality, like transaction batching and gas sponsorship.

While EIP-7701 assumes full adoption of smart contract wallets, which can be costly and complex, 

EIP-7702 allows EOAs to temporarily adopt AA features, bridging the gap for users and dApps not yet ready for full smart contract wallet adoption.

The evolution of Account Abstraction (AA) in Ethereum demonstrates an ongoing journey to enhance flexibility, security, and usability in account management. Early proposals like EIP-86 and EIP-2938 sought to integrate AA directly into the protocol by introducing new transaction types and modifying both the execution and consensus layers. While these proposals introduced powerful concepts like deterministic contract creation and native gas sponsorship, they were ultimately shelved due to the complexity and disruption of the required infrastructure-layer changes.

In response to these challenges, EIP-4337 took a different approach, implementing AA at the application layer. By using a higher-layer object, UserOperation, processed via an EntryPoint contract, it enabled features like custom verification logic, multisigs, gasless transactions, and social recovery—all without changing Ethereum’s core infrastructure. This proposal was successfully deployed as a set of smart contracts, marking a practical and incremental step toward realizing account abstraction.

However, the pursuit of deeper integration didn’t stop with EIP-4337. Recent proposals like EIP-7701 and EIP-7702, as well as Native AA (RIP-7560), revisit the idea of making infrastructure-layer changes. These proposals aim to integrate AA into the protocol itself, addressing execution and consensus layers to reduce gas overhead, improve security, and make features like paymasters and multi-phase transactions more efficient. For example, the Pectra upgrade is set to implement EIP-7702, introducing temporary code execution for EOAs to access AA-like features without deploying permanent smart contracts.

This progression highlights Ethereum’s adaptive approach to account abstraction: moving from bold infrastructure-layer proposals to pragmatic application-layer solutions and now back to refining protocol-layer designs. These efforts aim to balance innovation with Ethereum’s stability and scalability goals.