An EOA works through three deterministic operations: key generation produces a 256-bit private key, address derivation hashes the corresponding public key down to a 20-byte address, and transaction signing produces an ECDSA signature that any node can verify against the address. The Ethereum Virtual Machine exposes one verification primitive (ecrecover) that takes a signature and a hash and returns the address that signed it. Everything an externally owned account can do reduces to those three operations and that one primitive.
​

This article walks through the cryptography (ECDSA on secp256k1), the derivation chain from random number to Ethereum address, the structure of an EIP-1559 transaction, the signing procedure step by step, and how the EVM verifies signatures during transaction processing. The references are the RFC 6979 deterministic-signature specification and the EIP-2718 typed-transaction format.
​

EOAs use the Elliptic Curve Digital Signature Algorithm over the secp256k1 curve, the same combination Bitcoin uses. The SEC 2 specification defines the curve parameters: a prime field of order roughly 2^256, a generator point G, and a curve order n that bounds the private-key range.
​

The private key is a uniformly random integer d in the range [1, n-1]. The public key is the curve point Q = d * G, where * is elliptic-curve scalar multiplication. The discrete log problem on secp256k1 is what makes the system secure: given Q, recovering d is computationally infeasible at 128-bit security.
​

Ethereum uses the same curve but a different hash function from Bitcoin (keccak-256 instead of SHA-256). The hash difference means addresses derive differently, so the same private key controls different addresses on the two networks.
​

A wallet generates a private key by drawing 32 bytes of cryptographically secure randomness, interpreting them as a big-endian integer, and rejecting the value if it lies outside [1, n-1]. The probability of needing a redraw is vanishingly small, since n is only marginally smaller than 2^256.
​

Most wallets do not generate raw private keys directly. Instead, they generate a seed phrase under BIP-39: a 12-, 18-, or 24-word mnemonic encoding 128 to 256 bits of entropy. The seed phrase passes through PBKDF2 to produce a 512-bit seed, which feeds BIP-32 hierarchical deterministic key derivation. The standard Ethereum derivation path is m/44'/60'/0'/0/n, where n is the account index. EIP-2334 formalized the path conventions for Ethereum-specific use cases.
​

The result of this chain is that one seed phrase deterministically generates an unlimited sequence of private keys. MetaMask's "Account 1," "Account 2," etc. are sequential indices on the same derivation path. Ledger Live exposes the same accounts because the derivation is standard.
​

The public key Q is a point on the curve, encoded as 64 bytes (the X and Y coordinates concatenated, without the curve-prefix byte). The Ethereum address is the rightmost 20 bytes of the keccak-256 hash of those 64 bytes:
​

address = keccak256(public_key)[12:32]
​

The 20 bytes are conventionally written as a hex string with a 0x prefix. EIP-55 defines a checksum-encoding convention that mixes upper and lower case to provide a typo-detection capability without changing the underlying address. A wallet that does not implement EIP-55 will accept either case; modern dapps validate against the checksum to catch transcription errors.
​

The address space is 2^160, which is large enough that birthday-paradox collisions are computationally infeasible. Two distinct private keys produce two distinct addresses with overwhelming probability.
​

An Ethereum transaction (specifically an EIP-1559 type-0x02 transaction, which is the dominant format since the London hardfork in August 2021) has nine fields:
​

chain_id. The numeric identifier of the chain. 1 for Ethereum mainnet, 10 for Optimism, 42161 for Arbitrum, 8453 for Base. Including the chain ID in the signed payload prevents cross-chain replay.
​

nonce. The next outgoing transaction count for the EOA. The protocol enforces strict ordering: a transaction with nonce 5 cannot be included unless nonce 4 already has been.
​

max_priority_fee_per_gas. The tip the user pays to the validator on top of the base fee. Drives priority for inclusion.
​

max_fee_per_gas. The maximum total per-gas price the user is willing to pay. The actual price is min(max_fee, base_fee + priority_fee).
​

gas_limit. The maximum gas the transaction may consume. If execution exceeds this, the transaction reverts (but the user still pays for the gas consumed).
​

to. The recipient address. null for contract deployments.
​

value. The amount of wei to send.
​

data. The calldata. For a token transfer, this is the ABI-encoded transfer(address, uint256) call. For a contract deployment, this is the init code.
​

access_list. Optional list of addresses and storage keys the transaction will access, introduced in EIP-2930. Properly populating an access list reduces gas cost.
​

The wallet RLP-encodes the nine fields, prepends the type byte 0x02, and hashes the result with keccak-256. The hash is the message that gets signed.
​

The wallet then runs ECDSA signing per RFC 6979's deterministic k derivation: pick the per-signature nonce k as a deterministic function of the private key and the message hash, compute the curve point k * G, take its X coordinate modulo n as r, then compute s = k^-1 * (hash + r * d) mod n. The deterministic k rule prevents the catastrophic failure mode where two signatures with the same k reveal the private key (Sony PlayStation 3 had this bug; the consequences were widely documented).
​

The result is a triple (v, r, s) where v is a one-byte recovery indicator. The signature gets appended to the RLP-encoded transaction, producing the final signed transaction blob that goes to the mempool.
​

Hardware wallets perform this signing inside the secure element. The host computer sees the message hash and receives the signature back; the private key never leaves the device. Software wallets perform the signing in the host process, which is structurally weaker because any process with access to the wallet's memory can extract the key.
​

Verification is the inverse of signing. Given a signature (v, r, s) and a message hash, the EVM's ecrecover precompile (at address 0x01) returns the address that signed the hash. The protocol applies ecrecover to every incoming transaction: extract the signature, recover the signer, compare to the transaction's claimed sender. If they match, the transaction is authorized.
​

The same primitive is exposed to smart contracts. EIP-712 typed-data signatures use ecrecover in contracts to verify off-chain authorizations: a user signs a typed-data message, and the contract calls ecrecover on the message hash and signature to confirm the signer matches an expected address. This is how Uniswap's permit-based approvals, OpenSea's order signatures, and most off-chain authorization patterns work.
​

The verification cost is fixed: ecrecover consumes 3,000 gas per call regardless of signature properties. This is one of the reasons signature-based approvals are cheap relative to on-chain approvals.
​

The nonce in a signed transaction is what prevents replay attacks. A signed transaction with nonce 7 is valid for inclusion exactly once. After it is included, the EOA's account-state nonce increments to 8, and any subsequent transaction with nonce 7 is rejected by the protocol.
​

This has three consequences. First, transactions must be included in nonce order. A transaction with nonce 8 cannot be included before nonce 7. Second, a stuck transaction (one that the network refuses to mine because the gas price is too low) blocks every later transaction from the same EOA until it is replaced or canceled. Third, two transactions with the same nonce compete for inclusion; whichever lands first wins, and the other becomes invalid (this is how transaction "replacement by fee" works).
​

Smart wallets can implement custom nonce schemes, including parallel nonces (allowing multiple operations in flight) and 2D nonces (a key plus an index). EOAs are stuck with a strictly sequential single-counter nonce.
​

EIP-7702 does not change the signing or verification procedure for EOAs. The EOA still uses ECDSA on secp256k1, still derives an address from the public key, still generates signatures with deterministic k. What changes is what happens after a transaction reaches the EOA: under a 7702 delegation, calls to the EOA execute the delegated contract's bytecode, which can implement custom validation on top of the standard ECDSA verification.
​

The signing path the user sees is similar: the wallet asks for an ECDSA signature over a message hash, which the user approves on hardware. The difference is the message hash structure: a 7702 authorization signs a tuple (chain_id, contract, nonce) rather than a regular transaction. Wallets render the authorization fields explicitly so users see what is being delegated. See the EIP-7702 reference for the full mechanism.
​

An EOA on Ethereum produces signatures one transaction at a time, in nonce order, with no programmable batching. Cross-chain stablecoin movement traditionally required several signed transactions: approve, bridge, swap, settle. Eco is the stablecoin execution network that collapses that into one user-side signature across 15 chains. The user signs an intent. Eco's solver network selects between Circle CCTP, Hyperlane, LayerZero, and Wormhole rails to handle the cross-chain execution. Eco Accounts is the standardized smart-account layer that pairs with EOAs to make multi-chain stablecoin operations one signature regardless of how many chains and rails are involved underneath. The signing model the user sees stays familiar; the orchestration sits behind the API.
​

A private key is a 256-bit integer that controls one Ethereum address. A seed phrase is a 12 to 24-word mnemonic that, through BIP-39 and BIP-32, deterministically generates an unlimited sequence of private keys. One seed phrase backs up many accounts. Wallets typically expose accounts as sequential indices on the standard derivation path m/44'/60'/0'/0/n.
​

Both chains use ECDSA on secp256k1 for signing, but they hash the public key differently to derive addresses. Bitcoin uses RIPEMD-160 over SHA-256. Ethereum uses keccak-256 and takes the rightmost 20 bytes. The same private key gets two different addresses because the address-derivation step is different.
​

In principle, yes. The address space is 2^160 and the private-key space is roughly 2^256, so by the pigeonhole principle there exist private keys that map to the same address. In practice, finding such a collision is computationally infeasible at 2^80 work, far beyond any current adversary's capability.
​

The zero address (0x0000...0000). The protocol rejects any transaction whose recovered sender is the zero address, since no one can hold the private key for that address. Smart contracts that call ecrecover directly need to check explicitly for the zero-address return to avoid treating an invalid signature as a valid one signed by a non-existent address.
​

The wallet queries the RPC node's eth_getTransactionCount method, which returns the EOA's current nonce. For the next transaction, the wallet uses that count. Wallets that submit multiple transactions in flight track pending nonces locally and increment past the on-chain count to maintain correct ordering. Stablecoin API latency often comes back to nonce-management coordination.
​