Canonical way to find transfers for an account in Daml Finance

[huw]

In the ERC-20 standard, there is the Transfer event type which is emitted on every transfer of the token. Is there any close equivalent in Daml Finance? What type of events should I look for in the ledger transaction history to see what Holdings have gone in/out of my account, and what accounts they have come from, or have gone to? I was thinking to look for exercises of the Transfer choice on the Transferrable interface. However, it may be that in some cases the Holding is freely transferrable to other accounts under the same custodian. Someone can just transfer their Holding to me, and I won’t witness the exercise of Transfer on their Holding. I only see the create event of the Holding. Would I be better to make all transfers happen via a settlement Instruction, then I can see the creation of the Instruction and the exercise events on it?

[Johan_Sjodin]

Hi @huw,

Your point is well-taken. In scenarios where the incoming controllers of the receiving account are empty, the newOwner would solely witness the credit/creation of the new holding. However, they would not be privy to the corresponding holding being debited/archived. To rectify this situation, we could incorporate the newOwner as choice observers in the following manner:

  nonconsuming choice Transfer : ContractId Transferable
    -- ^ Transfer a contract to a new owner.
    with
      actors : Parties
        -- ^ Parties authorizing the transfer.
      newOwnerAccount : AccountKey
        -- ^ Account contract id of the parties to transfer the contract to.
    observer newOwnerAccount.owner
    controller actors, getLockers this
    do
      transfer this self arg

I have added a github issue 837 where we can track this.

Please also find the following related forum question:

Can we define, emit and listen to Custom Events?

There is no special inbuilt for custom events as every choice exercise is an event. So if you want to emit an event, you can just create a choice without an effect: controller (signatory this) can nonconsuming MyEvent : () with message : Text do return () If you exercise that, all you’ll get is an extra node on the transaction tree that you can react to.

I hope that helps.

Johan

[huw]

Thanks @Johan_Sjodin . If you add newOwnerAccount.owner as observer, I’m still not sure if we can know exactly who the owner was of the Holding that was transferred. I can see who the actors are, but how do I know which one of them is the owner?

[Johan_Sjodin]

Hello @huw,

When newOwnerAccount.owner is an observer of the choice, it gains visibility over the entire transaction tree that stems from it. This includes being disclosed the execution of the Debit choice and the subsequent archival of the holding.

I validated this by incorporating newOwnerAccount.owner as a choice observer, and then running the test 4 script, provided here:

Empty Account controllers

Hi @huw, The incoming and outgoing controllers offers a flexible mechanism to model a variety of required permissions for transfers. For instance, if the incoming controllers of the receiving account are empty, and the outgoing controllers of the sending account solely consist of the owner, this setup empowers the owner to transfer to the newOwner without requiring the newOwner's involvement. This process is akin to a Bitcoin transfer. I trust the subsequent test will offer a more vivid repres…

The table view, after execution, revealed that the archival of Alice’s holding is divulged to Bob. Without Bob being a choice observer, this transaction remains invisible. You can see a screenshot of the table view here for clarification:

Johan

[huw]

Hi @Johan_Sjodin , correct me if I’m wrong here, but I think Bob will not know the contract payload (create arguments) of Alice’s holding because he did not witness the CreatedEvent for it. I know it displays in the Navigator, but I don’t believe there is any way to get this contract payload via the ledger API.

[Johan_Sjodin]

Hi @huw,

To make these actions visible through the ledger API, two potential options are:

1. We could think of adding Bob as an observer to Alice’s holding just before it is debited/archived. By doing so, Bob would gain visibility into the holding arguments, rather than only witnessing the archival of Alice’s asset.
2. You could also modify the transfer implementation to create a “TransferEvent” contract instance signed by both Alice and Bob, effectively enabling Bob to view it through the ledger API (the template could be archivable by anyone).

Otherwise you might want to check if the information you need can be extracted from the full transaction graph (in the transaction log).

I have added ^ to the same github issue 837 where we can track this.

Johan