Can asset transfer in an ApplicationCallTxn be specified in a URL/QR-Code payment prompt?

Hello.

The main question is in the title. The specific case I have is the tracking of payments. I was thinking a smart contract could be made whose only purpose is to check if a note in a transaction is properly formatted and let it through if so. The transaction would have already be signed, but just needs the note checked, so I can track it. It should also be possible to use with transactions that do an asset transfer (not just ALGO). Such a transaction would also be needed to be encoded as a URL/QR-Code that auto-fills the payment in a wallet with an xnote (same note that is being checked).

From the documentation, it doesn’t look like ApplicationCallTxn has the asset transfer fields as in the AssetTransferTxn. The URI scheme also doesn’t seem to have any application calling fields. The application/program would need to be signed by a normal account as far as I can see, since the incoming transaction could have arbitrary from and to accounts.

Thanks for any insights!

An application call transaction cannot transfer any asset/Algo by itself.
It needs to be grouped with a payment/asset transfer transaction to do so.

If the sender account is fully controlled by the user, the user can decide to sign anything they want and may write the note of their choice. There is no way to reject an incoming Algo payment transaction: anyone can send you Algos with the note of their choice.

If you are willing to pay using assets, then the recipient must first opt-in to the asset before being able to receive it. This may be used to check the note field, but this would require the wallet to sign some group of transactions.

Thanks for the reply.

So the user could send a group transaction, consisting of:

• ApplicationCallTxn
• SignedTxn
  • AssetTransferTxn (includes note)

The idea with the note check is to prevent the user/wallet to mess up the note in some way and reject the transaction if that happens. But if it’s organized like this, it’s probably more likely that the group transaction as a whole gets messed up. I don’t see a group transaction available in the URI scheme for payments and QR-Codes so maybe it’s not possible to let the user open such in their wallet.

Do you know how reliable the xnote field in the URI scheme is? If it’s universally used in wallets, then maybe I could just use that and not verify.

Thanks.

And I suppose this checking would be kind of pointless if it’s organized like this, since the user can just sidestep the application.

Currently URI Scheme - Algorand Developer Portal is only supported by the official Algorand Wallet and you cannot create group of transactions with this feature. This may change in the future.

To create group of transactions, you may need to use AlgoSigner (AlgoSigner | Algorand Wallet Extension for Chrome | PureStake) or MyAlgoConnect (GitHub - randlabs/myalgo-connect).

But as you mentioned, if you are afraid the user or the wallet messes things up, the user may just forgo the application call.

If you’re using an ASA, you can prevent this by creating a fresh address RCP (that is a stateless contract account) for the user payment and by requiring using a group of 3 transactions:

• User sends 0.201 Algos to RCP
• RCP opts-in to the ASA - signed by the stateless smart contract, which also verifies the note field of the last transaction
• User sends the ASA payment to RCP

But this is quite complex and it is unclear you would gain much from that solution.

Interesting. I read this in the docs about contract accounts:

If the SHA512_256 hash of the program (prefixed by “Program”) is equal to the transaction Sender address then this is a contract account wholly controlled by the program

In the 3 transaction group example you gave, is it the second transaction then that makes this transaction group be processed by the program? (since its sender is the contract account)

I’d be fine with opting in to a fixed set of assets beforehand, then if the program could process an asset transfer to its contract account (in a single transaction), checking the note, then that would be perfect. But it’s the sender that needs to match, not the receiver.

Yes

If you opt in beforehand, then there is no way for you to check ASA transfers you’re receiving.