Free technical resource
Aiken Validator Review Checklist
A practical checklist for reviewing Cardano validator purpose, authorization, value conservation, datum and redeemer design, transaction context, tests, and release evidence.
Purpose and state model
A reviewer should be able to state what the validator protects before reading implementation details.
- The validator purpose and protected assets are stated in one paragraph.
- Every datum field has a documented meaning and ownership rule.
- Every redeemer represents a distinct action rather than an ambiguous mode flag.
- Allowed state transitions are enumerated, including terminal states.
- Invariants are written separately from implementation steps.
Authorization and security boundaries
Signatures are only one authorization mechanism; connect every authority check to the state and value it controls.
- Each action names the required signer, credential, token, or script authority.
- Authorization checks cannot be satisfied by an unrelated input or output.
- Privileged credentials cannot be duplicated or substituted by an arbitrary asset.
- Validity ranges use explicit boundary semantics.
- No branch falls through to success when a redeemer or datum shape is unexpected.
Value and asset accounting
Review the complete transaction, not only the script input currently being spent.
- Value entering and leaving the contract is accounted for by asset and quantity.
- Continuing outputs are identified by a condition that cannot be confused by extra outputs.
- Minting and burning rules bind policy actions to the intended transaction conditions.
- Minimum ADA, fees, and change outputs are treated as off-chain concerns without weakening on-chain rules.
- Tests cover extra assets, duplicate candidate outputs, and unexpected token names.
Transaction context
Cardano validators inspect a transaction assembled off-chain. Confirm which context fields the contract trusts.
- Input references are used where identity matters.
- Output addresses and credentials are compared at the correct level.
- Reference inputs cannot silently replace consumed state when consumption is required.
- Datums are handled consistently as inline data or hashes.
- The validator does not depend on output ordering unless that ordering is explicitly guaranteed.
Tests and failure evidence
A success-path example proves very little. The strongest evidence is a set of failures tied to named invariants.
- Every redeemer has at least one valid and one invalid test.
- Each invariant has a test that fails when the invariant is violated.
- Boundary values are tested for quantities, timestamps, and collections.
- Tests include extra inputs, extra outputs, and reordered outputs.
- Property-based tests are considered for conservation, uniqueness, and state-transition properties.
- Failure messages or test names make the violated rule clear.
Off-chain delivery and release
A correct validator can still be unusable or unsafe when transaction construction diverges from its assumptions.
- The transaction builder documents how it discovers state UTxOs.
- Off-chain datum and redeemer encoders match the on-chain types.
- Wallet, network, collateral, and change-output failures are surfaced clearly.
- The compiled blueprint and validator hash are reproducible from a tagged source revision.
- Deployment addresses, network, compiler version, and parameters are recorded.
- A reviewer can trace each contract assumption to code, tests, and integration behavior.
What this checklist does not replace
This is a review structure, not an audit result. It does not prove correctness, evaluate protocol-specific economics, replace tests, or certify production readiness. Adapt it to the contract's threat model and current Aiken and Cardano versions.
For invariants that deserve machine-checked reasoning, use the Aiken and Lean 4 formal-methods workflow after this checklist has identified the contract boundary and proof targets.
Validate implementation details against the Aiken validator documentation and the relevant Cardano eUTxO documentation.