From cardano-dev-skills
Explains Cardano's extended UTxO model to developers, covering datums, redeemers, script contexts, and how validators differ from account-based smart contracts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cardano-dev-skills:explain-eutxoThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- Documentation lookup path: ${CLAUDE_SKILL_DIR}/../../docs/sources/ -->
Help developers understand Cardano's extended UTxO (eUTxO) model, especially those transitioning from account-based chains like Ethereum or from web2 backgrounds.
write-validator or build-transaction insteadexplain-cipdeploy-validator or the relevant infrastructure skillconnect-walletThere is no global mutable state. The blockchain is a set of unspent transaction outputs (UTxOs). Each UTxO is an independent, immutable unit containing:
A transaction consumes UTxOs as inputs and produces new UTxOs as outputs. State changes happen by consuming old UTxOs and creating new ones with updated datums.
Cardano validators are predicates: they return true or false. They do not modify state or call other contracts. A validator receives three arguments and decides whether the transaction is allowed:
The off-chain code (transaction builder) does all the computation: selecting UTxOs, constructing outputs, calculating values. The validator merely checks that the result is valid.
Every validator invocation receives exactly these three pieces of data:
| Component | Provided by | Purpose |
|---|---|---|
| Datum | Attached to the UTxO at the script address | Represents current state |
| Redeemer | Supplied by the transaction spending the UTxO | Represents the action or intent |
| Script Context | Constructed by the ledger from the transaction | Full transaction view for validation |
Transactions are validated locally before submission. If validation passes locally, it will pass on-chain (assuming the UTxOs have not been spent by another transaction). This means:
When a developer comes from Ethereum, use these mappings to bridge understanding:
| Ethereum Concept | Cardano Equivalent | Key Difference |
|---|---|---|
| Smart contract | Validator (spending, minting, or withdrawing) | Validators are stateless predicates, not persistent programs |
| Contract storage | Datum on UTxOs at the script address | No global storage; state is per-UTxO |
| Function call | Redeemer | The redeemer encodes which "action" is being taken |
msg.sender | extra_signatories in script context | Must explicitly check that a required key signed the tx |
msg.value | Value in the transaction inputs/outputs | Explicitly check value flow in the script context |
| ERC-20 token | Native token (minting policy) | Tokens are ledger-native, no contract needed to transfer |
require() | expect / fail in Aiken | Pattern matching with expect is idiomatic |
| Contract-to-contract call | Multiple validators in one transaction | No re-entrancy; all validators run independently |
block.timestamp | Validity range (valid_after, valid_before) | Tx specifies a time window; validator checks the range |
| Mapping(address => uint) | Multiple UTxOs with datums, or a datum containing a data structure | No native key-value store; design around UTxOs |
| Events / logs | Datum content or transaction metadata | No native event system; off-chain indexers watch the chain |
| Constructor | Parameterized validator | Validators can take compile-time parameters |
| Proxy / upgradeable contract | Reference scripts (CIP-33) + governance pattern | Validators are immutable; upgradeability needs explicit design |
Determine:
Search the bundled documentation for relevant content:
${CLAUDE_SKILL_DIR}/../../docs/sources/plutus/ - Plutus docs${CLAUDE_SKILL_DIR}/../../docs/sources/aiken/ - Aiken language docs${CLAUDE_SKILL_DIR}/../../docs/sources/developer-portal/ - Cardano Developer PortalFor Ethereum developers, use the mapping table above. For web2 developers, use analogies:
Show when a developer encounters this concept. Examples:
Provide a minimal Aiken validator plus the off-chain interaction pattern:
// A simple vesting validator
validator vesting {
spend(
datum: Option<VestingDatum>,
_redeemer: Data,
_self: OutputReference,
tx: Transaction,
) {
expect Some(VestingDatum { beneficiary, deadline }) = datum
// Check that the beneficiary signed the transaction
let signed = list.has(tx.extra_signatories, beneficiary)
// Check that the deadline has passed
let deadline_passed = when tx.validity_range.lower_bound.bound_type is {
Finite(lower) -> lower >= deadline
_ -> False
}
signed && deadline_passed
}
}
Off-chain pattern (conceptual):
valid_after past the deadline| Concept | Quick Definition |
|---|---|
| Datum | Application data attached to a UTxO. Represents the "state" at a script address. |
| Redeemer | Data provided by the spender to indicate intent/action. The "key" to unlock. |
| Script Context | Full transaction data available to the validator during execution. |
| Validator | A predicate script that authorizes spending, minting, or withdrawing. |
| Reference Input | A UTxO included in the transaction for reading only (not consumed). CIP-31. |
| Reference Script | A script attached to a UTxO that other transactions can reference instead of including. CIP-33. |
| Collateral | A pure-ADA UTxO pledged to cover fees if script execution fails during phase-2 validation. |
| UTxO Selection | The off-chain process of choosing which UTxOs to use as transaction inputs. |
| Script Address | An address derived from a validator hash. UTxOs here are governed by the validator. |
| Stake Credential | A credential for staking/delegation, which can also be a script (enabling withdraw-zero). |
| Withdraw-Zero Pattern | A technique using a staking validator with a zero-ADA withdrawal to run validation logic once per transaction instead of once per input. Useful for batching. |
| Minting Policy | A validator that controls creation and destruction of native tokens. |
references/eutxo-vs-account.md — detailed comparison of eUTxO and account models../shared/PRINCIPLES.mdnpx claudepluginhub cardano-foundation/cardano-dev-skills --plugin cardano-dev-skillsProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.