Cardano plutus script vs native script: when should you use each?

29 October 2026

Use a native script when your logic is simple enough to be expressed as a set of spending conditions without loops, state, or external data. Use a Plutus script when you need complex validation, access to blockchain history, or the ability to manage state across multiple transactions. The choice is not about which is "better" - it is about which fits the problem you are solving.

What both script types do

Both Plutus scripts and native scripts lock UTXOs on the Cardano ledger. A transaction that attempts to spend a locked UTXO must satisfy the script's validation rules. If the script rejects the spending attempt, the transaction fails.

The key difference is how each script evaluates those rules and what it can see when it does.

Native scripts: simple, cheap, predictable

A native script is a set of logical conditions written in JSON-like syntax. It can express:

• Signature checks - require one or more specific keys to sign.
• Time locks - allow spending only before or after a certain slot or timestamp.
• Combinations - AND, OR, and threshold-of conditions that nest these checks.

Native scripts are evaluated entirely by the ledger without any execution environment. There is no CPU budget, no memory budget, and no execution cost beyond the base transaction fee. The validation cost is fixed and minimal.

When to use a native script

• Timelock vaults - lock ADA until a future date.
• Multi-signature wallets - require 2-of-3 or 3-of-5 signatures.
• Simple membership tokens - allow spending only if a specific key signs.
• Crowdfunding escrows - release funds after a deadline or when a threshold of backers approves.

If your logic can be written as a combination of "who signs" and "when", a native script is almost always the right choice. It is cheaper to create, cheaper to spend from, and does not require you to run a Plutus node or manage datum.

Plutus scripts: complex, flexible, stateful

Plutus scripts are programs written in Haskell (compiled to Plutus Core) that run on the Cardano node during transaction validation. They have access to:

• The entire current transaction (inputs, outputs, fees, minting, etc.)
• The redeemer - data provided by the spender at the time of spending.
• The datum - data stored in the UTXO when it was created.
• The script context - includes the current slot, the transaction's validity interval, and some on-chain state.
• Minting policies - control token creation and burning.

Plutus validation consumes CPU and memory, and each transaction that invokes a Plutus script pays execution fees based on the resources the script uses. If a script hits its budget limits, the transaction fails.

When to use a Plutus script

• Decentralized exchanges - order books or AMMs that match trades based on price and quantity.
• Lending protocols - manage collateral ratios, interest accrual, and liquidation.
• NFT marketplaces - enforce royalty payments, auction mechanics, or buy-now pricing.
• Token vesting - release tokens on a schedule that depends on external state, not just time.
• Governance systems - validate votes based on token holdings and proposal deadlines.
• Any logic that reads or writes datum - if you need to store and update data inside a UTXO, you need Plutus.

The eUTXO Difference That Drives the Choice

Under the eUTXO model, a Plutus script does not have access to the global state of the ledger. It sees only the UTXO being spent, the redeemer provided, and the current transaction. This is why complex protocols often need multiple UTXOs and multiple transactions to coordinate state - each step locks a new UTXO with updated datum.

Native scripts have no datum at all. They cannot store or inspect any data beyond the transaction itself and the current time. That is their fundamental limit.

Cost Comparison Summary

The exact fees for Plutus scripts depend on the current protocol parameters. You can check the current minFeeA, minFeeB, priceMem, and priceStep values on the Cardano explorer for your target era.

Practical Decision Flow

1. Can your logic be expressed as a combination of signatures and time ranges? Yes → use a native script. No → continue.

2. Does your logic need to read or write data that changes between transactions? Yes → you need Plutus and a datum. No → continue.

3. Does your logic need to inspect the contents of other UTXOs or query historical transactions? Yes → you need Plutus, but note that on-chain scripts cannot query arbitrary history. You must design your protocol to pass necessary data in the redeemer or datum, and the script validates that data against the transaction context. No → continue.

4. Does your logic involve loops, recursion, or complex computation? Yes → Plutus is the only option. No → a native script may still work if the conditions are simple enough.

If you are still unsure, start with a native script. If it cannot express what you need, move to Plutus. There is no penalty for choosing native first, and the simplicity saves you development time and transaction costs.

Back to cardano