Accounts, ERC Standards and Approvals: How Ethereum Applications Really Work

Disclaimer: This article is for informational and educational purposes only and simplifies underlying technical concepts for clarity. It is not financial, investment, or security advice.

To understand how Ethereum applications work, three concepts are particularly important:

• Accounts represent who is interacting with Ethereum.
• ERC standards define common rules for assets and applications.
• Approvals allow applications to use tokens on behalf of an account.

These concepts are closely connected, but it is easier to understand them one at a time.

1. Ethereum Accounts

An Ethereum account is an address that can hold ETH, interact with smart contracts and participate in transactions.

Ethereum has two fundamental types of accounts: an Externally Owned Account (EOA) and a Contract Account.

1.1 Externally Owned Account

An EOA is an account controlled by a private key.

When you first use a wallet such as MetaMask, the wallet first generates a private key locally on your device. The corresponding public key and Ethereum address are derived from it.

At this point, you have the ability to control an Ethereum address, but you have not sent anything to the Ethereum network yet. The flow is:

The private key stays with you. It is never stored on the Ethereum blockchain.

When does the account appear on Ethereum?

There is no separate “open account” transaction for an EOA.

The address can exist mathematically without having any on-chain activity. When the address first receives ETH, sends a transaction, or otherwise becomes part of an on-chain activity, Ethereum records the relevant account state for that address.

For example:

• Create wallet: private key generated locally, Ethereum address derived, no blockchain transaction yet.
• Someone sends 1 ETH to the address: Ethereum records the address's state, with Balance = 1 ETH.

Therefore:

• Address: derived locally from the key
• Account: the address as represented in Ethereum's state
• Account state: the information Ethereum currently records about that account

For an EOA, this state primarily includes its ETH balance and nonce. An EOA can hold ETH, own tokens, receive assets, initiate transactions and interact with smart contracts.

1.2 Contract Account

A smart contract is a program stored on the Ethereum blockchain that runs according to rules written in its code.

For example, a DEX smart contract can contain rules for swapping one token for another. A token contract can contain rules for transferring and recording token balances.

When a smart contract is deployed, Ethereum creates a contract account with its own address. The contract account is therefore the on-chain account associated with that program.

Unlike an EOA, a contract account has no private key. It is controlled by its code, and it cannot initiate transactions on its own.

An account's state can contain four key fields:

2. Where Is the Token Balance Stored?

A token is a digital asset created and managed by a smart contract. Unlike ETH, which is Ethereum's native asset, tokens such as USDC, USDT and UNI are created through smart contracts.

For example, the USDC smart contract contains the rules for how USDC works, including how balances are recorded and how tokens can be transferred.

Suppose an address owns 1,000 USDC. The 1,000 USDC are not stored inside the EOA. The EOA's state does not contain a field saying “USDC = 1,000.” Instead, the USDC contract's storage maintains a record that effectively says: Address → 1,000 USDC.

When a wallet displays the USDC balance, it retrieves this information from the USDC contract and displays: USDC: 1,000.

The same principle applies to NFTs. The NFT contract maintains the records that determine which address owns which NFT.

This is also why wallets do not need to store your token balances themselves. They retrieve the relevant information from the blockchain and present it to you.

3. How Ethereum Uses Account State

An Ethereum account provides the blockchain with the current state associated with that address, which is used when transactions are processed.

The purpose of maintaining account state is to give Ethereum a current source of truth that can be used to validate and execute transactions.

The Wallet's Role

The wallet uses blockchain data to show you the current state of your account.

For example, if your account has 2 ETH, the wallet can retrieve that balance and display it to you. When you want to send ETH, the wallet uses your private key to sign the transaction and submits it to the network.

For ERC-20 tokens, the process is slightly different. The token balance is stored in the token contract's storage, not in your Ethereum account. For example:

The wallet can therefore show you that you have 1,000 USDC and warn you if you try to send more than your available balance.

The Network's Role: Validation and Enforceability

The wallet's balance check is only a convenience. It does not enforce the rules.

When a transaction reaches the Ethereum network, nodes and validators process it using the current blockchain state.

Consider an account with 2 ETH and a nonce of 15. A transaction arrives asking to send 1 ETH. Ethereum uses the current account state to determine whether the transaction can be processed. It checks the account's balance, nonce and other relevant conditions. If the transaction is valid, Ethereum executes it and updates the state: the balance falls to just under 1 ETH (1 ETH minus the gas fee) and the nonce becomes 16.

For an ERC-20 transfer, the token smart contract enforces the token's rules. It checks the balance recorded in its own storage and only executes the transfer if the required conditions are satisfied.

4. Ethereum Accounts vs Bitcoin UTXOs

Bitcoin and Ethereum use fundamentally different models to keep track of assets.

Bitcoin: The UTXO Model

Bitcoin does not maintain a running balance for each address. Instead, it uses Unspent Transaction Outputs (UTXOs).

A UTXO is an amount of BTC created by a previous transaction that has not yet been spent. When you make a Bitcoin transaction, you consume existing UTXOs and create new ones.

For example, suppose 1 BTC is sent to your Bitcoin address. The transaction creates a 1 BTC UTXO that your address can spend.

Now suppose you want to send 0.6 BTC to someone else. You cannot take just 0.6 BTC from that UTXO. The entire 1 BTC UTXO is consumed. The transaction creates 2 new UTXOs. Whatever is left over is the fee, which goes to the miner and is not a UTXO:

The original 1 BTC UTXO is now spent. It is not modified; the transaction creates new UTXOs. The 0.39 BTC UTXO is a new UTXO that you can use in your next transaction.

A slightly more complicated example

Suppose A and B each send you 1 BTC, and you now want to send 1.5 BTC to someone else:

• A sends you 1 BTC → you receive a 1 BTC UTXO
• B sends you 1 BTC → you receive another 1 BTC UTXO

You therefore control two separate UTXOs worth 2 BTC in total. Bitcoin can use both UTXOs as inputs to the same transaction:

• Inputs: 1 BTC + 1 BTC = 2 BTC
• Outputs: 1.5 BTC + 0.49 BTC change = 1.99 BTC
• Fee: 2 BTC − 1.99 BTC = 0.01 BTC (the difference between inputs and outputs)

The important point is that you don't have one 2 BTC balance represented by a single UTXO. You have two separate UTXOs worth 1 BTC each, and the transaction can consume both of them. The 0.49 BTC change is then a brand-new UTXO that you control.

Bitcoin nodes maintain a UTXO set, which is the current collection of all unspent outputs. The underlying transactions are recorded on the blockchain, and nodes derive and maintain the current UTXO set from those transactions.

Ethereum: The Account Model

Ethereum uses an account-based model. Instead of tracking individual units of ETH as UTXOs, Ethereum maintains accounts and their current state. For an EOA, this state primarily includes the ETH balance and nonce. For a contract account, it can also include contract code and contract storage.

This state is part of Ethereum's on-chain state. Nodes maintain their own local copy of this state so they can validate and execute transactions.

For example, if an Ethereum account has 2 ETH, Ethereum records its current balance as 2 ETH. A transaction sending 0.5 ETH updates the account states:

There is no equivalent of consuming a 2 ETH UTXO and creating new ones.

The Key Difference

5. What Are ERC Standards?

Shared Rules Everyone Follows

An ERC standard is a publicly agreed template that defines how a certain type of Ethereum contract should behave. Because contracts following the same standard expose the same basic functions, wallets, applications and exchanges can interact with them without building a separate integration for every token or application.

Think of it like a standard shipping container. Once ports, ships, trucks and railways agree on a common container format, the same container can move through the entire system without being repackaged at every stage. ERC standards create a similar common language for Ethereum.

For example, an ERC-20 token provides standard functions such as balanceOf(), transfer() and approve(). A wallet does not need to understand the internal code of every ERC-20 token. It knows what functions to expect and how to interact with them.

Where Standards Come From

Changes and conventions for Ethereum are proposed through EIPs, or Ethereum Improvement Proposals.

EIPs that change the Ethereum protocol itself require changes to the network. EIPs that define standards for contracts and applications are generally referred to as ERCs, or Ethereum Requests for Comments. The number identifies the proposal. For example, ERC-20 refers to proposal number 20.

No one is forced to use an ERC standard. Standards become useful because wallets, applications, exchanges and developers adopt them.

6. The Key ERC Standards

ERC standards can be grouped into three broad categories:

1. Token standards: define how different types of digital assets work.
2. Signing, permissions and account standards: define how users authorise actions and interact with accounts.
3. Finance and regulated asset standards: define common structures for DeFi products and regulated tokenised assets.

6.1 Token Standards

ERC-20: Fungible Tokens

What is it? ERC-20 is a standard for fungible tokens, where every unit is interchangeable with another unit. For example, 1 USDC in your wallet is equivalent to 1 USDC in someone else's wallet. There is no distinction between the individual units of USDC. If you have 100 USDC, you do not have 100 individually identifiable USDC units. You simply have a balance of 100 USDC.

This is different from an NFT. If you own NFT #101 and someone else owns NFT #102, the two tokens are individually identifiable and may represent different assets or have different characteristics.

What does it define? A common interface with functions such as:

• balanceOf() to check a token balance
• transfer() to transfer tokens
• approve() to give another address permission to spend tokens
• allowance() to check that permission
• transferFrom() to transfer tokens using an approved allowance

Why does it matter? Without a common standard, every token could implement its own way of checking balances, transferring tokens and handling approvals. A wallet or exchange would then need a separate integration for every token. ERC-20 gives applications a predictable interface.

Example: think about USB-C. If every phone manufacturer used a completely different charging connector, you would need a different charger for every phone. A common connector allows many devices to use the same charging ecosystem. ERC-20 does something similar for tokens. Because USDC, USDT and other ERC-20 tokens expose the expected functions, wallets and applications can interact with them using the same basic interface.

Where is it used? Stablecoins, governance tokens, reward points and many other fungible digital assets.

ERC-721: Unique Tokens

What is it? ERC-721 is a standard for non-fungible tokens, where each token represents a distinct asset.

What does it define? It provides a standard way to identify an individual token using a token ID, determine who owns it, transfer ownership, and check ownership and token-related information.

Why does it matter? ERC-20 assumes that one token is interchangeable with another. That does not work when each asset needs its own identity. For example, Seat A12 at a concert is not interchangeable with Seat B15. ERC-721 allows each asset to have its own identity and ownership record.

Example: imagine concert tickets. Every ticket belongs to the same event, but each ticket can have a different seat number and owner. An ERC-721 contract can represent each ticket as a separate token ID. A marketplace can therefore identify and transfer the specific ticket rather than treating all tickets as identical.

Where is it used? NFTs, digital art, memberships, certificates, tickets and other unique assets.

ERC-1155: Multiple Token Types

What is it? ERC-1155 is a standard for managing multiple types of tokens through a single contract. These can include both fungible and non-fungible assets.

What does it define? It provides a common structure for managing multiple token IDs and supports operations such as transferring several types of tokens in a single transaction.

Why does it matter? Consider a blockchain game with hundreds of different assets. Creating and managing a separate contract for every asset can be inefficient. ERC-1155 allows many assets to be managed through one contract and can support batch operations.

Example: a game could have:

• 100,000 gold coins → fungible, because every coin is equivalent
• 5,000 health potions → fungible, because each potion is equivalent
• 1 legendary sword → non-fungible, because that specific sword is unique

An ERC-1155 contract can represent each of these as different token IDs while managing them through the same contract.

Where is it used? Gaming, digital collectibles, ticketing and applications with many different asset types.

6.2 Signing, Permissions and Accounts

EIP-712: Structured Signatures

What is it? EIP-712 is a standard for signing structured information. (Strictly speaking, EIP-712 is an EIP rather than an ERC. It is included here because many token and application standards build on it.)

When you sign something with your wallet, your private key creates a cryptographic signature that proves you authorised a particular piece of information. The problem is that the information being signed is not always easy for a human to understand. Without a standard format, a wallet may present the user with a collection of technical data that does not clearly explain what they are approving.

What does it define? A standard way for an application to structure the information before asking the user to sign it. Instead of asking your wallet to sign something that effectively looks like a long hexadecimal string, the application can structure the request so the wallet shows each field clearly:

Why does it matter? A blockchain signature is powerful. Once you sign something, the application may be able to use that signature as proof that you authorised an action. EIP-712 therefore helps solve an important human-readable signing problem:

Without a standard for structuring the request, different applications could present signing information in completely different ways, making it harder for wallets to interpret and display consistently.

Example: think about signing a bank document. You would want to see “Approve transfer of 100 AED to Account X” before signing it. You would not want the bank to show you a long string of technical data and simply ask you to sign it. EIP-712 brings a similar concept to crypto.

Where is it used? DeFi applications, token permits, authorisations and other situations where users need to sign structured messages.

ERC-2612: Signature-Based Token Approvals

What is it? ERC-2612 extends ERC-20 to allow a token holder to approve spending through a digital signature, rather than sending a separate approve() transaction.

What does it define? It adds a permit() mechanism that allows a token holder to sign an approval giving another address permission to spend tokens.

Why does it matter? With a traditional ERC-20 approval, using a DeFi application often requires two on-chain transactions:

1. approve() → give the DeFi application permission to spend your tokens
2. transferFrom() / DeFi transaction → actually use the tokens

Both transactions require gas, so the user normally needs ETH to pay for the approval transaction as well as the subsequent transaction. ERC-2612 allows the approval to begin with an off-chain signature.

Here is how it works, step by step:

Step 1: The DeFi application creates the permit. The application creates a structured message containing the owner (your address), the spender (the lending protocol), the amount (100 USDC) and a deadline. The message can use the EIP-712 standard discussed above.

Step 2: You sign the permit. Your wallet shows you the information and asks you to sign it. You click Sign. The wallet uses your private key to create a cryptographic signature. Your private key never leaves the wallet.

Step 3: The permit is sent. The wallet simply returns the signature back to the application. This is not an Ethereum transaction. Therefore: no transaction, no gas for this step. This removes the separate approval transaction and, in most cases, the gas for it.

Step 4: The permit is submitted with the transaction. The USDC contract verifies the signature. If it is valid, it records the allowance: your address → lending protocol → 100 USDC allowance. The DeFi protocol then processes deposit(100 USDC) and uses transferFrom(your address, lending protocol, 100 USDC). The USDC contract checks the allowance and transfers the tokens.

This transaction does require gas. The important difference is that the user did not need to send a separate approval transaction.

Where is it used? DeFi applications such as lending, swapping and other protocols where users need to approve an application to spend their ERC-20 tokens.

ERC-4337: Smart Accounts

What is it? ERC-4337 provides infrastructure for smart contract-based accounts, commonly called smart accounts.

What does it define? It introduces a framework around user operations, smart account validation, bundlers and paymasters, allowing account behaviour to become more programmable.

Why does it matter? Traditional EOAs have a relatively fixed transaction model. Smart accounts can support features such as:

• alternative authentication methods
• account recovery
• transaction batching
• sponsored gas fees
• programmable transaction rules

Example: think of a business bank account with multiple, configurable authorisation rules. Instead of requiring one person to approve every transaction, the account could be configured so that:

• transactions below AED 10,000 require one authorised person
• transactions above AED 10,000 require two authorised people
• certain payments require approval from a specific department

On its own, a traditional Ethereum EOA cannot implement these kinds of rules because transactions are authorised by its private key.

A smart account can put programmable authorisation rules around the account. For example, it could require multiple signatures for a transaction, support different authentication methods, batch several actions into one transaction, or allow another party to pay the gas.

Where is it used? Smart wallets and applications that want a more flexible account experience.

6.3 Finance and Regulated Assets

ERC-4626: Tokenised Vaults

What is it? ERC-4626 is a standard interface for tokenised vaults. A vault accepts assets from users and issues tokens representing their position in that vault.

What does it define? It standardises functions for actions such as depositing assets, withdrawing assets, minting vault shares, redeeming shares, and converting between assets and shares.

Why does it matter? Without ERC-4626, every DeFi vault could have its own way of handling deposits and withdrawals. One vault might use deposit(), another might use addFunds(), another might require several different functions. An application integrating these vaults would need to understand and build a separate integration for each one.

ERC-4626 defines a common interface for vaults. A compliant vault exposes standard functions for actions such as depositing assets, withdrawing assets, minting shares and redeeming shares. This means a DeFi application can be built to understand the ERC-4626 interface once and then interact with many different ERC-4626 vaults without creating a completely different integration for each vault.

Example: imagine a fund marketplace with several investment funds. Each fund has its own internal system, but investors expect standard actions such as invest money, withdraw money and receive fund units. If every fund used completely different processes and terminology, a platform integrating many funds would need a separate integration for each one. DeFi vaults work similarly. Different vaults may have different strategies and assets, but ERC-4626 defines a common interface for actions such as deposit(), withdraw(), mint() and redeem().

Where is it used? DeFi yield vaults, lending strategies and other managed asset pools.

ERC-3643: Permissioned Tokens

What is it? ERC-3643 is a framework for permissioned tokens, where ownership and transfers can depend on identity and compliance requirements.

What does it define? It provides components for areas such as identity verification, investor eligibility, token issuance, transfer validation and compliance checks.

Why does it matter? Most public blockchain tokens are designed to be transferable without checking whether the recipient is an eligible investor. Regulated financial assets are different. A fund, bond or security may only be available to investors who have completed KYC and satisfy certain eligibility requirements. ERC-3643 provides a framework for incorporating these restrictions into the token architecture.

Example: consider a regulated investment fund. You cannot simply transfer a unit of the fund to anyone. The recipient may first need to pass KYC and satisfy eligibility requirements. An ERC-3643 token can check whether the sender and recipient satisfy the required conditions before allowing the transfer.

Where is it used? Tokenised securities, investment funds, bonds, real estate and other regulated financial assets.

The Common Idea

These standards solve different problems, but the underlying principle is the same:

The standard does not necessarily define everything about an asset or application. It defines the common rules or interface that other systems can rely on.

7. What Is an Approval?

An approval is a standing permission you give a contract to move your tokens, and it exists because apps can't reach into your wallet any other way.

Here is the problem approvals solve. Say you want to swap 100 USDC for ETH on a trading app. The app's contract needs to take your USDC. But your USDC balance lives inside the USDC contract, not in your wallet, and the USDC contract will only move it if you say so. So the process has two steps:

1. Approve: you tell the USDC contract, “the trading app may take up to 100 of my USDC.” The USDC contract records this as an allowance.
2. Use: the trading app's contract asks the USDC contract to move your USDC. The USDC contract checks the allowance, sees permission, and moves it.

An everyday comparison is a direct debit or standing order at your bank. You authorise a company to take money from your account, up to a limit, without asking you every time. It is convenient, and that is exactly why it is risky if the company turns out to be dishonest, or if its systems are hacked.

Two key features of approvals:

• They can last until you cancel them: A limited allowance shrinks as it is used, and permits carry a deadline. However, an unlimited token allowance or an NFT “approve all” stays active until you revoke it. An approval you gave two years ago to an app you've forgotten about may still be active today.
• They are separate from your wallet's security: A perfectly protected seed phrase does not help if you have approved a malicious contract. It already has permission.

8. Types of Approval

There are four main kinds of approval:

1. Limited token allowance

You approve exactly what you need, for example 100 USDC for a 100 USDC swap. If the app is later compromised, the most you can lose is whatever is left of that allowance. Many wallets now let you edit the amount before confirming, which is a good habit.

2. Unlimited token allowance

Many apps ask for unlimited approval so you don't have to approve again, and pay another fee, next time. It is convenient, but it leaves a door open permanently. If that app's contract is ever hacked, every unit of that token your address holds is exposed, including any you receive in future.

3. Approve all for NFTs

NFT marketplaces need this to list your items for sale. But one signature covers your entire collection from that project. Scammers love this approval: a fake “free mint” or “claim your reward” site asks for it, and moments later the collection is gone.

4. Signature permits

Newer tokens support permits: instead of a separate approval transaction, you sign a message and the app submits it for you (for example, ERC-2612, explained above).

The danger is that signing a message costs nothing and feels harmless, much like a login. Scammers exploit this by presenting a permit as a “verification” or “sign-in.” A single signature can hand over your tokens.

Permit2 is also widely used. Uniswap's Permit2 contract brings signature-based approvals to almost any ERC-20 token, not only tokens that support ERC-2612. You give the Permit2 contract a one-time approval, and after that, apps ask you for signatures instead. Many permit-phishing attacks use Permit2 signatures, so treat a Permit2 signature request as carefully as a payment.

9. Managing Approvals Safely

Approvals are public and can be cancelled at any time, so a few minutes of regular housekeeping removes most of the risk.

Because every approval is recorded on the blockchain, anyone can look up which contracts have permission over an address. Free tools make this easy:

• Revoke.cash, a widely used site that lists all your approvals across many networks
• Etherscan's Token Approval Checker, built into the main Ethereum block explorer
• Built-in wallet features, as some wallets such as Rabby now show and cancel approvals directly

Cancelling, or revoking, an approval sets the allowance back to zero. It is an ordinary transaction, so it costs a small fee. Note that revoking a signature permit you've signed but that hasn't been used yet works differently, and good tools will guide you through it.

Good habits to have:

1. Approve only what you need when the wallet lets you edit the amount.
2. Review approvals every few months, and after trying any new or unfamiliar app.
3. Revoke anything you don't recognise or no longer use. Prioritise unlimited token allowances and NFT approve-all permissions.
4. Use a separate wallet for experiments. Keep your main holdings in a wallet that rarely connects to new apps.
5. If you suspect a scam, act fast. Revoke the approval immediately and move remaining assets to a fresh wallet.

10. Putting It All Together

Consider a simple DEX transaction. You want to exchange 100 USDC for ETH.

The relationship is therefore:

Each concept has a different role:

Ethereum's ecosystem works because these pieces fit together. Accounts provide identity and control. ERC standards provide common rules. Approvals provide controlled permissions.

Together, they allow a wallet, token and smart contract created by different developers to interact through a common framework. That interoperability is one of the foundations of Ethereum's application ecosystem.

Key Takeaways