You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current implementation, for opt-in transactions, the asset amount must be set to 0. However, using the transferAsset function with the asset amount set to 0 causes the transaction to fail. Interestingly, if the addAssetAmount function is not chained in the transferAsset call, the opt-in transaction works as expected.
To address this issue, I propose adding a dedicated function for opt-in transactions in the AlgorandTransactionCrafter class to handle this scenario more effectively.
The text was updated successfully, but these errors were encountered:
This looks like an issue with the encoder, validated that the toEncodingData from the algosdk is the same structure that is produced by the AssetTransferTxBuilder but the encoded bytes are not equal.
Yes, I am facing a similar situation. Currently, I am trying to create a similar transaction for an application call. Using bytesToSign from algosdk makes the transaction successful with hashi, while toEncodingData produces the same structure but results in unequal bytes.
In the current implementation, for opt-in transactions, the asset amount must be set to 0. However, using the transferAsset function with the asset amount set to 0 causes the transaction to fail. Interestingly, if the addAssetAmount function is not chained in the transferAsset call, the opt-in transaction works as expected.
To address this issue, I propose adding a dedicated function for opt-in transactions in the AlgorandTransactionCrafter class to handle this scenario more effectively.
The text was updated successfully, but these errors were encountered: