feat(Permit3): unlock account message type by re1ro · Pull Request #2 · eco/permit3

re1ro · 2025-02-27T00:52:20Z

No description provided.

nknavkal · 2025-02-27T01:16:34Z

src/NonceManager.sol

-        usedNonces[owner][nonce] = 1;
+    function _useNonce(address owner, bytes32 salt) internal {
+        require(usedNonces[owner][salt] == 0, NonceAlreadyUsed());
+        usedNonces[owner][salt] = 1;


using both salt and nonce in these methods is confusing

salt is what user passes, but salt is userAddress + salt

but I agree it's not elegant

lol even in that response it is confusing

We should unify into a single name — I see the conflict because it is kind of a salt and definitely a nonce. We can probably go with salt or something like snonce? Also could make the name descriptive like asyncNonce

pepper is taken...

nknavkal · 2025-02-27T01:27:58Z

src/Permit3.sol

     */
    function permit(
        address owner,
+        bytes32 salt,


no natspec for this

nknavkal · 2025-02-27T01:30:06Z

src/Permit3.sol

@@ -114,32 +117,40 @@ contract Permit3 is IPermit3, PermitBase, NonceManager {
     * 1. Immediate transfers (transferOrExpiration = 1)
     * 2. Allowance updates (transferOrExpiration = future timestamp)


update these to be modeOrExpiration

nknavkal · 2025-02-27T01:41:37Z

src/Permit3.sol

-                if (allowed.expiration == LOCKED_ALLOWANCE && timestamp < allowed.timestamp) {
+                if (
+                    allowed.expiration == LOCKED_ALLOWANCE
+                        && (p.modeOrExpiration != uint48(PermitType.Unlock) || timestamp <= allowed.timestamp)


What if i wanted to increase the timestamp of the lock?

nknavkal · 2025-02-27T01:50:02Z

src/NonceManager.sol

-            usedNonces[msg.sender][noncesToInvalidate[i]] = 1;
+        uint256 length = salts.length;
+
+        for (uint256 i = 0; i < length; i++) {


i don't think this matters here

5 gas saved 🙏

nknavkal · 2025-02-27T02:14:58Z

src/Permit3.sol

                }

-                emit Permit(owner, p.token, p.spender, allowed.amount, allowed.expiration, chain.nonce);
+                emit Permit(owner, p.token, p.account, allowed.amount, allowed.expiration, timestamp);


this timestamp is...a nonce?

nknavkal · 2025-02-27T02:15:10Z

src/interfaces/IPermit.sol

     * @param amount The approved amount
     * @param expiration When the approval expires
-     * @param nonce The nonce used in the permit signature
+     * @param timestamp The nonce used in the permit signature


nknavkal · 2025-02-27T02:15:42Z

src/NonceManager.sol

-        bytes32 chainedInvalidationHashes = proof.preHash;
-        chainedInvalidationHashes =
-            keccak256(abi.encodePacked(chainedInvalidationHashes, hashNoncesToInvalidate(proof.invalidations)));
+        bytes32 unbalancedInvalidationRoot = proof.preHash;


having trouble wrapping my head around this, but i think i just need to think about it more

nknavkal

Most of my comments are questions

christianangelopoulos · 2025-02-27T01:46:12Z

README.md

+    - Rejects all operations until unlocked

-4. **Increase Mode** (`transferOrExpiration > 2`)
+4. **Unlock Mode** (`transferOrExpiration = 3`)


glad we added this explicitly

christianangelopoulos · 2025-02-27T01:50:43Z

README.md


 Locked accounts have special restrictions:
- Cannot increase allowances
+- Cannot increase/decrease allowances


we want to keep the ability to decrease allowances in this state — if a user has approvals out for N tokens they might want to be able to decrease them all to zero while in this state

I guess you could pass in an array with an unlock step first and set all the approvals to zero in the operations that follow, but I like the idea that you can ensure the allowances are decreased in lock state + its more friendly to non-dev users

disregard: I now see that lockdown is per token and therefore this is not needed

maybe add a comment here that lockdown is per token and sets allowances to zero — that was why I was confused at first

christianangelopoulos · 2025-02-27T01:57:39Z

src/NonceManager.sol

-        bytes32 chainedInvalidationHashes = proof.preHash;
-        chainedInvalidationHashes =
-            keccak256(abi.encodePacked(chainedInvalidationHashes, hashNoncesToInvalidate(proof.invalidations)));
+        bytes32 unbalancedInvalidationRoot = proof.preHash;


~~unbalancedInvalidationRoot~~ --> unhingedInvalidationRoot 🥇

christianangelopoulos · 2025-02-27T02:20:10Z

src/NonceManager.sol

-        usedNonces[owner][nonce] = 1;
+    function _useNonce(address owner, bytes32 salt) internal {
+        require(usedNonces[owner][salt] == 0, NonceAlreadyUsed());
+        usedNonces[owner][salt] = 1;


We should unify into a single name — I see the conflict because it is kind of a salt and definitely a nonce. We can probably go with salt or something like snonce? Also could make the name descriptive like asyncNonce

pepper is taken...

christianangelopoulos · 2025-02-27T02:57:15Z

src/Permit3.sol

     */
    bytes32 public constant CHAIN_PERMITS_TYPEHASH = keccak256(
-        "ChainPermits(uint64 chainId,uint48 nonce,AllowanceOrTransfer[] permits)AllowanceOrTransfer(uint48 transferOrExpiration,address token,address spender,uint160 amountDelta)"
+        "ChainPermits(uint64 chainId,AllowanceOrTransfer[] permits)AllowanceOrTransfer(uint48 transferOrExpiration,address token,address spender,uint160 amountDelta)"


transferOrExpiration --> modeOrExpiration

also spender should be account

christianangelopoulos · 2025-02-27T03:10:38Z

I noticed some of the variable names are different in the EIP.md still — so will want to rectify those

feat(Permit3): unlock account message type

49786f3

re1ro requested a review from christianangelopoulos February 27, 2025 00:52

re1ro self-assigned this Feb 27, 2025

re1ro requested a review from nknavkal February 27, 2025 01:06

docs(Permit3): fixing comment structure

1cf329d

nknavkal reviewed Feb 27, 2025

View reviewed changes

src/Permit3.sol

*/

function permit(

address owner,

bytes32 salt,

Copy link

nknavkal Feb 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no natspec for this

nknavkal reviewed Feb 27, 2025

View reviewed changes

christianangelopoulos reviewed Feb 27, 2025

View reviewed changes

christianangelopoulos added 2 commits February 26, 2025 21:31

small nits

4aa872d

small typo

5fff057

christianangelopoulos merged commit f21e649 into main Feb 27, 2025
0 of 2 checks passed

christianangelopoulos deleted the feat/unlock-acoount-message branch February 27, 2025 03:41

re1ro mentioned this pull request Oct 31, 2025

feat(#1): add generic TreeNodeLib for EIP-712 tree reconstruction #53

Open

		@@ -114,32 +117,40 @@ contract Permit3 is IPermit3, PermitBase, NonceManager {
		* 1. Immediate transfers (transferOrExpiration = 1)
		* 2. Allowance updates (transferOrExpiration = future timestamp)

Conversation

re1ro commented Feb 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

re1ro Feb 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nknavkal left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

christianangelopoulos commented Feb 27, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

re1ro Feb 27, 2025 •

edited

Loading