DEV Community

imokokok
imokokok

Posted on

Confirmations Are a Policy Threshold, Not a Finality Guarantee

#architecture #blockchain #crypto

A transaction reaches 12 confirmations. Can a reviewer call it final?

Only if the system defined what “final” means and recorded evidence for that claim.

A confirmation count answers one question

A confirmation floor tells us how many blocks have been built on top of an inclusion. It is a useful policy threshold, but it is not a universal statement about consensus finality.

The requirement should be part of the signed intent, before execution. For example:

{
  "constraints": {
    "minConfirmations": 12,
    "maxToleratedReorgDepth": 2,
    "finalityRequirement": "RPC_FINALIZED"
  }
}
Enter fullscreen mode Exit fullscreen mode

These fields express separate constraints. A reorg depth of N requires at least N + 1 confirmations, so the effective floor must satisfy both the configured minimum and the reorg buffer. The buffer does not guarantee that a deeper reorg is impossible.

What RPC_FINALIZED means here

PriorSeal’s observer checks the configured RPC endpoint for the inclusion block, the current canonical block at that height, the head, and the endpoint’s finalized block.

It records FINALIZED only when:

  • the inclusion hash is still canonical;
  • the finalized height covers the inclusion block; and
  • the configured confirmation floor is met.

If the endpoint cannot provide finalized data, the execution remains PENDING. If the canonical inclusion hash changes, it becomes REORGED.

That wording matters: RPC_FINALIZED records an endpoint’s observation. It is not an embedded consensus proof.

Keep uncertainty distinct from a policy violation

PENDING and REORGED describe evidence status. Neither one, by itself, proves that an agent violated its authorization.

An offline verifier can check the issuer’s signature and replay the recorded evidence and arithmetic. It does not refetch historical RPC state. A reviewer who needs independent assurance must separately assess or corroborate the RPC source and its claim.

If a later reorg changes the outcome, the system should preserve that event as a separate signed receipt rather than silently rewriting the earlier record.

Questions to settle before signing

  1. What confirmation floor does the policy require?
  2. Is an RPC-reported finalized block also required?
  3. What reorg depth is tolerated, and what happens if it is exceeded?
  4. Which endpoint supplied the finality observation?
  5. How will later changes be represented in the evidence record?

Finality criteria belong in the authorization policy before execution. A status label added afterward cannot tell a reviewer what the user actually approved.

For the implementation details, see the temporal finality design and the PriorSeal SDK guide.

Top comments (0)