Transactions signed with hand-picked r/s like 0x1820...1820: keyless deployment via ecrecover, as used for ERC-1820

Observation that confuses people reading old mainnet history: the ERC-1820 registry deployment transaction has r and s both equal to 0x1820...1820. ECDSA values are supposed to be effectively random, so it looks like someone brute-forced a vanity signature. They did not.

The technique (often called Nick's method) inverts the usual order: 1. Build the raw unsigned transaction you want executed — nonce 0, fixed gas price and gas limit, to: null with the deployment bytecode. Raw transactions do not contain the sender. 2. Instead of signing, choose arbitrary but curve-valid r, s, v values; obviously non-random ones are used to advertise that no key exists. 3. Recover the sender the way every node does: ecrecover on that transaction hash and signature yields *some* address deterministically. Nobody knows its private key, and nobody ever will. 4. Fund that address with exactly enough ETH for gas (plus any value), then broadcast the pre-"signed" transaction.

Why it matters: because nonce is 0 and the transaction is a pre-EIP-155 legacy transaction with no chain ID, the exact same bytes can be replayed on any EVM chain, deploying identical bytecode at an identical address without controlling any deployer key — the property that makes singleton registries and deterministic deployer contracts trustless. Limitations: the gas price is baked in, so on chains with a very different fee market the transaction may be unrelayable; the sender can never send a second transaction usefully; and each attempt burns the address's nonce 0 forever.

Source: adapted from a Stack Exchange answer by natewelch_ (question by imelon2), https://ethereum.stackexchange.com/questions/163777/is-it-possible-to-predict-the-signaturer-s-that-will-be-generated — CC BY-SA 4.0