A transaction that can contain everything except key witnesses.

A transaction that has been witnesssed

Use when you do not have access to the UTxOs you intend to spend

A type used as a tag to distinguish the Babbage era.

A type used as a tag to distinguish the Conway era.

Represents the latest Cardano blockchain eras, including the one currently on mainnet and the upcoming one.

After a hard fork takes place, the era on mainnet before the hard fork is deprecated and, after a deprecation period, removed from cardano-api. During the deprecation period, cardano-api users should update their codebase to the new mainnet era.

Type class interface for the Era type.

An existential wrapper for types of kind k -> Type. It can hold any era, for example, Some Era. The era witness can be brought back into scope, for example, using this pattern:

anyEra = Some ConwayEra
-- then later in the code
Some era <- pure anyEra
obtainCommonConstraints era foo

Users typically interact with the latest features on the mainnet or experiment with features from the upcoming era. Therefore, protocol versions are limited to the current mainnet era and the next (upcoming) era.

How to deprecate an era:

1. Add the DEPRECATED pragma to the era type tag and constructor at the same time:

{-# DEPRECATED BabbageEra "BabbageEra no longer supported, use ConwayEra" #-}
data BabbageEra

2. Update the Haddock documentation for the constructor of the deprecated era, mentioning the deprecation.

data Era era where
  {-# DEPRECATED BabbageEra "BabbageEra no longer supported, use ConwayEra" #-}
  BabbageEra :: Era BabbageEra
  -- | The era currently active on Cardano's mainnet.
  ConwayEra :: Era ConwayEra

3. Add a new IsEra instance and update the deprecated era instance to produce a compile-time error:

instance TypeError ('Text "IsEra BabbageEra: Deprecated. Update to ConwayEra") => IsEra BabbageEra where
  useEra = error "unreachable"

instance IsEra ConwayEra where
  useEra = ConwayEra

Here we consider three types of witnesses in Cardano: * key witnesses * simple script witnesses * Plutus script witnesses

Note that AnyKeyWitnessPlaceholder does not contain the actual key witness. This is because key witnesses are provided in the signing stage of the transaction. However we need this constuctor to index the witnessable things correctly when plutus scripts are being used within the transaction. AnyWitness is solely used to contruct the transaction body.

This is a Plutus script witness. It possesses: 1. The plutus script or reference input 2. The script redeemer 3. The execution units 4. Potentially a script datum. See the PlutusScriptDatum type family for more details.

Note that Plutus script witnesses do not exist on their own. They must witness something and a redeemer pointer must be constucted to point to the thing being witnessed. See IndexedPlutusScriptWitness for more details.

This type collects all the requirements for script witnesses in a transaction.

These are all of the "things" a plutus script can witness. We include the relevant type class constraint to avoid boilerplate when creating the PlutusPurpose in the toPlutusScriptPurpose.

A simple script in a particular era. We leverage ledger's Cardano.Api.Experimental.ErasraScript type class methods to work with the script.

A Plutus script in a particular era. Why PlutusRunnable? Mainly for deserialization benefits. The deserialization of this type looks at the major protocol version and the script language to determine if indeed the script is runnable. This is a dramatic improvement over the old api which essentially read a ByteString and hoped for the best. Any failures due to malformed/invalid scripts were caught upon transaction submission or running the script when attempting to predict the necessary execution units.

Where do we get the major protocol version from? In order to access the major protocol version we pass in an era type parameter which can be translated to the major protocol version.

Where do we get the script language from? The serialized version of PlutusRunnable encodes the script language. See `DecCBOR (PlutusRunnable l)` in cardano-ledger for more details.

You can provide the plutus script directly in the transaction or a reference input that points to the script in the UTxO. Using a reference script saves space in your transaction.

A Plutus script witness along the thing it is witnessing and the index of that thing. E.g transaction input, certificate, withdrawal, minting policy, etc. A Plutus script witness only makes sense in the context of what it is witnessing and the index of the thing it is witnessing.

Every Plutus script has a purpose that indicates what that script is witnessing.

A family of singleton types used in this API to indicate which type to use where it would otherwise be ambiguous or merely unclear.

Values of this type are passed to deserialisation functions for example.

The transaction's redeemer pointer map allows the ledger to connect a redeemer and execution unit pairing to the relevant script. The ledger basically reconstructs the indicies (redeemer pointers) of this map can then look up the relevant execution units/redeemer pairing. NB: the redeemer pointer has been renamed to 'PlutusPurpose AsIndex' in the ledger.

To reduce boilerplate, we reuse the PlutusPurpose type from `cardano-ledger`. This type is utilized in constructing the redeemer pointers map, which links the redeemer and execution units with the entity being witnessed. The map is indexed by the redeemer pointer.

A natural question arises: How do Plutus scripts determine which execution units and redeemer are paired with them? The ledger constructs a redeemer pointer for every Plutus script, and this pointer corresponds to the one in the transaction's redeemer pointers map. For more details, refer to collectPlutusScriptsWithContext in `cardano-ledger`.

When it comes to using plutus scripts we need to provide the following to the tx:

1. The redeemer pointer map
2. The set of plutus languages in use
3. The set of plutus scripts in use (present in the t)
4. The datum map