Transaction Group Slots

post by gidon on Apr 8, 2021

The guidlines state:

“Transaction groups must be designed with ‘slots’ such that each transaction will know what position it is in. A transaction’s logic can check ( txn GroupIndex == K && global GroupSize == M) and then also check specific other transactions by their index through gtxn N field”

I have seen many examples where in a stateful smart contract you verify its own position in the group and that it is has appl type. Example in solution https://developer.algorand.org/solutions/assets-and-custom-transfer-logic/:

// check level should be called
// with the following txes
// tx 0 - check level smart contract call - signed by sender of asset
// tx 1 - clawback transactions that moves the frozen asset from
// sender to receiver - signed by clawback-escrow
// tx 2 - payment transaction from sender to clawback-escrow
// to pay for the fee of the clawback

check-level:
// check number and types of txes
global GroupSize
int 3
==
gtxn 0 TypeEnum
int appl
==
&&
gtxn 1 TypeEnum
int axfer
==
&&
gtxn 2 TypeEnum
int pay
==
&&
// Verify that this is index the stateful contract call
txn GroupIndex
int 0
==
&&
bz failed

Is this not just a complete waste? Surely if you verify all other transactions in the group (in above example tx1 and tx2) then by default the one not checked must be an appl call to the smart contract because otherwise the code would never be running.

post by fabrice on Apr 8, 2021

It indeed looks like in this specific example you may avoid the check that the first transaction is an application call.

In general however, you may want to be more defensive rather than trying to save space, in order to avoid any potential security risks.