Updated based on PR comments

ERCS/erc-7674.md

@@ -27,16 +27,12 @@ Compliant contracts MUST implement 1 new function in addition to [ERC-20](./eip-
 ```solidity
 function temporaryApprove(address spender, uint256 value) public returns (bool success)
 ```
-Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount.  This temporary allowance is to be considered in addition to the normal (persistent) [ERC-20](./eip-20.md) allowance, the total value that spender is able to spend during the transaction is thus capped by the sum of the temporary and the normal (persistent) allowances.
+Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount.  This temporary allowance is to be considered in addition to the normal (persistent) [ERC-20](./eip-20.md) allowance, the total value that spender is able to spend during the transaction is thus capped by the sum of the temporary and the normal (persistent) allowances. While it SHOULD be possible for a `transferFrom` operation to consume both types of allowance, the consumption of the temporary allowance SHOULD take priority over the consumption of the persistent allowance. Therefore, if the temporary allowance is sufficient for executing a `transferFrom` operation, the persistent allowance SHOULD not be loaded/updated from the storage. Consumption of persistent allowance, which implies storage accesses, SHOULD be performed only if the temporary allowance is not sufficient for the operation being executed.
 
-The storage for the temporary allowances MUST be different to that of the regular allowance. Compliant contracts MAY use the transient storage [EIP-1153](./eip-1153.md) to keep the temporary allowance. For each `owner` and `spender`, the slot MUST be uniquely selected to avoid slot collision. Each slot index SHOULD be derived from the base slot index for temporary allowances, `owner` and `spender` addresses. Slot MAY be derived as `keccak256(spender . keccak256(owner . p))` where `.` is concatenation and `p` is `keccak256` from the string uniquely defining temporary allowances in the namespace of the implementing contract.
-
-Compliant contracts MUST add a temporary allowance check to the `transferFrom` function. The permanent allowance SHOULD only be spent after the temporary allowance has been exhausted.
+Each temporary allowance MUST persist until the end of the transaction that created it (unless overwritten by another call to `temporaryApprove` or consumed by a call to `transferFrom`). Each temporary allowance MUST be cleared at the end of the transaction that created it. See [Using Transient Storage](#using-transient-storage) for an example.
 
 Compliant contracts MUST add a temporary allowance to the permanent one when returning the allowed amount to spend in the `allowance` function. In case the sum of the temporary and permanent allowance overflow, `type(uint256).max` MUST be returned.
 
-No event is required when setting a temporary allowance, but compliant contracts MAY emit a specific event.
-
 ## Rationale
 
 It was decided to make minimal interface extension to allow easier integration of a compliant contract into the existing infrastructure. This affects the backward compatibility of the `allowance` function. However, the required changes to the `transferFrom` function implementation satisfy the requirement to explicitly authorize the spender to transfer tokens.
@@ -47,7 +43,11 @@ All functionality of the [ERC-20](./eip-20.md) standard is backward compatible e
 
 ## Reference Implementation
 
-TBD <!-- TODO -->
+### Using Transient Storage
+The storage for the temporary allowances MUST be different to that of the regular allowance. Compliant contracts MAY use the transient storage [EIP-1153](./eip-1153.md) to keep the temporary allowance. For each `owner` and `spender`, the slot MUST be uniquely selected to avoid slot collision. Each slot index SHOULD be derived from the base slot index for temporary allowances, `owner` and `spender` addresses. Slot MAY be derived as `keccak256(spender . keccak256(owner . p))` where `.` is concatenation and `p` is `keccak256` from the string uniquely defining temporary allowances in the namespace of the implementing contract.
+
+### Events
+Even though no event is required when setting a temporary allowance, compliant contracts MAY emit `TransientApproval(address indexed owner, address indexed spender, uint256 value)` event.
 
 ## Security Considerations