Creating and Importing a Wallet#

• Creating a wallet

  In general, any random number within [1,n) can serve as a valid wallet private key. The public key obtained from d*G is processed with keccak256 to derive a wallet address, which represents the existence of that private key on the blockchain. In other words, wallets theoretically already exist on the blockchain. Once you create a private key corresponding to one of these addresses, you can activate and use it as its owner—provided that nobody else is already using it.

  However, generating a wallet by creating a new random number each time is rather inconvenient, and remembering a random 16-digit large number is not exactly easy. Is there a simpler way to create multiple wallets following a consistent pattern while allowing all of them to be recovered at once using a single, memorable piece of information? This is where HD wallets—Hierarchical Deterministic Wallets—come in. They are also what we commonly refer to today as mnemonic wallets.

  They use BIP-39 to generate a mnemonic phrase and its seed, BIP-32 to derive the master key m from that seed, and finally BIP-44 to derive wallets in batches using a path in the format m/44‘/60’/acc‘/0/i.

• Recovering/importing a wallet

  For an ordinary wallet, you only need to remember the private key beginning with 0x to recover it—assuming you have an extraordinary memory.

  For the more commonly used HD wallet, frequently used addresses are recovered by following the derivation process described above. The process continues seamlessly from the mnemonic phrase generated through BIP-39.

Verification and Transactions#

If wallet actions are categorized according to whether they can directly change on-chain state, they can roughly be divided into verification and transactions.

• Verification

  As the name suggests, verification works as described in my previous blog post: the wallet signs an EIP-191 message, usually in SIWE format, allowing the service receiving the signature to verify ownership of the wallet.

  
  dreaife.tokyo

  An EVM Wallet Login Interface for EOAs

  React/wagmi EVM login walkthrough: wallet connection, server nonces, SIWE messages, signing, backend address recovery, and proof of control.

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

  Of course, if a wallet could only perform simple operations such as signing messages, the range of things it could do would be rather limited. This led to the introduction of EIP-712.

  By defining a mutually understood set of signed fields, users can authorize a DApp or another service through a signature alone. That service can then initiate a transaction that calls an on-chain smart contract to execute the signed intent, making it more convenient for users to control their on-chain assets.

  There are also protocols such as EIP-7702 that give EOA wallets capabilities close to those of contract wallets. However, because the main focus here is ordinary EOA wallet functionality, I did not explore that topic in depth.

• Transactions

  A transaction is the basic mechanism through which a wallet actively changes on-chain state. It generally contains fields such as to｜value｜data｜nonce｜gas｜chainId. By controlling these fields, a wallet can initiate transactions that perform basic operations such as transferring funds, calling contracts, and deploying contracts.

HD Wallet Private-Key Creation Process#

The process from generating a mnemonic phrase to deriving a private key that can actually control a wallet address generally follows these steps:

• BIP-39 generates the mnemonic phrase and seed
• BIP-32 derives the master key m from the seed
• BIP-44 defines the m/44’/60’/account’/0/i derivation rule used by Ethereum, deterministically deriving a private key from account and i

Each step is explained in detail below.

Generating the Mnemonic Phrase and Seed#

Generating the mnemonic phrase:

• Generate random entropy

  When generating a mnemonic phrase, BIP-39 first generates a random number containing 128/160/192/224/256 bits.

  These sizes correspond to mnemonic phrases containing 12/15/18/21/24 words, respectively. Here, we use 256-bit entropy, which produces a 24-word mnemonic phrase, as an example.

• Calculate SHA-256 over 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, and then take the first ENT/32 bits of that checksum. For a 256-bit random number, this means taking the first 8 bits of the checksum.

• Concatenate the entropy and checksum to obtain a 256-bit + 8-bit, or 264-bit, number

• Divide this data into 11-bit groups, producing 264/11 = 24 groups; this is why 256-bit entropy corresponds to a 24-word mnemonic phrase

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

• The resulting 24 words form the mnemonic phrase normally used by an HD wallet

Next comes the conversion from the mnemonic phrase to the seed.

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

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

The UTF-8 byte stream of the mnemonic phrase is used as the password, while the salt is “mnemonic” + password, and HMAC-SHA512 is performed for 2048 iterations. The first value, U1, is calculated from the mnemonic phrase, password, and block_index (U1=HMAC(password,salt || INT(block_index))). Starting from U2, each HMAC-SHA512 operation uses the previously calculated $U_{i-1}$ as its input (U2=HMAC(password, U1)).

The final result for the first block is result = U1 xor U2 xor … xor U2048. Because the 512-bit output already matches the required length of 64 bytes, only one block is needed. This result is the seed generated according to BIP-39.

Deriving the Master Key m#

According to BIP-32, another HMAC-SHA512 operation is performed on the seed calculated above to obtain I:

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

This produces a 512-bit value I. It can be divided into two 256-bit halves.

The left half, $I_L$, becomes the master private key, while the right half, $I_R$, becomes the master chain code.

Both are used in the subsequent BIP-44 derivation calculations.

Deriving a Specific Private Key#

Next, we look at how BIP-44 specifies the derivation of a particular private key from the master key along the m/44’/60’/account’/0/i path using BIP-32.

Because this starts to involve group operations on the secp256k1 elliptic curve, anyone unfamiliar with the fundamentals is welcome to read my previous explanation and proof (

dreaife.tokyo

EOA Wallet Signature Verification and Related Topics

How secp256k1 math produces ECDSA r/s/v signatures and public-key recovery, enabling SIWE servers to verify EOA control without private keys.

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

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

  First, let us explain what a derivation path actually is.

  A derivation path can be understood as a six-level tree rooted at the master key m, with $2^{32}$ possible indices at each level. In practice, only half of them—$2^{31}$ indices—are generally used. Whether an index is interpreted directly as i ([0,$2^{31}$)) or as i‘=i+$2^{31}$ depends on the hardened marker ‘ displayed after the number at that level.

  The hardened marker also affects how child nodes are calculated.

  The five levels following m in 44’/60’/account’/0/i have the following meanings:

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

• Non-hardened child-node calculation

  For the index i of a child node at a given level, the child value I can be calculated from the parent node’s private key IL, referred to below as pPk, and its chain code IR, referred to below as pCc, using the following formula:

  $$$$

  Here, $serP(pPk*G)$ means 0x02/0x03 || (pPk*G)_x. pPk*G is the parent node’s public key, and whether 0x02 or 0x03 is used depends on whether the y or p-y value of the calculated parent public key (mod p) is odd or even.

  The resulting I is again divided into left and right 256-bit halves, IL and IR.

  The child private key is then (IL+parent private key) mod n.

  The child chain code is IR.

• Hardened child-node calculation

  For the index i’ of a child node at a given level, the child value I can be calculated from the parent node’s private key IL, referred to below as pPk, and its chain code IR, referred to below as pCc, using the following formula:

  $$$$

  Here, 0x00 means that the private key pPk is used directly, so there is no longer any need to determine whether the public key’s y coordinate is odd or even.

  The resulting I is again divided into left and right 256-bit halves, IL and IR.

  The child private key is then (IL+parent private key) mod n.

  The child chain code is IR.

• The resulting private key

  By deriving each level along m/44’/60’/account’/0/i, we eventually reach the leaf node at address_index i. The child private key calculated for this selected node is the private key d of that account address. Its actual account address can be obtained through the ordinary process of calculating d*G, applying keccak256, and taking the final 20 bytes.

  The address can also be converted into a mixed-case address using the EIP-55 checksum. This validates the address format and helps detect formatting or input errors.

  EIP-55 does not change the letters in an address. It only changes their capitalization according to the address’s keccak256 result. If the character at position i is between a and f and the corresponding character in the keccak256 result is ≥8, it is converted to uppercase; otherwise, it remains unchanged.

Transaction Structure#

An ordinary EIP-1559/type 2 transaction has roughly the following internal structure:

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 generally resembles JSON more closely:

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, it produces r/s/v values just like a verification signature, which are then appended to the end of the JSON shown above.

The transaction content and signature are then encoded into a byte sequence according to the following structure, producing a raw signed transaction. The encoded transaction can be sent to an RPC endpoint for broadcasting and eventual inclusion 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
])

Each field has the following purpose:

• chainId: prevents the same transaction from being replayed on another chain
• nonce: the account’s transaction sequence number, which prevents the same transaction from being executed repeatedly and determines transaction order. Note that this nonce belongs to the operating wallet on the current chain and must increment by 1 from the previous transaction’s nonce
• to: the destination address; an empty value indicates contract deployment
• value: the amount of native currency sent with the transaction
• data/input: the calldata for a contract call, or the init code when deploying a contract
• gasLimit: the maximum amount of gas the transaction is allowed to consume
• maxFeePerGas: the highest per-gas price the user is willing to pay
• maxPriorityFeePerGas: the maximum tip paid to the validator/proposer
• signature: the EOA wallet’s signature over the transaction content

Fee Models#

The fee models are generally divided into the following types:

Because this article primarily considers the basic transactions commonly used today, the structure above is based on type 2 transactions.

Transaction Lifecycle#

A transaction is generally constructed and signed while interacting with an application or directly inside a wallet. The completed transaction is then sent to an RPC endpoint for broadcasting and inclusion on-chain. The approximate process is as follows:

Ordinary Wallet-Ownership Verification Using the SIWE Standard#

This allows a wallet to prove to a service that the user controls it. For details, refer to the blog post linked above (

dreaife.tokyo

An EVM Wallet Login Interface for EOAs

React/wagmi EVM login walkthrough: wallet connection, server nonces, SIWE messages, signing, backend address recovery, and proof of control.

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

EIP-712: Verification That Can Authorize a Contract#

EIP-712 is a form of authorization verification in which the signer agrees to the contents of an EIP-712 message. It resembles a transaction signature: the user signs parameters intended for a contract call, authorizing the contract—if it supports this kind of authorization—to operate assets belonging to the user. Of course, this is still only a signature. To make the signed content change on-chain state, the service must combine the signature and call data into a transaction and send it to the contract targeted by the signature.

• Signature content

  The signed content generally follows this format:

  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 defines the data structures; primaryType specifies the primary structure being signed, such as Permit, Order, Forward, or Request; domain defines the scope in which the signature is valid; and message contains the actual authorization granted by the user.

• The process from an EIP-712 signature to its use

  For example, with a Permit-style EIP-712 signature, the owner signs an authorization allowing the spender address to spend a specified value of tokens until the deadline, using nonce n. This authorization is returned to the DApp as a signature. The DApp then initiates a transaction containing the authorization and its data through permit( owner, spender, value, deadline, v, r, s). After the contract verifies that the signature matches the signed content, it applies the change specified by the authorization.

  The complete process is as follows:

  1. The protocol/contract first defines a signable structure
     Permit(owner, spender, value, nonce, deadline)
  2. The DApp constructs the EIP-712 typed data
     including types, domain, primaryType, and message
  3. The wallet displays the signature content
     the user can see which DApp, chain, and contract are involved, as well as what is being authorized
  4. After the user confirms, the EOA private key signs it
     the wallet calculates the digest:
     keccak256(“\x19\x01” || domainSeparator || hashStruct(message))
     and then produces r/s/v
  5. The wallet returns the signature to the DApp/service
     nothing has been submitted on-chain yet, no gas has been consumed, and no state has changed
  6. The DApp/relayer/another party constructs a transaction
     passing the fields from message together with the signature to the contract
  7. The contract reconstructs the same digest on-chain
     and uses ecrecover / ECDSA.recover to recover the signer
  8. The contract checks whether the signature is valid
     whether signer equals owner
     whether the nonce has not already been used
     whether the deadline has not passed
     whether chainId / verifyingContract / domain match
  9. Once the checks pass, the contract changes state
     for example, setting an allowance, filling an order, or executing a meta-transaction
  10. The nonce is consumed
      preventing the same signature from being reused

EOA/HD Wallets#

For wallet creation, the current implementation follows the defaults used by mainstream wallets and the ethers library: it selects the first address under the first account. Specifically, it uses the path m/44‘/60’/0‘/0/0 and primarily relies on ethers’ Wallet class—using createRandom to create a wallet, direct construction to import one, and HDNodeWallet.fromPhrase to import a mnemonic phrase.

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
}

Ordinary EIP-191 Signatures#

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 Signatures#

• Constructing and verifying the signature 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
  }

• Constructing and signing a type 2 transaction

  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 a transaction

  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
  }