Determining when an Amulet is consumed and the purpose of acsDelta and

App Development
1

Question from a partner integrating with the Canton Network:

I have a question about how to determine the creation and consumption of Amulet contracts in TransferPreapproval_Send.

I noticed that in the following event:

  • ExercisedEvent
  • choice = “Archive”
  • consuming = true
  • acsDelta = false

this behaves differently from what I observed in Step 2 (transfer + accept flow), where:

  • ExercisedEvent
  • choice = “Archive”
  • was typically validated with consuming = true && acsDelta = true

So my questions are:

  1. What is the correct standard for determining when an Amulet is consumed (archived)?
  2. Why does this Archive event have acsDelta = false, while previous transfer/accept flows required acsDelta = true?
  3. Should acsDelta be considered a reliable condition for identifying consumption in all cases, or only in specific workflows?

It seems that the same Archive choice behaves differently depending on the transfer flow (e.g., TransferPreapproval_Send vs. 2-step transfer + accept). I would like to understand the correct parsing logic.

2

Answers:

“what is the correct standard for identifying valid Amulet creation in this flow?”

a create event

consuming=true is the only if signal for whether the choice consumes the contract.

acsDelta

Docs around “ACS delta” need to be improved but basically it tells you whether the archived contract pertains to a stakeholder from the parties provided in the update stream subscription AND if so, whether it archives a contract not created in that transaction. To put it more generally, acsDelta tells you whether any of the reader parties on the update subscription is interested in considering that event for updating its client-side view of the ACS.

acsDelta can be false due to 2 reasons:

  1. the archived contract was created in the same transaction (I think this is the case here but I don’t know that Daml flow so please double-check)
  2. the archived contract does not have a stakeholder amongst the parties reading for the stream