This typically ends up as boilerplate by defining a helper like this:

use aiken_design_patterns/linked_list

const node_key_prefix = "NODE"

const node_key_prefix_length =
  bytearray.length(node_key_prefix)

pub fn finalize_linked_list(
  eval: linked_list.Eval,
  list_nft_policy_id: PolicyId,
) -> Bool {
  linked_list.run_eval_with(
    eval,
    list_nft_policy_id,
    node_key_prefix,
    node_key_prefix_length,
  )
}

As an example, with this you’ll be able to turn your Eval results to Bools as such:

// In your minting contract:

let linked_list_eval = insert_ascending(...)

expect linked_list_eval |> finalize_linked_list(own_policy_id)

Initialize a linked list, i.e. produce a UTxO which contains some ADA and the authentication NFT, with a Root element data. The asset name of the NFT (i.e. RootKey) is something that must be validated by passing the result of this function to run_root_with.

Deinitialize an empty list.

The anchor element is inferred from inputs by requiring exactly one authentic linked list element input. It is assumed the address from which the anchor element comes from is the destination address for the new node.

The additional_validations argument provides you with 8 values:

1. Input of the anchor element
2. Change in Lovelace count from anchor input to continued anchor output
3. If the anchor element is a node, its key (i.e. asset name without the prefix) is provided
4. Underlying data of the anchor element – note that this can come from either a Root or a Node
5. Lovelace count of the new node UTxO
6. Key (i.e. asset name without the prefix) of the new node
7. Underlying data of the new node – note that this is extracted from a Node
8. Link of the new node

This is exactly like insert_ascending, with the exception that the inserted key is expected to be less than the anchor’s, and greater than anchor’s link (if any).

Append a new element at the very end of an unordered list. The anchor element is inferred from inputs by requiring exactly one authentic linked list element input. There is no comparison validation for the new key with respect to the anchor element’s, but the anchor must be terminal.

The additional_validations argument provides you with 7 values:

1. Input of the anchor element
2. Change in Lovelace count from anchor input to continued anchor output
3. If the anchor element is a node, its key (i.e. asset name without the prefix) is provided
4. Underlying data of the anchor element – note that this can come from either a Root or a Node
5. Lovelace count of the new node UTxO
6. Key (i.e. asset name without the prefix) of the new node
7. Underlying data of the new node – note that this is extracted from a Node

Prepend a new element at the very start of an unordered list. The root element is inferred from inputs by requiring exactly one authentic linked list element input. There is no validation for the new key to be less than or greater than the root element’s potential link.

The additional_validations argument provides you with 7 values:

1. Input of the root element
2. Change in Lovelace count from root input to continued root output
3. Underlying data of the root
4. Lovelace count of the new node UTxO
5. Key (i.e. asset name without the prefix) of the new node
6. Underlying data of the new node – note that this is extracted from a Node
7. Link of the new node

Remove a node. The anchor element is identified by its output reference, and the anchor and removing node are inferred from the transaction inputs. This operation assumes the list script/payment credential is dedicated to list elements, so the transaction must not include unrelated inputs at the same payment credential.

The additional_validations argument provides you with 9 values:

1. Input of the anchor element
2. Change in Lovelace count from anchor input to continued anchor output
3. If the anchor element is a node, its key (i.e. asset name without the prefix) is provided
4. Underlying data of the anchor element – note that this can come from either a Root or a Node
5. Input of the removing node
6. Lovelace count of the removing node UTxO
7. Key (i.e. asset name without the prefix) of the removing node
8. Underlying data of the removing node
9. Link of the removing node

Spend a root element and its link, reproduce the root while expecting the linked node to be burnt. The root is identified by its output reference. This traverses the whole inputs list and expects exactly two authentic list inputs at the list payment credential: the root input and the folding node input. This relies on the list spending validators preserving the invariant that list NFTs do not leave their list script/payment credential, and on the list script/payment credential being dedicated to list elements. Unrelated inputs at the same payment credential are intentionally rejected. Additionally, performs an arbitrary validation on keys and underlying data.

This function ensures:

• Authenticity of the two spent list inputs and root’s continued counterpart
• The anchor is root, and that it correctly points to the folding node
• The root is continued at the same address
• The continued anchor data remains a Root
• The folding node shares the root’s payment credential
• Folding node is burnt
• Root’s key is correct, and node’s key is prefixed as expected

The function you define for additional_validations is provided with 9 values (in order):

1. Input of the root element
2. Change in Lovelace count from input root to output
3. Underlying data of the root
4. Input of the folding node
5. Lovelace count of the folding node
6. Key (i.e. asset name) of the folding node
7. Underlying data of the folding node
8. Link of the folding node
9. Underlying data of the reproduced/continued root

Simply checks if there are any tokens getting minted/burnt in transaction’s mint field. How you provide list_nft_policy_id is most likely the “coupling” needed between the spending and minting endpoints.

For spending an individual element within a linked list and reproducing it with updated data, without affecting the structure of the linked list.

The continuation provides you with:

1. Change in Lovelace count from input to output (i.e. output minus input).
2. A possible node key (i.e. its asset name without the prefix). It’ll be None if the spent element is root.
3. Input underlying data.
4. Updated data in the reproduced element.
5. Element’s link.

The transaction’s mint is required to ensure no linked list assets are minted or burnt.

This should generally not be needed, but in cases where another script wants to validate expenditure from the linked list, this function can help.

After validating the authenticity of the provided element UTxO, it provides the continuation with:

1. Lovelace count of the element
2. A possible NodeKey (i.e. it will be None if the element UTxO is root)
3. Underlying data of the element
4. Element’s link

Unlike other helpers, this one returns an ElementEval<a>. This is very similar to Eval. However, the type variable a allows the final evaluation to result in any type rather than being restricted to Bool.