Cardano CIP-0195 sets Plutus V4 data encoding and picks lists over arrays

Victoria Shinder14 October 2026, 09:422 min read

The Cardano Improvement Proposals repository merged CIP-0195 "Data Encoding of Plutus V4 Ledger Types" on 13 October 2026, with status Proposed. Written by Ziyang Liu of IOG, with the IOG Plutus team listed as implementor, it specifies how the ledger API types of the next Plutus version — the script context and the types it refers to — are encoded as Data objects that smart contracts receive.

Why a CIP was needed at all. The proposal names three reasons. UPLC now has a built-in Array type with constant-time indexing, which raises the question of switching encodings. Plutus V1 to V3 carry known inefficiencies: every product type is wrapped in a redundant Constr 0 tag, and reaching a bound of an Interval or the credential inside a Maybe StakingCredential takes two layers of Constr where one would do. And in V1–V3 the encoding was never formally specified — the de facto specification was Template Haskell code in the plutus repository, which developers of alternative compilers had to reverse-engineer.

Lists, not arrays — and the counter-intuitive reasoning. The CIP concludes that List is clearly the better choice for encoding datatypes, despite arrays' constant-time access. First, list encoding needs no change to the Data type, while arrays would require two new constructors and four new built-ins — an invasive change for Plutus and for every other language and tool. Second, lists are usually faster in practice: thanks to the new dropList built-in, whose cost model has a low intercept and slope, list access stays faster than indexArray even for the 20th field — and TxInfo, the largest V4 constructor, has exactly 20 fields. Array encoding wins only in corner cases, such as reading a few widely separated fields of a large constructor. Third, building Data from lists avoids an extra listToArray conversion; the authors estimate that converting a 1,000-element list costs well under 1% of the per-transaction limit when an array is genuinely needed.

What else changes. Product types are encoded as a plain List [x1…xn] instead of Constr 0 [x1…xn], removing the pair-destruction overhead. On flattening nested types, the CIP is selective: the one obvious sum-type candidate, Maybe StakingCredential, disappears anyway because V4's Address carries a Maybe AccountId instead, and V4 also drops the over-nested Interval type in favour of a new one.

For contract authors the practical effect is that V4 scripts read their context through a documented encoding rather than one inferred from generated code, with a different layout from V1–V3 wherever product types or the new Address and interval types are involved.

Source: Cardano Foundation CIPs repository, CIP-0195 "Data Encoding of Plutus V4 Ledger Types" (merged 13 October 2026) — https://github.com/cardano-foundation/CIPs/commit/3d15c14da08d1fe22f61f717d50fc08eeb0baea1