MintBurnFactory Holding Offers/Requests

Hello,

What is the rationale behind the Splice.Api.Token.BurnMintV1:BurnMintFactory not having offer/request flows for “accumulating” authorizations from “issuers/holders” respectively? For context the Utility.Registry.App.V0.Service.AllocationFactory:AllocationFactory has such flows alongside the BurnMintFactory one.
As it stands, it seems difficult that a backend service/api call with no dependencies from utility is able to mint holdings to “holders”, apart from a “issuer mint to self and transfer to holder” given it requires multiple controllers and some of those may be “external parties”.

Hi David,

The BurnMintFactory interface is meant as an integration point where custom Daml models can compose with the DA Registry. The expectation is that those custom models are used for authorization gathering.

Matteo

But this means that a backend service would need a hard dependency on a token standard implementation package, registry or otherwise. Is this the intended usage of the token standard for an external dapp?

The Token Standard doesn’t cover burn and mint operations, only transfers.

Burn and mint are currently app-specific. The DA Registry offers a composition point to (Daml) apps with custom mint and burn workflow over the BurnMintFactory interface. While this interface is part of Splice, it is not part of the Token Standard (CIP-0056, CIP-0112).

So if your dApp is just doing transfers, then there’s no need for your backend to depend on concrete implementations.

If. on the other hand, your dApp is doing DA Registry mints and burns (so outside of Token Standard), you need to either depend on concrete implementations or use the BurnMintFactory with your custom Daml models.