I’ve been thinking about the possibility of nesting groups of transaction. The use case I’m after is combining transactions between unrelated dApps. Let’s say for instance I want to buy something from one dApp but pay with a token not supported by the seller. Then I could combine a set of transactions to an exchange dApp, with the required transactions to the seller. If this could all be one atomic transaction I would be confident I only make the purchase if the exchange succeeds and vice-versa.
Maybe there is already other established solutions to this problem?
This could be solved with one flat group of all required transactions. That would however require that the involved dApps don’t verify the group-size or any absolute positions in groups. I guess they could instead verify companion transactions at offsets from their own index. But all examples and docs I’ve seen, seem to advocate verifying expected group-size and even absolut indices, are there valid reasons for this?
This is indeed a very insightful comment.
Currently, the documentation advocates for checking group of transactions as it is simpler from a developer perspective.
As you mentioned, this ARC will recommend to not check the size of the groups to allow for composition.
In addition: it will most likely be recommended that
any given method uses a fixed-size “subgroup” of transactions. Not doing so can be very dangerous when escrow accounts are used (risks of interleaving transactions and allowing forbidden operations on the escrow account).
the application call will be at the end of the subgroup. This is necessary if the application call needs to read results from previous application calls via the scratch space or if the application needs access to the ID of an asset created in a previous transaction.