# What number of confirmations is considered secure for Geth PoA Clique?

In Ethereum PoW the recommendation is to wait for 12 confirmations at least.

[Q]: What rules to apply for Geth PoA Clique algorithm?

My best guess so far:

lower limit: sum of confirmation block difficulties >= (floor(N/2) + 1) * 2

upper limit: sum of confirmation block difficulties <= N * 2

where N = number of sealers in the network

The reason that I'm multiplying with 2 is that in-order sealers are contributing 2 to the block difficulty, otherwise it's 1.

Update. After reading Castro/Liskov Paper on PBFT (http://pmg.csail.mit.edu/papers/osdi99.pdf), I beleive that the rule of `2*f + 1` confirmations for a `N = 3*f + 1` applies for Clique too. At least as lower limit. Upper limit could stay as is. See the comment below.

• There's an article by Vitalik blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times that examines the transaction confirmation time vs block times. It doesn't apply directly to PoA, but you can approximate it by the byzantinum fault tolerance model where the numbers of attackers is less than N/2.
– Ismael
Commented Sep 12, 2018 at 18:27
• I just read the Liskov Paper on pBFT. They state that in a system with n = 3*f + 1, 2*f + 1 confirmations are needed to ensure the consistency. I beleive that this applies to Clique too. I was able to construct an example with Clique where 50% + 1 confirmations were not sufficient for avoiding transaction removal on reorg. In PoW things seem to be diferent, since there is no fixed number of nodes, but rather a computational power involved. Hence it's about the computational race between fautly and honest nodes (->51%). Commented Oct 1, 2018 at 11:08

In this sense, the minimum number of confirmations will have to be: 66,6% + 1 [more precisely: `N - floor((N-1)/3)`] different sealers have confirmed the transaction, which is analogous to pBFT.