Cardano is a proof-of-stake blockchain whose smart contracts follow the extended UTXO (eUTXO) model rather than the account model of the EVM. A contract does not hold a balance and execute actions: it validates whether a transaction may spend the outputs it guards. For a project, this changes both the design of the application and what auditors have to check.
Building on Cardano
On-chain code consists of validator scripts that approve or reject transactions, and minting policies that control the creation of tokens. Each output locked by a script carries a datum (its state), and the spender provides a redeemer (the action). Because validators only check a transaction, a large share of the logic, building transactions, lives in off-chain code, which must be consistent with on-chain rules.
- Languages: Aiken, Plutus written in Haskell, and other languages that compile to Plutus Core
- Native tokens exist at the ledger level, without a token contract
- Not EVM-compatible
What auditors look at
- Datum handling: missing, malformed or unexpected datums, and outputs created with a datum an attacker controls
- Double satisfaction: one payment used to satisfy several validators in the same transaction
- Value checks: exact token amounts, extra tokens sent to a script output to block or bloat it, minimum ada requirements
- Minting policies: who can mint or burn, and whether a policy can be reused unexpectedly
- Concurrency on shared outputs and the correctness of the off-chain transaction builder
Before requesting quotes
- Specify the language and compiler version, and include the off-chain code if it builds transactions
- Describe every validator and minting policy, with its datum and redeemer types
- Provide tests, including property-based tests on adversarial transactions
- Explain how the application handles several users acting on the same outputs