Daml does yoga: an introduction to flexible controllers

One last insider look at Daml’s authorization system

In previous blog post, we discussed our introduction of conjunction choices to Daml. The novelty was that choices could be controlled by more than one party and each controller had to give their consent for the choice to be executed. Hence the name conjunction choice. Initially, the Daml Language Team promised to follow-up with the delivery of their dual, disjunction choices. However, it was never entirely clear what a disjunction choice actually is or what its syntax could look like. We embraced this lack of clarity as an opportunity to extend Daml with a new form of choices that is far more flexible than conjunction and disjunction choices in combination. We have termed the new language concept flexible controllers.

We are going to introduce flexible controllers in two blog posts. In this blog post, we focus on how flexible controllers can be used to model disjunction choices. In an upcoming post, we will demonstrate why and how they are more powerful than disjunction choices.

A Daml based system for suggesting features

Imagine you are working at a startup and the founders want to empower their employees to suggest new features for their product. The idea is that every employee can suggest features. Whenever one of the founders favors a feature, they can sponsor it and the person who suggested it gets assigned to implementing it. The founders of your startup are apparently very perceptive to new ideas and you easily convinced them to implement a system to manage this feature suggestion workflow in Daml. The full code of the example can be found in this GitHub Gist.

The essence of an assignment to implement a feature could be captured by the following template:

0_tE0zhonboztrlxc5The beginning of a template modeling a suggestion might look as follows:

0_8G_zLSNyrj997lG3We want to give each of the founders the opportunity to accept such a proposal. Thus, we need a choice which can be exercised by any of the founders. That's where a choice with flexible controllers and the new syntax for it come into play:

0_Dazy8tcPf6LZl-bBIn contrast to a regular choice, this choice is introduced by the choice keyword rather than a controller … can construction and the controller clause comes after the choice type. The main semantic difference is that the controller expression can refer not only to the template arguments but also to the choice arguments. In our example, that is the sponsor. The assert statement in line 27 ensures that exercising the choice only succeeds when the sponsor is actually a founder. Since the AcceptFeature choice can be exercised by any of the founders, i.e., by the first founder or the second founder or ..., we call it a disjunction choice.

To see the feature suggestion workflow in action, let us have a look at a scenario:

0_aPh2IxR0fRl5I6jMThe interesting part is lines 51 and 52. Eric submits a transaction which exercises the AcceptFeature choice with himself as the sponsor. This works fine because the sponsor is also the controller and hence Eric is both the submitter of the transaction and the controller of the choice. Other attempts to exercise the choice, like Yuval trying to force Shaul into sponsoring the proposal or Dr. Who trying to sponsor it themselves, are not expected to succeed and do indeed fail at run time.

A caveat regarding flexible controllers and privacy

There is one big caveat coming with flexible controllers: since the controllers of a choice which is introduced using the new syntax can depend on the choice argument, they are usually not known at the time when a contract instance of the corresponding template is created. Thus, the controllers of such choices are not automatically added to the list of observers. In our example above, we explicitly made the founders observers of the template for exactly this reason. If we had not done that, neither of the founders would have been able to actually see the contract instance they have a choice on.


Flexible controllers are a new Daml feature that allows for defining choices whose controllers are not yet determined at the time when a contract instance is created but only when they are actually exercised. A very prominent example of this pattern is disjunction choices, which have been introduced in this blog post. There are many more ways to use the full power of flexible controllers and we will present a few of them in a follow-up blog post.

Read the first story in this series

Join the community and download the Daml SDK at daml.com

This story was originally published 9 May 2019 on Medium

About the authors

Martin Huschenbett, Ph.D. - Senior Software Engineer – Daml Language Team, Digital Asset

Martin joined Digital Asset’s language engineering team in 2017, where he works on the Daml compiler and authorization checker. Previously, as a member of the trading systems team for the proprietary trading firm Jane Street Capital in London, he contributed to the research infrastructure used by the quantitative analysts and the monitoring systems for the compliance team.

Martin holds a Ph.D. from Technische Universität Ilmenau in Germany, where he worked as a research associate at the Department of Theoretical Computer Science. His academic work included research and teaching primarily in the fields of computational logic, automata theory and formal verification. He held a postdoctoral position at the Ludwig-Maximilians-Universität München prior to joining Jane Street Capital. @hurryabit

Shayne Fletcher, B.Sc. - Language Engineer – Daml Language Team, Digital Asset

Shayne joined Digital Asset’s language engineering team in 2018 where he works on the Daml compiler. Shayne has 20+ years of experience with C++ and OCaml. He has a deep understanding of programming language theory and a wealth of experience in finance and building language based-products. In a previous role with Bloomberg, Shayne led the team that built the BLAN language for modeling exotic derivative securities. @shayne_fletcher