How Ethereum and Solana Tokens Work:  Approvals, Permit, Smart Accounts, and EIP-7702

Smart contract blockchains, such as Ethereum and Solana, both have the concept of “tokens,”  These tokens are managed by smart contracts that contain either a single token or a collection of tokens, either fungible or non-fungible. Blockchains and wallet software work hard to abstract away the technical details of how this works, making it more relatable to the average user. However, to gain a deeper understanding of end-user security, we’ll need to peel back that abstraction and reveal what’s happening under the hood.

Token Contracts

When ETH first came to life, it launched with the Ethereum Virtual Machine and Smart Contracts, code and a way to execute it in a decentralized way, offering something the Bitcoin blockchain never did. 

Token contracts on these chains follow specific token “standards.” For example, on the Ethereum network, you’ve likely heard of ERC-20 (often referred to as the fungible token standard), ERC-1155, and ERC-721 (popular non-fungible counterparts). However, tokens don’t have to adhere strictly to these standards at all. While ERC-20 defines how a transfer function should work, nothing stops a developer from coding a similar token that behaves in an unexpected or malicious way. Also, remember that the contract tracks balances, transactions, and approvals granted to specific addresses. In effect, it functions like a mini-blockchain within a blockchain!

The Approvals Problem

Approvals track which addresses have given permission for their tokens to be moved by a smart contract or an individual address. It’s the code equivalent of a money manager, like saying, “Alfred,” the bank teller can spend my money as needed. On the Ethereum blockchain, approvals have always been somewhat challenging to manage. While security-minded community members view approvals as a necessary guardrail, many users perceive them as unnecessary friction, as they cost more gas, require additional steps, and add to the confusion.

One nice thing about approvals was that they required the wallet owner to send a transaction directly to the smart contract, without an intermediary in between. This kept users safe because a single smart contract could not batch approval transactions to drain 20 different tokens from a wallet in one transaction. However, with the introduction of EIP-7702 and Smart Accounts in 2025, this “safety feature” is no longer a given

The security community is split on this. On the one hand, it is necessary to simplify the transaction flow, similar to other modern smart contract blockchains, such as Solana. However, on the other hand, it compromises the  security layer that once protected users from losing everything due to a careless transaction signature. The reality is that approvals were never a perfect security layer anyway. Users often gave them flippantly, with infinite allowances, and left them open in perpetuity, leading to approvals sometimes being exploited years later. So, where does that bring us?

Permit & Permit2

Permit, introduced as ERC-2612, addresses the approvals problem head-on. It allows off-chain signatures to stipulate approvals and enables adding an expiration date to those approvals, addressing two major issues with the on-chain approval system: costly gas and lingering security vulnerabilities. However, existing token contracts couldn’t use this system. So in 2022, Uniswap Labs introduced Permit2, a smart contract layer that acts as a universal permission manager for tokens, even those that don’t natively support permit. Permit2 is powerful, but also a target, since its far reaching power leaves it vulnerable to scammers looking to batch-exploit approvals.

Figure 1-1 Permit Tokens (Taken from the Boring Security 101 Class)

Permit2 had some additional features incorporated to enable batch transfers of these tokens. However, this update still didn’t bring Ethereum to parity with modern smart contract blockchains which treat tokens like first-party apps—and don’t require approvals. 

SPL (Solana Program Library)

SPL stands for Solana Program Library, and it’s foundational for how Solana handles tokens, both in its code and governance structure. Unlike Ethereum, where each token contract has its own siloed logic, most Solana tokens rely on a central token program that enforces standardized behavior. This centralization brings consistency, but also some tradeoffs.

What meaningful differences are there from a security perspective to a user? For one thing, tokens are governed by rules within the Standard Token Program (or its 2022 upgrade), and are not simply “standard suggestions” that can be bent or broken by a developer. A transfer within the token program will do exactly what you think it will, as these function names and behaviors are standardized.

  Figure 1-2 Token Account Takeover Wallet Example (Taken From Boring Security’s Solana 101 Class)

Although you can make tokens outside of these token programs, most wallet providers don’t allow users to interact with non-standard tokens by default. So, while it isn’t a protocol-level guarantee, it’s better for the average user. Additionally, certain token contract details are changeable by default. For example, the Token amount can be changed until the Mint Authority is revoked. Users can check Solana mint authority status via the tools mentioned later in this module! 

For those curious, Boring Security offers an entire class dedicated to exploring Solana security from an end-user perspective. 

Smart Wallet Accounts, Delegation, And Where It’s All Going

Ethereum Improvement Proposals surrounding smart accounts are everywhere: EIP-4337, EIP-7702, EIP-6900, etc. The ultimate goal is to blur the line between the current format of self-custody (EOA) wallets and upgrade users to smart accounts that enable provisioning, batch transactions, permissions, social recovery, and more. 

Thanks to the Pectra upgrade in 2025, Ethereum now enables the creation of batched transactions in regular wallets (EOAs) without requiring approval in separate transactions. While this is an excellent step for user-experience, it’s also a potential security risk. For this reason, many wallet providers have chosen not to implement smart accounts, or to implement them conservatively at first. For instance, at Ledger, only the simple 7702 contract provided by the Ethereum Foundation is compatible with your Ledger signer at the device level—and it is not yet available to use via Ledger Live. While multiple software wallet and infra providers have created audited versions of these contracts, many of them rely on users blind signing transactions, which is a real risk when you’re delegating your whole wallet to a smart account. For this reason, you should always exercise caution, even when interacting with an audited 7702 contract.

Final Thoughts

Whether on Ethereum or elsewhere, the direction is clear: wallets are becoming increasingly intelligent, programmable, and complex under the hood. With proposals like EIP-4337 and EIP-7702 already live, and others like EIP-6900 evolving fast, the Ethereum ecosystem is steadily moving toward a future where every wallet is a customizable app. Other chains, like Solana, have taken different paths to abstraction, but the challenges remain the same: making security intuitive, making power features usable, and wallets that everyday users can trust. 

We’re not there yet, but the engine is running, and the mid-air upgrades continue. As a result, staying educated is crucial to staying safe, as numerous changes are being made to blockchains, wallets, and the scam landscape.