ARC-04 Algorand Transaction Calling Conventions

General
1

I’ve been reviewing the ARC-04 Algorand Transaction Calling Conventions (which is awesome by the way). I was hoping for some clarification around transaction order in atomic transactions. The convention states:

Arguments of these types are encoded as consecutive transactions in the same transaction group as the Application call, placed in the position immediately preceding the Application call.

I have some TEAL code that checks the balance of the contract account of the same contract that is being called, as part of its validation logic. If I place the pay transaction before the appl transaction in the group, I get an incorrect reading on the balance (presumably because that transaction has occurred first). I don’t get the same issue when I switch the order.

This is the same case for axfer transactions. So I have been placing my axfer and pay transactions at the end of the atomic transaction array, but I am now seeing that this is not best practice.

What should I do in this case without submitting two consecutive transactions? Ideally I’d like the pay or axfer transactions to fail if the logic in the appl transaction fails.

2

Yes, transactions are executed in order. So your smart contract will see the new balance.

Group transactions (aka atomic transfers) fail completely if one of the transaction fails.
This means that you can still have your application make the checks and reject if the checks fail.
This will also cancel the previous payment transaction in the group.

You will just need to change the check you are doing to take into account that the transfer already took place. (Concretely, for an ASA transfer, you may want to deduct the transferred amount to the current ASA balance. For an Algo transfer, this is slightly more complex because of participation rewards but in most cases you may just ignore them I think.)

1 Like