12 confirmações podem satisfazer um limite configurado. Isso não significa automaticamente que a finalidade de consenso foi alcançada.

Antes de uma transação ser assinada, a política deve especificar:
• o número mínimo de confirmações;
• se é obrigatório que um bloco seja reportado como finalizado por RPC;
• a profundidade de reorganização tolerada.

Esses critérios respondem a perguntas diferentes. No PriorSeal, CONFIRMATIONS significa que o número configurado foi atingido. RPC_FINALIZED também verifica se o hash de inclusão ainda é canônico, se a altura finalizada informada pelo endpoint abrange o bloco de inclusão e se o mínimo de confirmações foi atingido.

Se o endpoint não puder fornecer dados de finalização, a execução permanece PENDING. Se o hash canônico de inclusão mudar, o status passa a REORGED. Nenhum dos dois status, por si só, comprova uma violação de autorização.

Uma tolerância de reorganização de N exige pelo menos N+1 confirmações. É uma margem de segurança, não uma garantia de que reorganizações mais profundas sejam impossíveis. Um recibo finalizado por RPC registra a observação de um endpoint; não é uma prova de consenso incorporada.

O que você exigiria em um fluxo de trabalho de agente: um mínimo de confirmações, um sinal de finalização por RPC ou ambos?