Daml Finance Account tight coupling with HoldingFactory

Looking at how the Daml Finance account is setup, I was wondering whether it wouldn’t be more advantageous to have the holdingFactoryCid not be part of the Account template field definition? https://github.com/digital-asset/daml-finance/blob/b0bd65e1647d2f11efcf09ff1fc86eca493f9320/src/main/daml/Daml/Finance/Account/Account.daml
Any reason why we couldn’t just change the credit choice of the interface to take an input which would be a holdingFactoryCid and as such generalize the Holdings that an account can be associated to?

Hi @Luis_Marado,

As you mention, having the holding factory tightly coupled with an Account contract effectively fixes the implementation of holdings that can be held at an Account.

The trust assumption is slightly different if we make the holdingFactoryCid an input to the Credit choice, as we trust the controllers of the choice with the holding implementation type. This might in some cases be undesirable.

On the other hand, the tight coupling makes your life harder when dealing with upgrades, as any Holding upgrade would force a re-creation of the Account contracts in order to update the factoryCid.

Matteo

I guess my question was also business focused. Is there any other reason to block an account from connecting itself various different holdings types? What would be the rationale to allow multiple holdings of the same type (e.g. fungible such as USD or EUR) under the same account, but then disallowing non-fungible ones?

But addressing the more technical comments made, on such trust assumption, if I’m following, it would still require the factory provider to be part of the account stakeholders, or maybe the factory provider could be added to the account to enable a validation which would then guarantee those same trust assumptions, i.e. the factory provider is the same party regardless of the underlying holding.

Eventually, another way to counter it would be by enabling the account to support a list of holdingFactoryCid. The input for the credit choice would still require an extra input, but the list of allowed holdingFactoryCid would be contained on the Account.

Hi @Luis_Marado,

Luis_Marado:

Is there any other reason to block an account from connecting itself various different holdings types?

No other reason comes to my mind, other than the one I mentioned above.

Luis_Marado:

What would be the rationale to allow multiple holdings of the same type (e.g. fungible such as USD or EUR) under the same account, but then disallowing non-fungible ones?

Fungible holdings on different instruments under the same account can be used to model e.g. securities accounts.

Luis_Marado:

it would still require the factory provider to be part of the account stakeholders

The factory provider does not need to be an account stakeholder. However, given that the factory provider witnesses all holding creations, it is usually the same party as the account provider.

I agree that adding a signatory check such as signatory factory == account.provider would add a level of safety when the factory is provided as part of the Credit choice.

Luis_Marado:

Eventually, another way to counter it would be by enabling the account to support a list of holdingFactoryCid. The input for the credit choice would still require an extra input, but the list of allowed holdingFactoryCid would be contained on the Account.

This is also a feasible approach (and something we mention in e.g. this issue).

Do you have a real-world example in mind where holdings of different types sit at the same account?

Thanks,
Matteo

Hi,

Thank you for the comprehensive feedback to my follow up.

The real world scenario which drove this question was a bit of a mixture between a fungible and non-fungible holding. There’s a holding which represents a fungible token (e.g. a bond or some other financial instrument), but that can only be split to the integer level, and while someone can have a holding with quantity > 1, each unique holding is linked to a list of non-fungible holdings with their own id. Both of these holdings were being thought to be put under the same account.

Thanks for the explanation, that is an interesting use-case.

I think the first part (the fungible) could be modelled with a custom fungible holding where one

• ensures that the amount is an integer
• changes the implementation of split to ensure the splitAmount is integer

I will raise an issue to consider adding such an implementation of a Fungible to Daml Finance.