cooked-validators
Safe HaskellSafe-Inferred
LanguageHaskell2010

Cooked.Skeleton.Mint

Description

This module exposes the minting constructs used in a TxSkel and their associated utilities.

Synopsis

Documentation

type TxSkelMints = Map (Versioned MintingPolicy) (TxSkelRedeemer, NEMap TokenName (NonZero Integer)) Source #

A description of what a transaction mints. For every policy, there can only be one TxSkelRedeemer, and if there is, there must be some token names, each with a non-zero amount of tokens.

You'll probably not construct this by hand, but use txSkelMintsFromList.

data Mint where Source #

A description of a new entry to be added in a TxSkelMints. The users should be using lists of those (using txSkelMintsFromList) instead of building a TxSkelMints directly.

Constructors

Mint 

Instances

Instances details
PrettyCooked Mint Source #

Prints a minting specification

Example: > #abcdef - Redeemer: red - Reference script at: txOutRef - Foo: 500 - Bar: 1000

Instance details

Defined in Cooked.Pretty.Cooked

mint :: ToVersioned MintingPolicy a => a -> TxSkelRedeemer -> TokenName -> Integer -> Mint Source #

Additional helper to build some Mint in the usual minting case where a single type of token is minted for a given MP

burn :: ToVersioned MintingPolicy a => a -> TxSkelRedeemer -> TokenName -> Integer -> Mint Source #

Similar to mint but deducing the tokens instead

addMint :: TxSkelMints -> Mint -> TxSkelMints Source #

Add a new entry to a TxSkelMints. There are a few wrinkles:

  1. If for a given policy, redeemer, and token name, there are n tokens in the argument TxSkelMints, and you add -n tokens, the corresponding entry in the "inner map" of the policy will disappear (obviously, because all of its values have to be non-zero). If that also means that the inner map becomes empty, the policy will disappear from the TxSkelMints altogether.
  2. If a policy is already present on the argument TxSkelMints with a redeemer a, and you add a mint with a different redeemer b, the old redeemer is thrown away. The values associated with the token names of that policy are added as described above, though. This means that any pre-existing values will be minted with a new redeemer.

addMints :: TxSkelMints -> [Mint] -> TxSkelMints Source #

Adds a list of Mint to a TxSkelMints, by iterating over the list and using addMint

txSkelMintsToList :: TxSkelMints -> [Mint] Source #

Convert from TxSkelMints to a list of Mint

txSkelMintsFromList :: [Mint] -> TxSkelMints Source #

A smart constructor for TxSkelMints

txSkelMintsValue :: TxSkelMints -> Value Source #

The value described by a TxSkelMints

Orphan instances

Monoid TxSkelMints Source # 
Instance details

Semigroup TxSkelMints Source #

Combining TxSkelMints in a sensible way. In particular, this means that

Map.fromList [(pol, (red, NEMap.fromList [(tName, 1)]))]

and

Map.fromList [(pol, (red', NEMap.fromList [(tName, -1)]))]

will combine to become the empty TxSkelMints (and similar examples, where the values add up to zero, see the comment at the definition of addMint).

In every case, if you add mints with a different redeemer for the same policy, the redeemer used in the right argument takes precedence.

Instance details