Validation

Overview

Validation asks whether an input satisfies a defined set of rules. A node validates transaction structure, authorization, spendability, and consensus conditions. A block undergoes additional checks involving parent linkage, commitments, limits, and the result of executing its transactions.

Validation occurs at different times. A wallet can reject malformed input before signing, a peer can apply relay policy before forwarding, a block producer can select valid pending transactions, and every full node can independently verify the accepted block. Local policy can be stricter than consensus without changing protocol validity.

Payment applications need business validation beyond node acceptance. A technically valid transaction can use the wrong token, network, amount, destination, or invoice. The system should compare the observed transfer with the payment request and then apply confirmation and exception rules.

Validation is also different from authentication and authorization. A signature can authenticate control of a key, while business authorization determines whether that key is allowed to approve a payout. Correct format does not establish either permission or economic intent.

Reliable validation returns specific, stable error information and preserves the evidence used. It should be deterministic, tested with edge cases, and repeated at trust boundaries. Combining node checks with State Verification and Independent Verification provides stronger assurance for high-value operations.

Validation failures should be classified by layer. A malformed request, rejected signature, insufficient balance, reverted contract, wrong payment amount, and unsupported business state require different remediation. Stable error categories help users correct input while preventing the application from retrying permanent failures as if they were temporary outages.