Cardano Plutus and EUTxO Contracts
How Cardano's Extended UTXO (EUTxO) model differs fundamentally from Ethereum's account model, what writing Plutus contracts actually involves, and why concurrency on Cardano works differently.
EUTxO — Cardano's Foundation
Cardano extends Bitcoin's UTXO model into the Extended UTXO (EUTxO) model. Each UTXO can carry arbitrary data ('datum') and is governed by a validator script ('validator'). When a transaction tries to spend a UTXO, the validator script runs: it has access to the UTXO's datum, the transaction's structure, and a 'redeemer' supplied by the spender. If the validator returns true, the spend is allowed; otherwise it's rejected. Smart contracts on Cardano are validators that govern UTXOs.
Plutus as the Language
Plutus is Cardano's smart-contract platform. The on-chain language is Plutus Core (a typed lambda calculus); the off-chain language is Haskell (or, more recently, languages that compile to Plutus Core like Aiken). Most developers write Haskell that compiles to Plutus Core; the strong type system catches many bugs at compile time. The trade-off: Haskell's small developer pool relative to Solidity. The benefit: extremely well-typed, formally analysable contracts.
EUTxO vs Account Model — The Big Difference
In Ethereum's account model, the state of, say, an AMM is one mapping in one contract. All swaps modify that mapping. In EUTxO, the AMM's state is distributed across many UTXOs. A user's swap creates a transaction that consumes specific UTXOs (representing pool state and user funds) and produces new ones. Two users can't swap concurrently on the same UTXO — only one transaction per UTXO per block. This produces real architectural differences in how DeFi protocols are designed on Cardano.
- Cardano = EUTxO model, contracts are validator scripts attached to UTXOs
- Plutus = on-chain language (Plutus Core), with Haskell as off-chain dev language
- Concurrency works differently — one transaction per UTXO per block
- Strong type system enables formal verification; smaller developer pool
Key Takeaways
- Cardano uses EUTxO — a UTXO model with arbitrary data and validator scripts
- Plutus is the contract platform; Haskell is the primary developer language
- Concurrency on EUTxO is structurally different from account model — one tx per UTXO
- DeFi protocols are designed differently on Cardano to handle UTXO concurrency
Related Content
Related Coins
Related Topics
Key Terms
More Topics
Browse all 179 topicsSolana Programs and Anchor
How Solana's account model differs from Ethereum's, why Sealevel enables parallel execution, what makes Solana programs feel different to write, and where Anchor fits.
Move Language (Aptos and Sui)
Why Move's resource model fundamentally differs from Solidity, how Aptos and Sui evolved from the same Facebook-origin language, and what 'resources' mean for safety guarantees.
Cairo and StarkNet Contract Development
How Cairo as a language differs from Solidity and Rust, why account abstraction is native to StarkNet, and what writing production StarkNet contracts actually involves.
CosmWasm and Cosmos Smart Contracts
How CosmWasm enables smart contracts on Cosmos chains via WebAssembly, what makes the developer experience distinct from EVM, and why Cosmos's sovereign-chain architecture is a different bet from rollup-style scaling.
NEAR Contract Model
How NEAR's sharded execution, async cross-contract calls, and storage staking model differ from Ethereum and Solana — and what writing production NEAR contracts looks like.
ICP Canister Model
How Internet Computer (ICP)'s canisters fundamentally differ from Ethereum-style smart contracts — combining compute, storage, and HTTP-server-like functionality in a single on-chain primitive.
ERC-721A and Compressed NFTs
How gas-optimised NFT standards like ERC-721A made batch mints affordable, and how Solana state compression takes the same idea further by storing NFT data in Merkle trees off-chain.
ERC-6551 Token-Bound Accounts
How ERC-6551 lets NFTs own smart contract wallets that can in turn own other assets — enabling 'NFTs that own NFTs,' character-bound inventories, and new composability patterns.
References & further reading
- primary
- secondary