Interfaces in Daml 3

Hello,

I was playing around with a Daml 3 snapshot and I was experimenting with Retroactive Interface Instances which was a feature in Daml 2 where you could instantiate a pre-existing template in new interface.

template Foo
  with
    signer : Party
  where
    signatory  signer

data FooView = FooView with
  signer : Party

interface IFoo where
  viewtype FooView

  interface instance IFoo for Foo where
    view = FooView with signer

Now in daml 3 I’m getting an error in the keyword interface for the instance. Is this a removed feature in Daml 3?

Best regards,
David Martins

According to these docs it should still be possible, but I’m unable to.
The version I’m using is “3.3.0-snapshot.20250305.0”.

@David_Martins, thank you for pointing this out!

Retroactive interfaces were deprecated with 2.10 LTS, due to edge-cases around the Smart Contract Upgrades feature.

I’ll let the team know to edit the docs.

Hi @David_Martins , as @WallaceKelly explained that feature is indeed not supported in Canton 3.x. You can achieve the same effect using a Smart Contract Upgrade to add an interface implementation to a template that was defined in a prior version of your Daml package.

Adding new interface implementations to existing templates is a new feature that was added as part of Canton 3.3 to support the implementation of the token standard interfaces by existing assets like Canton Coin and USYC.

Hello @Simon_Meier,

Thank you for the reply, but hypothetically speaking, let’s say that I don’t control the token app from the issuer, but I still want to integrate with it via an interface. By losing the retroactive interface, I’m unable to do so, even with this “workaround”, unless I somehow convince the app owner to upgrade, right?

Yes you are right. You cannot implement an interface instance for third-party code using an SCU.

Convincing the third-party to implement the interface, or expose a suitable interface for your purposes seems like a good investment though, as that means they define an explicit public API whose implementations can be resolved at runtime. Using interfaces for cross-app dependencies greatly simplifies the coordination of upgrades.

I’d expect that in the near future most of these interfaces come as part of standards like the CN token standard.

Retroactive interfaces implementations might be useful for cases like the one you pointed out where additional interfaces are required to adapt an existing app post-hoc. Support for reatroactive interface instances is challenging to implement in a Canton 3.x world, but not fundamentally impossible AFAIS. Let’s see how the app composition landscape evolves, and whether there’s strong evidence for the ROI of implementing retroactive interface instances.

For now, I’d suggest that we consider interfaces as a tool for apps to define a stable public API for consumption by other apps.