How does the approval of transactions affect balance calculations? Consider a scenario with four transactions involving two accounts:
Transaction 1: Account A mints 50 tokens. [MINT TX]
Transaction 2: Account A transfers 20 tokens to Account B. [TRANSFER TX]
Transaction 3: Account A approves the transfer of 10 tokens to Account B. [APPROVE TX]
Transaction 4: Account B transfers 10 tokens to Account C. [TRANSFER TX]
What should the balances of Accounts A and B be?
I’m asking this to gain insight into how “Approve” type transactions function. For context, here’s an example of such a transaction: transaction
How does an “Approve” transaction impact wallet balances, and how can a spender utilize the approved transaction amount? Furthermore, why is this type of transaction necessary in the first place?
An approval costs the same amount as a transfer that transfers 0 tokens, i.e. just the transaction fee. For ICP that’s 0.0001 ICP. The spender is then allowed to transfer the approved amount as if it were their own tokens.
Approvals are very useful since there is no automatic notification mechanism when an account receives a transfer. So in most cases it’s easiest to just let the canister that needs to be notified of a transaction to do the TX on its own instead of doing the transfer and then notifying the receiver of the transfer. The work is mostly the same, but error handling becomes much easier that way
So, if I understand correctly, after the completion of all four transactions, the balances would appear as follows:
Account A: 30 tokens
Account B: 10 tokens
Am I correct in assuming that Account A’s approval allows Account B to spend 10 tokens, yet these tokens won’t immediately reflect in their respective balances? Furthermore, can Account B transfer these 10 tokens to another account, say Account D, given the authorization granted by Account A?
Edit: i’m ignoring transaction fees here. just trying to understand main transfer logic.
Yes, that’s right. An approval does not affect the balance because it only approves someone else to spend token. They can then use icrc2_transfer_from to actually perform the transfer
Continuing with the example, in Account A, there are still 30 tokens, with 10 tokens allocated to Account B. Are these tokens subject to locking? Moreover, what would occur if Account A were to transfer all 30 tokens to another account before Account B utilizes the allocated 10 tokens?
The standard does not require tokens to be locked, although I don’t think it would be forbidden. Also, while the standard does not allow infinite approvals, you can approve more than the current balance, so you can create effectively infinite approvals by approving e.g. u128::MAX.
When there are not enough tokens in the account for a transfer then whoever tries to transfer (no matter if it’s the owner or an approved spender) will receive an InsufficientFunds error.
@Severin I have one more question for clarification regarding fee calculation. As you mentioned, during an APPROVE transaction, fees are deducted from the account that approves the transaction. So, if Account A approves tokens for Account B, fees will be deducted from Account A.
Now, when Account B uses the transfer_from method to access those tokens, it becomes a regular “TRANSFER” type transaction from Account A to Account B. In this scenario, what happens with fee deduction? Is the fee deducted twice?
Additionally, could you clarify how the from and to parameters function?
In an “APPROVE” transaction, the from address will be Account A, and there won’t be a to address specified. Account B will act as the spender.
When Account B later utilizes the transfer_from method, resulting in a “TRANSFER” type transaction, which address will be designated as the from address? Will it be Account A or Account B?
The approve costs you the fee one time, and then every transfer_from also costs 1x the fee. Also, if you approve 10 and then 10x transfer_from only 1 token then you pay the fee 11 times (1x approve, 10x transfer).
It will show up as a transfer from A since the funds come out of account A
Also, Once we’ve approved a certain number of tokens, is it correct that we can’t reverse this decision if we later want to unapprove them? once approved, then tokens belong to the spender right?
ohh ok. can you help me how exactly? I’ve explored nns.ic0.app but haven’t located the transaction options for “APPROVE” or “UNAPPROVE.” By default, the transaction type available on NNS appears to be “TRANSFER.”
so basically the “approve” transaction, it seems it’s more of an update rather than a conventional transaction; it serves as a mapping of an account against a certain number of tokens.
This implies that if I approve an account to spend 10 tokens, and then later approve the same account for 5 tokens, the spender can only utilize 5 tokens, not a cumulative 15. The approve transaction overwrites rather than adds to the previous approval limit.