Factories for Lifecycling Rules

Questions
1

Is there a reason why the various lifecycling rules do not have factories?

This would require someone using daml-finance to depend directly on the concrete implementation packages rather than only on the interface ones (or implement an extra couple of packages with the factory interface and the factory template).

Thank you,
Daniel

2 Likes
2

Hi @drdo.intellecteu,

In our original thinking, the various lifecycling rules are akin to factories, in the sense that

  • the number of contract instances is generally small
  • they can be setup by running a one-off Daml script (that depends on an implementation package)
  • user workflows would reference the rule by their interface (thus not depending on an implementation package)

Hence we did not provide factories for those.

This is different to holdings or instruments, which need to be created / archived multiple times in user workflows.

If as a user you have a requirement to create / archive lifecycling rules in your Daml workflow, we can consider adding factories for the rules.

Matteo

3

What would be a typical way to use a Claim rule? In particular what would you pick for the claimers?

And for a Lifecycle rule, what would you pick for the lifecycler party?

I was thinking that many instances of theses rules would need to be created to account for these authorization requirements. Was the idea to have just one party doing the lifecycling for every Instrument and claiming the effects for every Holding?

4

The Claim rule is used to “claim” an effect for a Holding and generate Settlement Instructions. In a case where you have many holdings with a single custodian and multiple owners, you would pick the custodian as the claimer.

The lifecycler party in the Lifecycle rule is the party entrusted to lifecycle the instrument correctly. This party should provide the correct market data (e.g. NumericObservables) when calling the Evolve choice. In our examples it is typically one of the two parties signing the instrument.

When the Evolve choice also creates the new Instrument version, then the Lifecycle rule must be signed by both the instrument’s depository and issuer.

I agree with you that there is a trade-off between strong authorization + privacy vs number of instances of the Rule contracts.

In a case where very strict privacy guarantees are required, you might need to instantiate a number of Lifecycle and Claim rule contracts (respectively, one per (issuer, depository) pair and one per custodian), in which case factories are quite handy. I will raise an issue to track this item.

Thanks,
Matteo

2 Likes
5

Is this something that you envision being implemented in daml-finance in the near future, if at all?

Just to decide if I go with the concrete templates for now or if I implement the factories in our project.

Thanks,
Daniel

6

I discussed and concluded that this is something worth adding. The ticket to track is here: Add factories for `Lifecycle` and `Claim` rule contracts · Issue #682 · digital-asset/daml-finance · GitHub .

As for priorization earliest we can do it is for SDK 2.7, which is still some time out. So in the short term I’d suggest you implement the factories in your project, and you can then switch them out as and when they land in Daml Finance.

7

Alright! Thanks a lot @Matteo_Limberto and @georg !