Rational in implementing multiple interfaces views in a template

What is the rational in implementing views of two separate interfaces in a template? How to visualize data being serialized under the hood? Is it template instance will preserve both views and can only be accessed by toInterfaceContractId for example “exerciseCmd (toInterfaceContractId @Participant.I cid) Participant.GetView with viewer = admin”

interface instance Disclosure.I for Instruction where
view = Disclosure.View with disclosureControllers = S.fromList [step.sender, step.receiver]; observers

interface instance Instruction.I for Instruction where
view = Instruction.View with requestors; settlers; signed; batchId; id; step; allocation; approval

Hi @code_monkey.

An interface definition includes a viewtype that defines its serializable part.

A template implementing two interfaces will need to define how both views are generated. One can then access each view by using toInterfaceContractId, as you suggest.

I believe that the rationale for this is an upcoming feature where you will be able to query for interfaces via the Ledger API and retrieve the corresponding interface views.

For instance, in your UI application you will be able to query for all contracts implementing the base Holding interface and print out the corresponding amount (which is defined in the view).


Can share some diagram how to visualize Interfaces, InterfaceContractId, Views etc?

Let me try to illustrate these concepts with an example drawn from the Daml Finance library.


These work similarly to what you would expect from interfaces in object-oriented programming:

  • an interface defines a set of methods and choices
  • a template that implements an interface needs to provide the implementation of the corresponding methods
  • when writing Daml code, we can access the choices via the interface

As an example, consider the setup in the picture below

We have two contracts on the ledger

Both templates implement the Base holding interface, which gives access to the GetView choice.

Only the Fungible holding implements the Fungible interface, which gives access to the Split and Merge choices.

Interface ContractId

Assume now that you want to write a new Daml template where the owner of a holding can claim a prize if the amount they hold is greater than 100.0.

You want to write generic code that works for both C1 and C2, given that they both have an amount and owner field. Specifically, you can write your template to work for any contract implementing the Base holding interface (which gives access to owner and amount fields via the GetView choice). In order to do that, we need a way to reference this set of templates: an interface ContractId.

Your new template will look as follows:

template ClaimPrize
  nonconsuming choice Claim : ContractId Prize
      ctrl : Party
      holdingCid : ContractId Base.I -- any contract that implements the base holding interface
    controller ctrl
      view <- exercise holdingCid GetView
      assert view.owner == ctrl
      if view.amount > 100 then create Prize with ... else abort ""

Interface Views

Finally, an interface view is just a special method which

  • must be defined for each interface
  • must return a serializable object

The reason why views are useful is explained in my post above.

I hope this helps you get a better understanding of the mechanics of interfaces in Daml. If you find this example useful, we could consider adding it to the Daml Finance documentation. I also encourage you to have a look at the Daml Finance getting started tutorial in case you haven’t done so.




1 Like