Accounts (EOA vs contract accounts) in Blockchain / Solidity - Visual Side-by-Side Comparison

Concept Flow - Accounts (EOA vs contract accounts)

Start

↓

Check Account Type

↓

EOA

↓

Has Private Key

↓

Can Sign Tx

↓

Send Tx

↓

End

The flow checks if an account is an EOA or a contract account, then shows their key differences in behavior.

Execution Sample

Blockchain / Solidity

account = get_account(address)
if account.is_eoa():
    account.sign_transaction(tx)
else:
    account.execute_contract(tx)

This code checks the account type and either signs a transaction (EOA) or executes contract code (contract account).

Execution Table

Step	Action	Account Type	Condition	Result
1	Retrieve account by address	Unknown	N/A	Account object loaded
2	Check if account is EOA	EOA	account.is_eoa() == True	Proceed to sign transaction
3	Sign transaction	EOA	Can sign	Transaction signed by private key
4	Send transaction	EOA	Signed tx ready	Transaction sent to network
5	End process	EOA	N/A	Process complete
1	Retrieve account by address	Unknown	N/A	Account object loaded
2	Check if account is EOA	Contract	account.is_eoa() == False	Proceed to execute contract
3	Execute contract code	Contract	Has code	Contract logic runs with tx data
4	Return execution result	Contract	Execution done	Output or state changes returned
5	End process	Contract	N/A	Process complete

💡 Execution stops after transaction is signed and sent for EOA, or after contract code execution completes for contract accounts.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
account	None	Account object loaded	Account type identified	N/A	N/A
account_type	Unknown	EOA or Contract	N/A	N/A	N/A
transaction	Unsigned	Unsigned	Signed (EOA) or Executed (Contract)	Sent (EOA) or Result returned (Contract)	Complete

Key Moments - 3 Insights

Why can't contract accounts sign transactions like EOAs?

Contract accounts do not have private keys (see execution_table step 2 and 3 for EOAs), so they cannot sign transactions. Instead, they execute code when called.

What happens when a transaction is sent to a contract account?

The contract code runs with the transaction data (execution_table step 3 for contract accounts), producing outputs or state changes instead of signing.

How does the system know if an account is EOA or contract?

By checking if the account has code deployed (execution_table step 2). If code exists, it's a contract account; otherwise, it's an EOA.

Visual Quiz - 3 Questions

Look at the execution_table, what is the account type identified at step 2 when account.is_eoa() returns False?

A Contract Account

B Externally Owned Account (EOA)

C Unknown Account

D Miner Account

💡 Hint

Refer to execution_table row where account.is_eoa() == False at step 2

At which step does the transaction get signed for an EOA in the execution_table?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the action 'Sign transaction' for EOA in execution_table

If a contract account had no code deployed, how would the execution_table change at step 3?

A It would execute contract code as usual

B It would fail or do nothing because no code exists

C It would sign the transaction instead

D It would become an EOA automatically

💡 Hint

Check key_moments about how contract accounts require code to execute

Concept Snapshot

Accounts in blockchain are either EOAs or contract accounts.
EOAs have private keys and sign transactions.
Contract accounts have code and execute logic on transactions.
System checks code presence to distinguish account type.
EOAs send signed transactions; contracts run code and update state.

Full Transcript

This visual execution shows how blockchain accounts work. First, the system loads an account by address. Then it checks if the account is an Externally Owned Account (EOA) or a contract account by seeing if code exists. EOAs have private keys and sign transactions before sending them to the network. Contract accounts do not have private keys; instead, they execute their code when a transaction is sent to them. The execution table traces these steps for both account types, showing how variables like account type and transaction state change. Key moments clarify why contract accounts cannot sign transactions and how the system distinguishes account types. The quiz tests understanding of these steps and concepts. This helps beginners see the difference between EOAs and contract accounts clearly and follow the transaction flow visually.

Practice

1. Which of the following best describes an Externally Owned Account (EOA) on a blockchain?

easy

A. An account that can only receive tokens but not send them.

B. An account that only stores data but cannot send transactions.

C. An account that automatically executes code when called.

D. An account controlled by a private key, used by people to send transactions.

Solution

1. Step 1: Understand what an EOA is

   An EOA is controlled by a private key and represents a user or person on the blockchain.

2. Step 2: Identify EOA capabilities

   EOAs can send transactions and initiate actions, unlike contract accounts which run code.

3. Final Answer:

   An account controlled by a private key, used by people to send transactions. -> Option D

4. Quick Check:

   EOA = user-controlled account [OK]

Hint: EOAs are user accounts with private keys [OK]

Common Mistakes:

• Confusing EOAs with contract accounts
• Thinking EOAs run code automatically
• Believing EOAs cannot send transactions

2. Which syntax correctly represents a contract account address in Solidity?

easy

A. address payable contractAddr = 0x1234567890abcdef1234567890abcdef12345678;

B. contractAddr = '0x1234567890abcdef1234567890abcdef12345678';

C. address contractAddr = 1234567890abcdef1234567890abcdef12345678;

D. address contractAddr = 0xGHIJKL7890abcdef1234567890abcdef12345678;

Solution

1. Step 1: Check Solidity address syntax

   Addresses must be hexadecimal starting with 0x and enclosed in proper type declaration.

2. Step 2: Validate each option

   The declaration 'address payable contractAddr = 0x1234567890abcdef1234567890abcdef12345678;' uses correct type and hex format. String assignments without type declaration are invalid, missing 0x prefix fails, and invalid hex characters like 'GHI' are not allowed.

3. Final Answer:

   address payable contractAddr = 0x1234567890abcdef1234567890abcdef12345678; -> Option A

4. Quick Check:

   Valid Solidity address syntax = address payable contractAddr = 0x1234567890abcdef1234567890abcdef12345678; [OK]

Hint: Solidity addresses start with 0x and use 'address' type [OK]

Common Mistakes:

• Omitting 0x prefix
• Using invalid hex characters
• Assigning address as a plain string without type

3. Consider the following Solidity code snippet:

address sender = msg.sender;
bool isContract = sender.code.length > 0;

What does isContract indicate?

medium

A. True if sender is an EOA, false if contract.

B. True if sender is a contract account, false if EOA.

C. Always true because msg.sender is a contract.

D. Always false because msg.sender has no code.

Solution

1. Step 1: Understand msg.sender.code.length

   This checks the length of the code at the sender's address; contracts have code, EOAs do not.

2. Step 2: Interpret the boolean value

   If code length > 0, sender is a contract account; otherwise, it's an EOA.

3. Final Answer:

   True if sender is a contract account, false if EOA. -> Option B

4. Quick Check:

   Code length > 0 means contract [OK]

Hint: Check code length to distinguish contract vs EOA [OK]

Common Mistakes:

• Assuming msg.sender is always EOA
• Confusing code length meaning
• Thinking EOAs have code

4. You have this Solidity function:

function sendEther(address recipient) public {
    recipient.transfer(1 ether);
}

When calling this function with an EOA address, it fails with an error. What is the likely cause?

medium

A. The recipient address is not payable, so transfer fails.

B. EOA addresses cannot receive ether.

C. The function lacks the payable modifier.

D. transfer() only works with contract accounts.

Solution

1. Step 1: Understand transfer() requirements

   transfer() requires the recipient address to be payable to receive ether.

2. Step 2: Analyze recipient type

   If recipient is declared as address (not address payable), transfer will fail even if it's an EOA.

3. Final Answer:

   The recipient address is not payable, so transfer fails. -> Option A

4. Quick Check:

   Use address payable for ether transfers [OK]

Hint: Use address payable to send ether [OK]

Common Mistakes:

• Thinking EOAs can't receive ether
• Missing payable keyword on function
• Assuming transfer only works with contracts

5. You want to write a Solidity function that sends 1 ether only if the recipient is an EOA (not a contract). Which code snippet correctly implements this check?

hard

A. require(recipient.balance > 0, "Recipient must have balance"); recipient.transfer(1 ether);

B. require(recipient.code.length > 0, "Recipient must be contract"); payable(recipient).transfer(1 ether);

C. require(recipient.code.length == 0, "Recipient must be EOA"); payable(recipient).transfer(1 ether);

D. require(msg.sender == recipient, "Sender must be recipient"); recipient.transfer(1 ether);

Solution

1. Step 1: Check recipient code length to identify EOA

   EOAs have no code, so recipient.code.length == 0 confirms EOA.

2. Step 2: Use require to enforce condition and transfer ether

   If recipient is EOA, convert to payable and transfer 1 ether safely.

3. Final Answer:

   require(recipient.code.length == 0, "Recipient must be EOA"); payable(recipient).transfer(1 ether); -> Option C

4. Quick Check:

   Code length 0 means EOA, then transfer [OK]

Hint: Check code length == 0 to confirm EOA before sending [OK]

Common Mistakes:

• Checking for code length > 0 to find EOAs
• Not converting address to payable before transfer
• Using balance check instead of code length