i’m implementing statefull contract in teal version 6.
This contract did support submit inner txn/calling other application, receive asset/algo, transfer asset/algo to user and of course have function and method for user to interact with.
One thing here is that when user submit txn, i see some special field that may affect the contract and different from other blockchain platform. i want to know more if these field can do to my stateful contract and how vulnerability/issue it may have:
First an important note: terminology changed on Algorand. When I talk about “smart contracts”, I mean the current notion of smart contracts, that is stateful applications. Old stateless smart contracts (now called smart signatures) are completely different (see end of post).
CloseRemainderTo and AssetCloseTo are only present in payment and asset transfer transactions. An application call to a (stateful) smart contract won’t contain this field.
The RekeyTo field applies to the sender of the application call transaction. Since an application call is usually made by an end user, the end user is the send and they must check that the transaction they sign (as presented by the DApp wallet) does not contain rekey field as this would allow the malicious DApp to take over the user’s account. (Except if the goal of the transaction is to give the DApp control over the user’s account, which may happen in some very advanced designs).
From a DApp developer point of view, if you are only using smart contracts (and not smart signatures or any advanced features), you mostly don’t need to worry about these fields in (stateful) smart contracts, as long as you don’t use them in inner transactions.
From a user or a wallet designer point of view, you must be very careful. ARC-1 which standardizes ways wallets receives signing requests from DApps contain very strict requirements to ensure safety of users.
However, if you are using smart signatures (formally known as -stateless- smart contracts and also known as logic sig), you must be extremely careful. Those fields must be strictly checked.
Nowadays, smart signatures are restricted to advanced DApp designs and delegation of approval.
Most DApps should not be using them
Thanks, i can understand about CloseRemainderTo and AssetCloseTo
For RekeyTo, stand with stateful smartcontract point of view (not the wallet or the dapp front end which build txn), what really happend when this field is not zero address?
For what i’m inderstand, it can be authorize for others account. For example account A reley to account B, account A send txn X to stateful contract. The reley field of this txn X must be B, the txn.sender still A? An others different with this txn?
For an app like authorize voting which check the authorize of sender, does rekey txn and normal txn can be treated the same?
Or an example should be great!
Thanks for your help.
Or if the ReleyTo is set to non zero in the txn call to app (for example address A), the address A will be considered as the authorized of the sender account (like a set RekeyTo txn but it is in with the application call)?
Rekeying is a way to change who is allowed to sign/authorize transactions from that account.
Suppose I have an account with address A.
I can decide to rekey this account to use instead address B to authorize transactions.
For that, I use the rekeyto field on any transaction (it can be a payment transaction, an application call, …).
From now on, to submit transactions with sender A, I will need to sign using the secret key for address B. To do that, I add another field in the signed transaction, sgnr. I do not use the field RekeyTo anymore.
After this specific application call transaction, another address will need to authorize transactions from this account. It mostly does not matter to your smart contract, except if you actually need the smart contract to take over the sender’s account (by rekeying to the application account).
No, in that case, it is the field sgnr / authorized address that is set in the signed transaction. The rekeyTo field would not be set.
Yes, it would not matter to it
It does not matter which kind of transaction rekeyTo is specified. It can be an application call.