Hi, I have an issue where if I create a Batch such that I want to start a pass-through chain with a CreditReceiver allocation, it breaks the default implementation of Batch – in this code I see that it only considers Pledge as the start of a pass-through chain. As a result, this assertion fails.
Instruction 1: Alice → Bob
Allocation: PassThroughFrom Instruction 0
Approval: TakeDelivery
I know the above looks a bit redundant as it could simplified to one Instruction in which the Cusodian sends directly to Bob, but we want the transaction to have specific properties to be faithful to legal/tax requirements.
Indeed, the current Instruction implementation does not support the combination of CreditReceiver and PassThroughTo.
To achieve the same outcome, the Custodian could (instead of allocating its instruction with CreditReceiver) first create a self-held holding and then pledge it. Alice could then pass the asset through to Bob.
Custodian
/ | \
Custodian -> Alice -> Bob
The effect of this settlement is that the Custodian is crediting a holding to Bob, a process that could be accomplished with a single Instruction (as you point out). It would be interesting to understand the legal/tax reasons why it needs to go through Alice.
I have added a ticket for considering to add support for this allocation/approval combination here for us to track.
@Johan_Sjodin thanks for that answer. That is the approach we will need to go down for now. The reason it (ideally) needs to go through Alice is we are rewarding the “producer” of this asset (Alice) and then allowing Alice to send the asset to a buyer (Bob) in the other step. We don’t want to send the asset to Alice first in one transaction, then allow her to sell to another party in a separate transaction, as this would create a tax liability for Alice without any payment received to fund the liability.