12 Bestätigungen können einen festgelegten Schwellenwert erfüllen. Das bedeutet nicht automatisch, dass die Konsensfinalität erreicht ist.

Vor der Signierung einer Transaktion sollte die Richtlinie Folgendes festlegen:
• die Mindestanzahl an Bestätigungen;
• ob ein von RPC gemeldeter finalisierter Block erforderlich ist;
• die tolerierte Reorg-Tiefe.

Diese Kriterien beantworten unterschiedliche Fragen. In PriorSeal bedeutet CONFIRMATIONS, dass die festgelegte Anzahl erreicht wurde. RPC_FINALIZED prüft zusätzlich, ob der Inclusion-Hash weiterhin kanonisch ist, die vom Endpunkt gemeldete Finalisierungshöhe den Inclusion-Block abdeckt und die Mindestanzahl an Bestätigungen erreicht ist.

Kann der Endpunkt keine finalisierten Daten bereitstellen, bleibt die Ausführung PENDING. Ändert sich der kanonische Inclusion-Hash, wird der Status zu REORGED. Keiner der beiden Status allein beweist einen Verstoß gegen die Autorisierung.

Eine Reorg-Toleranz von N erfordert mindestens N+1 Bestätigungen. Sie ist ein Puffer und keine Garantie dafür, dass tiefere Reorgs unmöglich sind. Ein RPC-finalisierter Beleg hält die Beobachtung eines Endpunkts fest; er ist kein eingebetteter Konsensbeweis.

Was würden Sie in einem Agenten-Workflow voraussetzen: eine Mindestanzahl an Bestätigungen, ein RPC-finalisiertes Signal oder beides?