Skip to main content

Try it Live

Run Transaction examples in the interactive playground

Transaction Signing

Signature verification and sender address recovery using secp256k1.

getSender

Recover sender address from transaction signature.

Parameters

  • tx: Any - Signed transaction (any type)

Returns

AddressType - 20-byte sender address recovered from signature

Throws

  • Error("Transaction is not signed") - If transaction has zero r or s
  • Error("Unknown transaction type") - If transaction type is invalid
  • Error("Not implemented") - If type-specific recovery not implemented yet
  • Signature recovery errors for invalid signatures

Usage

Source: getSender.ts:12-27

verifySignature

Verify transaction signature is valid.

Parameters

  • tx: Any - Signed transaction

Returns

boolean - true if signature is valid, false otherwise

Usage

Source: verifySignature.ts

isSigned

Check if transaction has a signature.

Parameters

  • tx: Any - Transaction to check

Returns

boolean - true if transaction has non-zero r and s, false otherwise

Usage

Source: isSigned.ts:7-14

assertSigned

Assert transaction is signed (throws if not).

Parameters

  • tx: Any - Transaction to check

Throws

  • Error("Transaction is not signed") - If r or s is zero

Usage

Source: assertSigned.ts:6-13

Signature Components

Legacy Transactions

Legacy transactions use v/r/s signature format:
v value calculation:
  • Pre-EIP-155: v = 27 + yParity (yParity is 0 or 1)
  • Post-EIP-155: v = chainId * 2 + 35 + yParity
Example:

Typed Transactions (EIP-2930+)

All typed transactions use yParity/r/s format:
yParity directly encodes the recovery ID (0 or 1), no chain ID encoding needed.

Sender Recovery Process

  1. Get signing hash (transaction data without signature)
  2. Recover public key from signature using secp256k1
  3. Hash public key with keccak256
  4. Take last 20 bytes as address

Type-Specific Methods

Each transaction type has specialized methods:

Usage Patterns

Transaction Pool Validation

Authorization Check

Replay Protection

Batch Verification

Safe Sender Recovery

Signature Malleability

ECDSA signatures have malleability issue - for every valid signature (r, s), there’s another valid signature (r, -s mod n). Ethereum requires s value to be in lower half of curve order:
This is checked automatically in signature verification.

Performance Considerations

Signature recovery is expensive (elliptic curve operations):
For batch processing:

Implementation Status

Many methods currently throw “Not implemented” - check test files for implementation status.

See Also

EIP References