I Need You to Authenticate This Claim#

Now that the address to authenticate is known, we can prepare a standard SIWE (Sign-In with Ethereum) login signature message. It looks roughly like this:

1
localhost:3000 wants you to sign in with your Ethereum account:
2
0xYourWalletAddress
3

4
Sign in to web3walletLogin with this wallet.
5

6
URI: http://localhost:3000
7
Version: 1
8
Chain ID: 1
9
Nonce: <server-issued nonce>
10
Issued At: <generated timestamp>

The message is then standardized according to EIP-191 so that it can be distinguished from other signatures and ordinary transactions:

"\x19Ethereum Signed Message:\n" + len(message) + message

The implementation uses wagmi’s signMessageAsync to send the actual authentication request to the wallet.

1
const { signMessageAsync, isPending: isSigning } = useSignMessage();
2

3
// make a siwe message
4
const siweMessage = new SiweMessage({
5
      domain: window.location.host,
6
      address,
7
      statement: "Sign in to web3walletLogin with this wallet.",
8
      uri: siteOrigin,
9
      version: "1",
10
      chainId,
11
      nonce
12
    });
13
const preparedMessage = siweMessage.prepareMessage();
14
// send sign request to wallet
15
const signature = await signMessageAsync({ message: preparedMessage });

Only My Private Key Can Produce This Proof#

When the wallet receives this message and authentication request, it must ensure that its signature can prove control over the address provided earlier. To do this, the wallet signs the hash of the message using its private key, while ensuring that the signature can still be verified by a website that knows only the wallet address and the requested message. Naturally, a series of mathematical transformations is needed to make this verification method work. For now, the implementation simply uses wagmi’s algorithm to verify the returned signature (

1
// use the message (the client send) and sign(the wallet back)
2
const verifyResponse = await fetch("/api/auth/verify", {
3
      method: "POST",
4
      headers: {
5
        "Content-Type": "application/json"
6
      },
7
      body: JSON.stringify({ message: preparedMessage, signature })
8
    });
9

10
// sign message verify
11
const siwe = new SiweMessage(body.message);
12
const result = await siwe.verify({
13
    signature: body.signature,
14
    domain: expectedDomain,
15
    nonce: siwe.nonce
16
  });
17

18
// the fail result
19
if (!result.success) {
20
    return NextResponse.json({ error: "invalid signature" }, { status: 401 });
21
  }

As for the actual verification math?

That brings us to the secp256k1 curve used for EOA wallet signatures. For an EOA wallet, it works roughly like this:

• EOA private key: a random number d of approximately 256 bits
• Public key: an elliptic-curve point Q = d * G
• Address: the last 20 bytes of keccak256(publicKey)
• Signature: ECDSA over secp256k1

I do not really understand the actual calculations here either, but my rough understanding is that the private key d cannot be reverse-engineered from the public key Q recovered using the signature and message hash because doing so would require solving the elliptic-curve discrete logarithm problem $Q = d * G$. For secp256k1, a 256-bit curve, this would require roughly $2^{128}$ operations.

Ultimately, the returned signature ($r + s + v$) and the hash of the message sent by the website can be used to recover a public key and derive its address. If that address matches the one provided earlier, it proves that the wallet controls the address.