Haskell

Haskell is a functional language with static types that expresses rules through functions and explicit data structures. Within Cardano it is connected to protocol development and Plinth, formerly called Plutus Tx, which uses a Haskell subset to create validators.

A validator decides whether a transaction satisfies specified conditions. The application constructing that transaction performs a different task: selecting inputs, calculating change, supplying data and requesting signatures. Separating these layers avoids assigning the contract responsibilities that belong to the integration and makes the complete operating flow easier to review.

Cardano's EUTXO model represents state through transaction outputs that can be consumed when their conditions are satisfied. A validator receives relevant transaction information alongside data such as the datum and redeemer, then checks the spending rules. Execution is evaluated within a resource budget.

Types help model states and transitions explicitly. An operation might allow opening, cancellation or settlement under different conditions. Describing these alternatives makes it possible to discuss behaviour before connecting the system to a wallet or payment service, including how invalid transitions will be rejected.

Haskell can be useful when a team works with complex rules and has functional programming experience. For escrow, a reference model can describe which participants authorise each transition and how amounts are conserved. Tests compare constructed transactions with those rules and explore combinations of inputs.

Formal verification requires a specification and a proof about particular properties. Using Haskell or compiling a validator does not mean that process has been completed. Testing scope should also include transaction construction, error handling and integration with external components that influence the actual user operation.

Haskell is not mandatory for every product built on Cardano. Other languages and tools, including Aiken, are available, and the frontend can use a separate stack. Selection depends on existing code, compiler support and the team's ability to review and maintain validators.

Before choosing it, prototype the most demanding operation: transaction size, execution budget and concurrent access to shared state. An elegant model may be impractical if every operation consumes the same output. Product architecture and transaction architecture need to be designed together and assessed against expected activity.