Ethereum Transaction Confirmations - how many are enough?

Question

Is there a recommendation - or even some sort of unofficial "standard" - regarding how many Confirmations we should wait for before considering a Transaction successful/valid - and then updating our front-end dApps to reflect that?

I recall Binance reduced their confirmation number requirements from 30 to 12 (https://www.binance.com/en/support/articles/360030775291) - but what's the rule of thumb these days?

OR, what are some of the more important factors one should consider when trying to figure out what's best for their own use-case?

(My use-case is that I'm working on an ERC721 Token Minting contract, so I want to know how many positive Confirmations I should wait to receive after a token-minting Tx is submitted and approved, before I can assume with a good amount of certainty that said Tx will not later prove invalid for some reason.)

Answer 1

One is usually enough. And that is the standard default for on-chain applications.

If "good amount" for you refers to a very-high-value item or something where you expect miners to collude to take over your app, then let's talk, you have bigger problems than this.

The biggest concern about multiple transactions is when you are bridging across chains. Moving assets from one chain to another, or cashing out to fiat, requires some many confirmations. And 12 is a fair number to limit exposure. If you are processing over $100k USD per hour of transactions consider a higher number.

Answer 2

I wrote a script a while back that looks at the lengths of the last 25,000 ephemeral chain forks (i.e. reorg depths). Re-running it gives:

Forks of length 1: 24631
Forks of length 2: 364
Forks of length 3: 5

[This covers the time period of approximately the last 280 days, up to today.]

I remember noticing fork lengths of 4 on previous runs, and at least in the early days of the network, much longer forks were common.

I think you would be unlucky for a transaction to be in an invalidated block and not be in the corresponding (same block number) valid block or any subsequent blocks.

But I don't think there's a guarantee that transactions from invalidated blocks will later be included in the chain... So it's probably better to be safe than sorry.