continues proposed deprecation of whitelist

Author: m4sterbunny

src/content/roadmap/account-abstraction/index.md

@@ -48,7 +48,7 @@ For example, backup keys can be added to a wallet so that if you lose or acciden
 - **Account freezing**: If a device is lost or compromised the account can be locked from another authorized device, protecting the user's assets.
 - **Account recovery**: Lost a device or forgotten a password? In the current paradigm, this means your assets could be frozen forever. With a smart contract wallet, you can setup an allowlist of accounts that can authorize new devices and reset access.
 - **Set transaction limits**: Specify daily thresholds for how much value can be transferred from the account in a day/week/month. This means if an attacker does gain access to your account they can't drain everything at once and you have opportunities to freeze and reset access.
-- **Create whitelists**: Only allow transactions to certain addresses that you know to be safe. This means that _even if_ your private key was stolen, the attacker could not send funds to non-whitelisted destination accounts. These whitelists would require multiple signatures to change them so that an attacker couldn't add their own address to the list unless they had access to several of your backup keys.
+- **Create allowlists**: Only allow transactions to certain addresses that you know to be safe. This means that _even if_ your private key was stolen, the attacker could only send funds to destination accounts on your list. These allowlists would require multiple signatures to change them so that an attacker couldn't add their own address to the list unless they had access to several of your backup keys.
 
 ## Better user experience {#better-user-experience}
 
@@ -92,7 +92,7 @@ The way wallets work would also change under EIP-4337. Instead of each wallet re
 
 <ExpandableCard title="EIP-2938: changing the Ethereum protocol to support account abstraction" eventCategory="/roadmap/account-abstract" eventName="clicked EIP-2938: changing the Ethereum protocol to support account abstraction">
 
-<a href="https://eips.ethereum.org/EIPS/eip-2938">EIP-2938</a> aims to update the Ethereum protocol by introducing a new transaction type, <code>AA_TX_TYPE</code> that includes three fields: <code>nonce</code>, <code>target</code> and <code>data</code>, where <code>nonce</code> is a transaction counter, <code>target</code> is the entry point contract address and <code>data</code> is EVM bytecode. To execute these transactions, two new instructions (known as opcodes) have to be added to the EVM: <code>NONCE</code> and <code>PAYGAS</code>. The <code>NONCE</code> opcode tracks the transaction sequence and <code>PAYGAS</code> calculates and withdraws the gas required to execute the transaction from the contract&#39;s balance. These new features allow Ethereum to support smart contract wallets natively as the necessary infrastructure is built in to Ethereum&#39;s protocol.
+<a href="https://eips.ethereum.org/EIPS/eip-2938">EIP-2938</a> aims to update the Ethereum protocol by introducing a new transaction type, <code>AA_TX_TYPE</code> that includes three fields: <code>nonce</code>, <code>target</code> and <code>data</code>, where <code>nonce</code> is a transaction counter, <code>target</code> is the entry point contract address and <code>data</code> is EVM bytecode. To execute these transactions, two new instructions (known as opcodes) have to be added to the EVM: <code>NONCE</code> and <code>PAYGAS</code>. The <code>NONCE</code> opcode tracks the transaction sequence and <code>PAYGAS</code> calculates and withdraws the gas required to execute the transaction from the contract&#39;s balance. These new features allow Ethereum to support smart contract wallets natively as the necessary infrastructure is built into Ethereum&#39;s protocol.
 
 Note that EIP-2938 is currently not active. The community is currently favoring EIP-4337 because it does not require changes to the protocol.