A smart account can hold assets and use contract logic to decide whether an action is authorized. OpenZeppelin's account documentation separates the account from the signer and shows how execution and validation fit together. This allows different authentication mechanisms and batched actions. The term smart wallet therefore covers a family of implementations rather than one security model. The useful research questions are which code executes, what proves authorization and which parts can be replaced after the account has funds.

EIP-1193, now Final, standardizes the JavaScript provider interface used between applications and wallets. Requests and events let an application learn when an account or network changes. Connected means the provider can service requests to a chain; it is not the same as an application having permission to spend. The specification treats the provider as a potential adversarial boundary. Applications must handle rejection and changed context rather than assume yesterday's selected account or chain still applies today.

Final EIP-6963 addresses competition between browser extensions trying to occupy window.ethereum. Wallets announce providers through events so a user can choose among several installations. The proposal explicitly discusses imitation, unsafe icons and fingerprinting. Discovery improves choice, but a displayed wallet name is still information supplied by software. A convincing icon does not authenticate a provider.

The standard's practical contribution is making simultaneous options discoverable instead of letting an unpredictable extension loading order silently decide which one an application receives.

Final ERC-191 defines an envelope for signed data, with versions for particular uses. Its structure separates arbitrary signed messages from Ethereum transactions. This identifies the payload type without explaining every consequence. A message can still authorize something economically important. Evaluate its recipient, intended use and replay rules even when a wallet describes it simply as a message.

Final EIP-712 gives structured messages typed fields and a domain so interfaces can display meaningful data rather than only an opaque hash. The standard explicitly leaves replay protection to applications. A contract name, chain identifier and verifying address can help distinguish contexts, but the application still needs nonces, expiry or other appropriate controls. Typed signing is therefore a representation improvement. It does not turn a fraudulent spender into a legitimate one or remove the need to read an amount and scope before approval.

Final ERC-4361, Sign-In with Ethereum, specifies an authentication message with a domain, address, URI, chain ID, nonce and issued time. Verification establishes a session, with phishing and replay addressed by the specification. Authentication remains different from financial permission. The service manages the session and access rules; owning an address does not grant every application role.

Final ERC-1271 offers isValidSignature to ask whether evidence satisfies a contract account's current rules. A multisignature account applies its threshold rather than one private key. Verifiers must consider state: changed owners or authorization rules can alter whether a signature remains valid.

Final ERC-6492 handles a related onboarding difficulty: an account's contract may not yet be deployed when it needs to sign in. Its wrapped signature supplies a way to prepare or deploy the account before checking authorization. This counterfactual workflow can postpone deployment until needed, but verifiers must implement the format carefully. The specification warns about calls made during validation and the treatment of wrappers. An apparent absence of code at an address is not enough to decide that only ordinary key signatures can be valid there.

Final ERC-4337 defines UserOperations submitted to bundlers, which package them into calls to an EntryPoint contract. The account validates authorization before execution. A paymaster may sponsor the fee. This route works through application infrastructure rather than requiring the consensus layer to accept a new transaction format for each wallet feature. The standard supports custom account validation and distinguishes a UserOperation from an ordinary network transaction.

Its flexibility comes with infrastructure compatibility and implementation details that users should not mistake for automatic universal support.

ERC-7562 is in Review at this editorial check. It restricts validation behavior to protect nodes from unpaid computation and operations invalidated by unrelated state changes. Its rules address opcodes, storage access and entity reputation. These constraints explain why an account being able to execute code on-chain does not mean every bundler will accept its operation into a shared pool. A developer must consider the operation's admission rules as well as the account's own authorization check and the target network's execution rules.

The account-abstraction implementation's release record is also part of compatibility research. EntryPoint releases document changes in interfaces, validation and gas accounting. An application should identify the particular deployment and version its bundler supports rather than treat ERC-4337 as a single unchanging software binary. A specification is the agreement; a release is code implementing it. Review those records together when investigating a failed operation, a sponsorship limit or a migration between providers.

Final Core EIP-7702 allows an ordinary account to authorize a persistent delegation to another address's code. Replacing or clearing the designation requires another valid authorization. A delegation can affect later calls, so it must not be interpreted as permission for only one harmless interaction.

The Ethereum Foundation's Pectra announcement placed this capability in the May 2025 mainnet upgrade and described batching, sponsored fees, alternative authentication, spending controls and recovery as features wallets could build around it. Those are possibilities supplied by appropriate delegation code, rather than features every existing wallet gains automatically. The announcement also explains revocation and nonce-bound authorization. The practical boundary is the specific code selected by the user and what the wallet actually implements on the selected chain.

Draft ERC-7821 proposes a minimal batch executor interface that can be used with delegations. It gives applications a consistent way to prepare several actions and asks implementations to enforce access control. Batch execution can improve an approve-and-use workflow, but the same convenience can group several consequential permissions into one confirmation. An interface that knows how to execute a batch does not know whether the batch is desirable. Its authorization rules and the user's understanding of each action remain central.

Draft ERC-7579 specifies interfaces for modular accounts and modules, including validators, executors, fallback handlers and hooks. Its authors want functionality to move across account implementations without trapping users in one vendor's ecosystem. Minimal refers to an intended common boundary, not an absence of complex security consequences. Installation and removal are sensitive actions because modules can influence authorization or execution.

Compatibility must be checked for the actual account and module implementation; sharing the proposal number is not proof that every pairing is safe.

Draft ERC-6900 is another modular-account effort with its own validation, execution and hook conventions. It documents coordination among implementers while leaving room for architecture choices. Multiple proposals illustrate a community still negotiating where interoperability should live. Readers should not collapse them into one interchangeable plugin system or infer that a proposal listed in the registry is Final. An implementation's supported interfaces, configuration and tested combinations matter more than a generic statement that it follows modular account standards.

Draft ERC-7710 defines an interface through which a contract can delegate capabilities to another contract or ordinary account. The delegator authorizes a manager to execute permitted actions. The standard does not itself prescribe every condition an application might want. Limited automation therefore depends on the implementation checking the intended constraints during redemption. An authorization written as a friendly promise is only effective if the code actually rejects actions beyond that promise, including attempts routed through a different executor or recipient.

Draft ERC-7715 adds wallet methods for requesting, examining and revoking execution permissions. It introduces permission and rule types, allowing applications to ask for something more specific than unrestricted repeated signing. Scope can include the chain, allowed action and time limits, but support depends on the wallet and enforcement mechanism. This is a developing interface, not proof that every advertised session key has the same protections. A reader should inspect how the wallet displays permission, what code enforces it and what revocation actually invalidates.

Final EIP-5792 standardizes multiple-call requests, capability discovery and status checks. Applications can ask whether atomic execution is supported instead of assuming a set of calls always succeeds together. Atomic means the relevant batch succeeds or fails as a unit under the supported behavior; it does not mean every requested operation was wisely chosen. A wallet might support different capabilities on different networks. A readable confirmation should explain the requested outcome and the supported execution mode rather than hide several permissions behind a single reassuring button.

Vitalik Buterin's January 2021 recovery essay argues for a signing key backed by a group of guardians able to authorize replacement after loss. He contrasts this with the theft and loss risks of one key or one mnemonic backup. The essay is an attributable proposal about personal custody. Guardian selection, independence and continued availability remain part of the design. A guardian threshold is meaningful only if the user understands who holds that authority and what circumstances allow it to be exercised.

Safe's module documentation gives a concrete example of programmable account extensions. Enabled modules can execute transactions through the account and support arrangements such as allowances or recovery. Safe explicitly warns that a malicious module can take over an account. This makes installing a module an authority decision, even if its purpose sounds protective. Owners should investigate the actual module's code and controls, and how to remove it, instead of assume every extension inherits the security of the account's basic multisignature mechanism.

Safe guards illustrate a different risk. A guard can inspect transactions before and after execution, enforcing restrictions beyond a signing threshold. Safe's documentation warns that a broken guard can block transaction execution and create denial of service. A rule meant to prevent theft can therefore threaten availability if configured badly. Research needs both sides of the custody question: who can authorize an undesirable action, and what could prevent legitimate owners from acting or recovering when an extension malfunctions.

In The Three Transitions, Buterin connects smart account adoption with scaling and privacy. Different networks, recovery changes and address relationships complicate how a user moves through the ecosystem. His essay treats this as a coordination problem for wallets and applications rather than a feature solved by publishing one proposal. That framing explains why a technically valid account may still meet an application that cannot authenticate it, discover its network or handle its recovery model.

The original ERC-4337 discussion supplies an example of that coordination. Sequence contributor Agustin Aguilar welcomed the approach while asking how existing factories and counterfactual addresses could fit its deployment path. Buterin responded that supporting accounts created through other routes required attention to the initialization mechanism. This early exchange records practical compatibility work among wallet builders. It is evidence of the design process, not a blanket statement that every wallet now uses an identical factory or that historic implementation assumptions still apply.

The ERC-7579 discussion contains enthusiastic support alongside criticism of the proposal's minimality and questions about using it with other account-abstraction architectures. Its authors discuss simplifying functions and the relationship between validation and execution. These details matter because standards are agreements negotiated among implementations. The practical test is whether a user can change applications or modules without losing control or necessary functionality.

A proposal's vendor-independence ambition deserves separate evidence of working migrations and compatible implementations.

The ERC-7715 discussion likewise asks how wallets identify the application requesting permission, how validity periods should work and how implementations should handle the interface. Contributors proposed simplifications after practical development experience. Such questions are a healthier record than pretending a new standard removed every ambiguity at publication. Review the actual allowed recipients, assets, durations and revocation behavior before trusting automation.

An application able to request a limit is not enough; enforcement must survive the conditions in which that limit matters.