The Finance Library — Part 2

György Balázsi
Sep 30 · 4 min read
Image for post
Image for post
Photo by Ramón Salinero on Unsplash

In the first part of my two-part sub-series of this DAML Masterclass about the Finance Library, I started to reverse engineering the Financial Library reference application.

I have identified 5 Big Ideas in it, out of which I have presented 3 in the first part. Here are the remaining two ideas.

Big Idea #4: a dynamic set of signatories

This can be important because the signatories authorise in advance the choices of the contract.

This mechanism is working also in a simple propose/accept pattern, which makes it possible to create contracts signed by multiple parties.

The propose/accept pattern in general works like this: The proposal contract has a variable set a signatories. All necessary signatories of the final contract get added to the set of signatories step by step through the evolution (archival and creation) of the proposal contract instances. By the time all intended signatories have signed the proposal contract, they have authorised the creation of the final contract, containing a fixed set of signatories, which can be pulled off by any one of them. (See about this topic my previous blog post How DAML smart contracts are digital twins of human relationships.)

Something similar works in the case of a settlement chain, presented in the third section (Big Idea #3: multistep settlement chain) of the first part of this sub-series, where all intermediary senders of the individual steps want to authorise the transfer of their allocated funds (asset deposit contracts) in advance. This is the purpose of asset allocation.

This happens so, that those senders, who already have allocated their funds (members of the sendersDone list), become signatories of the next SettlementInstruction contract instance, while those senders who haven’t yet allocated their funds (members of the sendersPending list), become observers:


The members of the sendersDone and the sendersPending list are collected by the following list function, which uses the Either data type and the partitionEithers function:


The senders who have already allocated their funds can be recognized by the fact that they are senders of steps where the optional asset deposit contract id field has been filled in already, which is checked by the isSome boolean function. The partitionEithers function creates a partition based on the Either values so that it collects the Left a values into the first partition, and the Right a values into the second partition.

To make sure that you fully understand what the Either data type and the partitionEithers function does, check out a simplified version of the function in the DAML REPL. The DAML expression below partitions the odd and even values of a list. In order for it to work, we need to add the DA.Either library module.

daml> :m + DA.Eitherdaml> let odd (x : Int) = x % 2 == 1daml> let (oddMembers, evenMembers) = partitionEithers $ map (\x -> if odd x then Left x else Right x) [1..10]daml> oddMembers[1,3,5,7,9]daml> evenMembers[2,4,6,8,10]daml>

Big Idea #5: advanced ledger update: fetch and archive


But this function is conceptually important, for the following reason:

DAML ledger updates follow the UTXO model, so they are in some sense similar to Bitcoin’s operating model. Every ledger update is a transaction which has zero or more inputs, which may or may not be consumed by the transaction, and zero or more outputs.

DAML doesn’t have a ledger update transaction syntax separate from contract template syntax. Every ledger update gets performed on either a contract template with issuing a create command, or on an existing contract instance with the exercise <contract> <choice> command.

One might wonder, how a DAML ledger update transaction can consume two or more input contracts. And the answer is, that the update is programmed as a choice on a specific contract, and the choice needs to contain an update which fetches the other input(s) of the transaction, and archives them (of course, only if we want the input to be consumed). The standalone fetchAndArchive function is a shorthand for this important case. So a transaction for instance which consumes two existing contract instances as inputs, conceptually looks like the following:

Image for post
Image for post

In the subsequent parts of my DAML Masterclass series I will write about the following reference applications:

DAML Masterclass

How to draw inspiration with advanced DAML reference applications

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store