Better Design Pattern To Pass Parties Information

Questions
1

What is the better design pattern to pass Parties in nested template creation? It seems like daml-finance relies on declaring and passing parties directly as parameters while daml-finance-app passing account contract instance as parameters?

template Offering
with
operator : Party
** provider : Party**
issuer : Party
public : Party
…
issuerAccount : Account.K
backToBack : Optional BackToBack
status : Status

2

Hi @code_monkey.

The latter example is using an account contract key data type within the template. The account key is defined as

-- | A unique key for Accounts.
data AccountKey = AccountKey
  with
    custodian : Party
      -- ^ Party providing accounting services.
    owner : Party
      -- ^ Party providing accounting services.
    id : Id
      -- ^ Unique identifier for an account.
  deriving (Eq, Ord, Show)

The advantage I see with this approach is that

  • it makes it clear to the reader that the template is linked to an account contract
  • the account key is readily available and does not need to be explicitly built every time from its base components (custodian, owner, id)

On the other hand, enumerating all parties in a flat data structure has the advantage that all parties are immediately visible to the reader.

In my opinion, using the AccountKey data type makes the economic meaning of the template clearer, but you should choose the approach that you think works best for your use-case.

Matteo