Wallet Creation and Import#

• Wallet creation

  Generally speaking, as long as you create a random number in [1,n), it can be considered a valid wallet private key. The wallet address calculated through keccak256 from the public key obtained by d*G is the on-chain wallet corresponding to the existence of this private key on the block chain. In other words, in theory, the wallet has always existed on the block chain; once you create a private key that can correspond to this address, you can activate and use it as its owner (assuming it has not been used by someone else).

  But if generating a wallet requires specially creating a random number every time, that is still a bit too troublesome, and it is also not easy to memorize a random 16-byte large number. So is there a simpler way to batch-create multiple wallets that follow a pattern, while also letting me recover them all at once with one unified and easy-to-remember piece of content? This is the HD wallet (Hierarchical Deterministic Wallet), or what can also be called the mnemonic wallet most commonly used today.

  It generates a set of mnemonic words and their seed through BIP-39, then derives m from the seed through BIP-32, and finally uses BIP-44 to batch-calculate and generate wallets according to the format m/44‘/60’/acc‘/0/i.

• Wallet recovery/import

  For an ordinary wallet, you only need to remember the private key string starting with 0x to recover it (if you have an amazing memory).

  For the more commonly used HD wallet, it recovers some commonly used addresses by following the derivation process above. The specific steps can connect seamlessly after generating the mnemonic through BIP-39.

Verification and Transactions#

If we classify wallet-initiated actions by whether they can directly change on-chain state, they can roughly be divided into two categories: verification and transactions.

• Verification

  Verification, as the name suggests and as mentioned in the previous blog, means signing a piece of EIP-191 content (usually in SIWE format) so that the service receiving the signature can verify wallet ownership. That is what it does.

  
  dreaife.tokyo

  An EVM wallet login interface for EOAs

  A practical EVM/EOA wallet login walkthrough covering connect wallet, SIWE-style messages, wagmi signing, nonce handling, and backend verification, explaining why login separates address connection from signature-based ownership proof.

  dreaife.tokyo/en/posts/evm-wallet-login/

  Of course, if a wallet could only do simple operations like signing, there would be too few things it could do. So EIP-712 appeared.

  By defining a consensus-based signing payload, users can authorize a DApp or another service simply through a signature, allowing it to initiate a transaction that calls an on-chain smart contract to execute the signed content. This makes it more convenient for users to control on-chain assets.

  Of course, there are also protocols like EIP-7702 that let EOA wallets gain capabilities close to contract wallets, but since the main focus here is EOA wallets, I did not look into it in depth.

• Transactions

  Transactions are the basic way for a wallet to actively change on-chain state. They usually contain basic fields such as to｜value｜data｜nonce｜gas｜chainId. By controlling the contents of these fields, wallet-initiated transactions can perform basic operations such as transfers, contract calls, and contract deployment.

Private Key Creation Flow for HD Wallets#

For a full process from generating mnemonic words to deriving a private key that can actually control a wallet address, the flow generally follows these steps.

• BIP-39 generates the mnemonic and seed
• BIP-32 derives the master key m from the seed
• BIP-44 then uses the derivation rule m/44’/60’/account’/0/i for Ethereum, deterministically deriving a private key through account and i

Each step is described in detail below.

Generating the Mnemonic and Seed#

Mnemonic generation

• Generate random entropy

  When BIP-39 generates mnemonic words, it first generates a 128/160/192/224/256-bit random number.

  These correspond respectively to 12/15/18/21/24 mnemonic words. Here we use 256-bit entropy, that is, generating a 24-word mnemonic, as the example.

• Run SHA-256 on the entropy to obtain a new 256-bit number

• Take a checksum of length ENT/32

  In other words, first calculate the checksum from the SHA-256 result, then take that many leading bits from the checksum result. For a 256-bit random number, this means taking the first 8 bits of the checksum.

• Concatenate entropy and checksum to get a 256-bit + 8-bit number, namely 264 bits

• Group this data by 11 bits, which gives 264/11 = 24 groups. This is also why 256 bits corresponds to 24 mnemonic words

• Then for each group, select the corresponding word from the BIP-39 wordlist of 2048 ($2^{11}$) words

• The resulting 24 words are the mnemonic words generally used in HD wallets

Next is the generation from mnemonic to seed

Here PBKDF2-HMAC-SHA512 is used to calculate a 512-bit seed. The specific calculation is as follows:

$PBKDF2-HMAC-SHA512(password=mnemonic ,salt="mnemonic"+password,iteration=2048,dkLen=64bytes)$

That is, the mnemonic as a utf8 byte stream is used as the password, and the salt is “mnemonic” + password, then HMAC-SHA512 is iterated 2048 times. The first U1 is calculated from the mnemonic, password, and block_index (U1=HMAC(password,salt || INT(block_index))). Starting from U2, each step uses the previously calculated $U_{i-1}$ as the key for HMAC-SHA512 calculation (U2=HMAC(password, U1)).

Thus the final result of the first block is result = U1 xor U2 xor … xor U2048. Since the 512-bit output is exactly the required length of 64 bytes, there is only one block, and the output result at this point is the seed generated according to the BIP-39 rules.

Deriving the Master Key m#

According to BIP-32, another round of HMAC-SHA512 encryption is performed on the seed calculated above to obtain I. The specific content is as follows.

$I = HMAC-SHA512(key = \text{``Bitcoin seed''}, data = seed)$

At this point, a 512-bit I is obtained. By splitting it into two halves of 256 bits each, we get the left and right parts.

The left part $I_L$ is used as the master private key; the right part $I_R$ is used as the master chain code.

They will be used in the next BIP-44 derivation calculation.

Deriving a Specific Key#

Next is how BIP-44 specifies deriving a specific key through BIP-32 from the master key along the path m/44’/60’/account’/0/i.

Since this starts entering the realm of group calculations on the secp256k1 elliptic curve, if you are not familiar with the basics, you are welcome to read my previous proof of the principles (

dreaife.tokyo

About an EOA Wallet Signature Verification and Related Content

A developer-focused guide to EOA wallet signature verification, covering secp256k1, ECDSA r/s/v signatures, public key recovery, keccak-256 address derivation, and how SIWE proves wallet ownership without exposing the private key.

dreaife.tokyo/en/posts/eoa-sign-verify/

• Derivation path m/44’/60’/account’/0/i

  First, let’s introduce what a derivation path actually is.

  A derivation path can be understood as a six-level tree rooted at the master key m, where each level is a $2^{32}$ number. But for this $2^{32}$ number, generally only half of it is used, namely $2^{31}$ numbers. This is determined by whether the number at each level has a ‘ hardened mark in the upper-right corner, which determines whether the number i at this level simply uses i ([0,$2^{31}$)) or uses i‘=i+$2^{31}$.

  At the same time, the hardened mark here also affects the calculation method when computing child nodes.

  As for the five levels after m, namely 44’/60’/account’/0/i, their meanings are:

  • 44‘: the purpose defined by BIP-44
  • 60’: the coin type used for Ethereum
  • account‘: the account number selected during derivation
  • 0: external chain, generally used for ordinary receiving addresses
  • i: the i-th address for each account

• non-hardened child node calculation method

  For the number i of a child node at a certain level, the child node’s I can be calculated using the parent node’s private key IL (called pPk below) and chainCode IR (called pCc below) with the following formula.

  $$I = HMAC-SHA512(key=pCc,data=(serP(pPk*G) || ser32(i))$$

  Here, $serP(pPk*G)$ means 0x02/0x03 || (pPkG)_x), where pPkG is the parent node’s public key. Whether it is 0x02 or 0x03 is determined by whether y/p-y of the calculated parent public key (mod p) is odd or even.

  For the obtained I, it is also split into left IL and right IR according to a length of 256 bits.

  The child private key of this child node is (IL+parent private key) mod n

  The child chain code of the child node is IR

• hardened child node calculation method

  For the number i’ of a child node at a certain level, the child node’s I can be calculated using the parent node’s private key IL (called pPk below) and chainCode IR (called pCc below) with the following formula.

  $$I = HMAC-SHA512(key=pCc,password=(0x00 || ser256(pPk) || ser32(i + 2^{31}))$$

  Here 0x00 means directly using the private key pPk, so there is no longer any need to judge the parity of the public key’s y value.

  For the obtained I, it is also split into left IL and right IR according to a length of 256 bits.

  The child private key of this child node is (IL+parent private key) mod n

  The child chain code of the child node is IR

• The final private key

  By deriving layer by layer according to m/44’/60’/account’/0/i, we finally reach the leaf node at address_index i. The child private key calculated at this selected node is the private key d of that account address. Its actual account address can be obtained by the usual keccak256 calculation of the private key d*G, taking the last 20 bytes.

  At the same time, for this address, EIP-55 provides a checksum method that converts an ordinary address into a mixed-case address for validation, ensuring the legality of the address format (checking string format/input errors).

  EIP-55 does not change the letters of the address itself; it only changes their case according to the keccak256 calculation result of that address. For the character at position i, if the address character is a-f and the corresponding i-th position in the keccak256 calculation result is ≥8, it is uppercased; otherwise it remains unchanged.

Transaction Structure#

For an ordinary EIP-1559/type2 transaction, the internal structure is roughly like this:

1
type: 0x02
2

3
chainId
4
nonce
5

6
maxPriorityFeePerGas
7
maxFeePerGas
8
gasLimit
9

10
to
11
value
12
data
13

14
accessList
15

16
signatureYParity
17
signatureR
18
signatureS

This is only a list of properties. An unsigned transaction is generally more like a JSON format:

1
{
2
  chainId: 1,
3
  nonce: 42,
4
  to: "0xContractOrEOA...",
5
  value: "1000000000000000000",
6
  data: "0x...",
7
  gasLimit: "21000",
8
  maxFeePerGas: "...",
9
  maxPriorityFeePerGas: "..."
10
}

After signing, r/s/v will appear just like the result of signing during verification, and they are appended to the end of the JSON above.

Then, according to the following structure, the transaction content and signature are encoded into a byte string as the raw signed trans action. The encoded transaction can then be sent to an RPC for broadcasting and prepared to go on-chain.

1
0x02 || rlp([
2
  chainId,
3
  nonce,
4
  maxPriorityFeePerGas,
5
  maxFeePerGas,
6
  gasLimit,
7
  to,
8
  value,
9
  data,
10
  accessList,
11
  yParity,
12
  r,
13
  s
14
])

The role of each field is:

• chainId: prevents the same transaction from being replayed on another chain
• nonce: the account transaction sequence number, preventing the same transaction from being executed repeatedly and also determining transaction order (note that this nonce is the nonce of the operating wallet on the current chain, and the nonce for the previous transaction must follow a +1 order)
• to: target address; empty means deploying a contract
• value: amount of native coin sent along with the transaction
• data/input: contract call calldata, or init code when deploying a contract
• gasLimit: the maximum amount of gas this transaction is allowed to consume
• maxFeePerGas: the highest unit price the user is willing to pay
• maxPriorityFeePerGas: the upper limit of the tip given to the validator/proposer
• signature: the EOA wallet’s signature over the transaction content

Fee Model#

The fee model is generally divided into these types:

Since the main consideration here is only the commonly used basic transactions today, the above structure is written with type2 as the reference.

The Lifecycle of a Transaction#

For a transaction, the content is generally constructed and signed when calling an application or within the wallet, and then the constructed transaction content is sent to an RPC to be broadcast on-chain. The rough flow is as follows:

Ordinary Wallet Ownership Verification Under the SIWE Standard#

This is where a wallet proves to a called service that the user has control over the wallet. For the specific content, you can refer to the blog linked above (

dreaife.tokyo

An EVM wallet login interface for EOAs

A practical EVM/EOA wallet login walkthrough covering connect wallet, SIWE-style messages, wagmi signing, nonce handling, and backend verification, explaining why login separates address connection from signature-based ownership proof.

dreaife.tokyo/en/posts/evm-wallet-login/

EIP-712, a Type of Verification That Can Authorize Contracts#

EIP-712 is an authorization verification method that expresses agreement with the 712 signed content. However, it is more similar to signing in a transaction: it signs parameters that need to call a contract, allowing the contract to be called for assets under your name (if the contract supports this kind of authorization). Of course, it is only a signature. If you ultimately want this signed content to change on-chain state, the service side still has to combine the signature and call content into a transaction and submit it to the contract targeted by the signature.

• Signing content

  The content to be signed generally has a format like this:

  1
  {
  2
    types: {
  3
      EIP712Domain: [
  4
        { name: "name", type: "string" },
  5
        { name: "version", type: "string" },
  6
        { name: "chainId", type: "uint256" },
  7
        { name: "verifyingContract", type: "address" }
  8
      ],
  9
      Permit: [
  10
        { name: "owner", type: "address" },
  11
        { name: "spender", type: "address" },
  12
        { name: "value", type: "uint256" },
  13
        { name: "nonce", type: "uint256" },
  14
        { name: "deadline", type: "uint256" }
  15
      ]
  16
    },
  17
    primaryType: "Permit",
  18
    domain: {
  19
      name: "DemoToken",
  20
      version: "1",
  21
      chainId: 1,
  22
      verifyingContract: "0xTokenContract..."
  23
    },
  24
    message: {
  25
      owner: "0xUser...",
  26
      spender: "0xDappOrRouter...",
  27
      value: "1000000000000000000",
  28
      nonce: 0,
  29
      deadline: 1710000000
  30
    }
  31
  }

  Here, types is used to define the data structure; primaryType is the main structure being signed, such as Permit, Order, Forward, or Request; domain specifies the scope where the signature applies; and message is the content actually authorized by the user.

• Flow from an EIP-712 signature to use

  For example, for a permit-type 712 signature, the owner signs to allow the spender address to spend value amount of tokens, valid until deadline, with nonce n. This authorization is then returned to the DApp as a signature. The DApp uses this authorization and content to initiate a transaction permit( owner, spender, value, deadline, v, r, s). After the called contract verifies that the signature matches the signed content, it applies changes according to the authorization content.

  The specific content is as follows:

  1. The protocol/contract first defines the signable structure Permit(owner, spender, value, nonce, deadline)
  2. The DApp constructs EIP-712 typed data Including types, domain, primaryType, and message
  3. The wallet displays the signing content The user sees which DApp, which chain, which contract, and what authorization content it is
  4. After the user confirms, the EOA private key signs The wallet calculates digest: keccak256(“\x19\x01” || domainSeparator || hashStruct(message)) Then signs out r/s/v
  5. The wallet returns the signature to the DApp/service side At this point, it has not gone on-chain, there is no gas, and there is no state change
  6. The DApp/relayer/other party constructs a transaction Passing the fields in message together with signature to the contract
  7. The contract reconstructs the same digest on-chain Then uses ecrecover / ECDSA.recover to recover the signer
  8. The contract checks whether the signature is valid Whether signer equals owner Whether nonce has not been used Whether deadline has not expired Whether chainId / verifyingContract / domain match
  9. After the checks pass, the contract executes the state change For example, setting allowance, filling an order, or executing a meta transaction
  10. The nonce is consumed Preventing the same signature from being reused

EOA/HD Wallet#

For wallet creation, the current implementation defaults to the same behavior as common wallets and the ethers library: it takes the 0th address key of the 0th account by default. The specific implementation is as follows, using the path m/44‘/60’/0‘/0/0. It mainly uses ethers Wallet to create with createRandom and to import directly with new/HDNodeWallet.fromPhrase.

1
const DEFAULT_DERIVATION_PATH = "m/44'/60'/0'/0/0";
2

3
function createWallet() {
4
  const nextWallet = ethers.Wallet.createRandom();
5
  selectWallet(nextWallet, "Created wallet");
6
}
7

8
function importWallet() {
9
  const nextWallet = new ethers.Wallet(importKey.trim());
10
  selectWallet(nextWallet, "Imported wallet");
11
}
12

13
function importSeedPhrase() {
14
  const phrase = seedPhrase.trim().replace(/\s+/g, " ");
15
  const nextWallet = ethers.HDNodeWallet.fromPhrase(
16
    phrase,
17
    "",
18
    DEFAULT_DERIVATION_PATH
19
  );
20
  selectWallet(nextWallet, `Imported seed phrase at ${DEFAULT_DERIVATION_PATH}`);
21
}

EIP-191 Ordinary Signature#

1
function personalSignEnvelope(message: string) {
2
  const byteLength = ethers.toUtf8Bytes(message).length;
3
  return `0x19 || "Ethereum Signed Message:\n${byteLength}" || utf8(message)`;
4
}
5

6
async function signMessage() {
7
  const activeWallet = requireWallet();
8
  const nextSignature = await activeWallet.signMessage(message);
9
  setSignature(nextSignature);
10
}
11

12
function verifyMessage() {
13
  const recovered = ethers.verifyMessage(message, signature);
14
  const digest = ethers.hashMessage(message);
15
  setRecoveredAddress(recovered);
16
}

EIP-712 Signature#

• Constructing and verifying signing content

  1
  const typedDomain = {
  2
    name: "EOA Wallet Lab",
  3
    version: "1",
  4
    chainId: BigInt(typedChainId || "1"),
  5
    verifyingContract: typedVerifier || ZERO_ADDRESS
  6
  };
  7
  
  8
  const typedTypes = {
  9
    LoginRequest: [
  10
      { name: "owner", type: "address" },
  11
      { name: "statement", type: "string" },
  12
      { name: "nonce", type: "string" },
  13
      { name: "deadline", type: "uint256" }
  14
    ]
  15
  };
  16
  
  17
  const typedValue = {
  18
    owner: wallet?.address || ZERO_ADDRESS,
  19
    statement: typedStatement,
  20
    nonce: typedNonce,
  21
    deadline: BigInt(typedDeadline || "0")
  22
  };
  23
  
  24
  async function signTypedData() {
  25
    const activeWallet = requireWallet();
  26
    const nextSignature = await activeWallet.signTypedData(
  27
      typedDomain,
  28
      typedTypes,
  29
      typedValue
  30
    );
  31
    setTypedSignature(nextSignature);
  32
  }
  33
  
  34
  function verifyTypedData() {
  35
    const recovered = ethers.verifyTypedData(
  36
      typedDomain,
  37
      typedTypes,
  38
      typedValue,
  39
      typedSignature
  40
    );
  41
    const digest = ethers.TypedDataEncoder.hash(typedDomain, typedTypes, typedValue);
  42
    setTypedRecovered(recovered);
  43
  }

• type2 transaction construction and signing

  1
  function buildTxRequest(): ethers.TransactionRequest {
  2
    return {
  3
      type: 2,
  4
      to,
  5
      value: ethers.parseEther(txValue || "0"),
  6
      data,
  7
      chainId: BigInt(txChainId || "1"),
  8
      nonce: Number(txNonce || "0"),
  9
      gasLimit: BigInt(txGasLimit || "21000"),
  10
      maxFeePerGas: ethers.parseUnits(txMaxFee || "1", "gwei"),
  11
      maxPriorityFeePerGas: ethers.parseUnits(txPriorityFee || "1", "gwei")
  12
    };
  13
  }
  14
  
  15
  async function signTransaction() {
  16
    const activeWallet = requireWallet();
  17
    const signed = await activeWallet.signTransaction(buildTxRequest());
  18
    const parsed = ethers.Transaction.from(signed);
  19
  
  20
    setRawTx(signed);
  21
    setTxHash(parsed.hash || "");
  22
  }
  23
  
  24
  function verifyRawTransaction() {
  25
    const parsed = ethers.Transaction.from(rawTx);
  26
    setTxHash(parsed.hash || "");
  27
    setTxSigner(parsed.from || "");
  28
  }

• Broadcasting transactions

  1
  async function broadcastTransaction() {
  2
    const signed = rawTx || (await requireWallet().signTransaction(buildTxRequest()));
  3
    const provider = new ethers.JsonRpcProvider(rpcUrl);
  4
    const parsed = ethers.Transaction.from(signed);
  5
  
  6
    const response = await provider.broadcastTransaction(signed);
  7
  
  8
    setRawTx(signed);
  9
    setTxHash(parsed.hash || response.hash);
  10
    setTxSigner(parsed.from || "");
  11
    setBroadcastHash(response.hash);
  12
  
  13
    const receipt = await provider.waitForTransaction(response.hash, 1, 60_000);
  14
  }