CEP-2612: Permit Extension by zie1ony · Pull Request #99 · casper-network/ceps

zie1ony · 2026-05-12T16:28:51Z

davidatwhiletrue

@zie1ony , please check my comments.

davidatwhiletrue · 2026-05-13T11:17:22Z

+that produces the same allowance state change as `approve` while being callable
+by a third party.
+
+## Prior art


Almost every CEP has a Motivation section. We may have one here too.

We are porting a standard here, not inventing anything new.

davidatwhiletrue · 2026-05-13T11:17:43Z

+
+The CEP-2612 extension is defined by:
+- one new entrypoint (`permit`),
+- the EIP-712 typed data definition for the `Permit` struct,


'...and the domain separator'

davidatwhiletrue · 2026-05-13T11:18:03Z

+
+Below definitions use Rust syntax, but they are not Rust specific.
+
+### Entrypoint interface


'Entry point' with a space

davidatwhiletrue · 2026-05-13T11:18:39Z

+    ///   disables the expiry check.
+    /// - `public_key` is the signer's Casper public key.
+    /// - `signature` is `public_key`'s signature over the EIP-712 digest
+    ///   of the `Permit` typed data (see below).


I'd remove (see below) becuase this is a code block.

davidatwhiletrue · 2026-05-13T11:19:49Z

+    /// - the allowance of `spender` over `owner` is set to `value` (i.e.
+    ///   the same effect as `owner` calling `approve(spender, value)`),
+    /// - the `owner`'s permit nonce is incremented by one,
+    /// - a CEP-18 `SetAllowance { owner, spender, allowance: value }`


just SetAllowance { owner, spender, allowance }

This is ok, because value is the parameter in permit function. This link makes sense.

davidatwhiletrue · 2026-05-13T11:25:47Z

+
+1. `signature` is a valid signature of `public_key` over the EIP-712
+   digest of the `Permit` typed data (described below), AND
+2. `owner == Address::from(public_key)` — i.e. `owner` is the account


Is Address::from() correct here?

Yes. It only represents the logic.

I'm not convinced. Address is an Odra type. It doesn't exist in casper_types. The reader doesn't need to know that an Address is an account hash. It'd be more explicit.

davidatwhiletrue · 2026-05-13T11:28:07Z

+The encoded message data hashed alongside the typehash is the
+concatenation, in order, of:
+
+- `owner` encoded as an EIP-712 `address` (32 bytes, big-endian, left-padded),


In Casper, owner and spender are a hash of an Account Hash or a (package) Hash (the hash of 0x00 or 0x01 prefix || 32 bytes). I would mention it here. and remove big-endian, left-padded

done, I mentioned how address is serialized.

davidatwhiletrue · 2026-05-13T11:28:52Z

+- `nonce` encoded as an EIP-712 `uint256` (32 bytes, big-endian) — equal
+  to the current on-chain `permit_nonces[owner]` value at the time the
+  signature was produced,
+- `deadline` encoded as an EIP-712 `uint64` (32 bytes, big-endian,


“EIP-712 uint64" does not exist. u64 or uint256. let’s use the same here as in CEP-3009 for validAfter and validBefore

davidatwhiletrue · 2026-05-13T11:29:39Z

+The final digest is computed using the standard EIP-712 rule
+(`keccak256("\x19\x01" || domainSeparator || keccak256(typeHash || encodedData))`).
+
+The EIP-712 `domainSeparator` uses:


Not aligned with casper-eip-712 domain type:

EIP712Domain(string name,string version,string chain_name,bytes32 contract_package_hash).

Worth to add the type string to this section too.

Also, recommend to use CAIP-2 for chain_name as here.

I updated the document, but not sure if this is what you wanted. Please check

I don't see the domain type in the document. Because it differs from the EIP-2612 domain type, I think we need to include it.

EIP712Domain(string name,string version,string chain_name,bytes32 contract_package_hash)

Also, check this comment: https://github.com/casper-network/ceps/pull/99/changes#r3272351456

davidatwhiletrue · 2026-05-13T11:31:31Z

+- The chain name is stored under the key `chain_name` with the type
+  `String`.
+
+#### Permit nonces


Should we discuss non-sequential nonces? I realize this will diverge from the ERC-2612 specification. But it’s a limitation and something Permit2 solved if I'm not mistaken.
Moving to random nonce probably means having a cancel_permit-like entry point, and a different structure to store used values.

I don't think we need to. We do 2612 to be compatible with possible 2612 users, but I'd use 3009 over 2612 in any case.

davidatwhiletrue

@zie1ony , see my comments.

davidatwhiletrue · 2026-05-20T08:25:41Z

+The final digest is computed using the standard EIP-712 rule
+(`keccak256("\x19\x01" || domainSeparator || keccak256(typeHash || encodedData))`).
+
+The `domainSeparator` is defined as:


This is not the domain separator for casper.
See here:
https://github.com/casper-ecosystem/casper-eip-712#casper-native-domain-example

EIP712Domain(string name,string version,string chain_name,bytes32 contract_package_hash)

davidatwhiletrue · 2026-05-20T08:26:02Z

+The final digest is computed using the standard EIP-712 rule
+(`keccak256("\x19\x01" || domainSeparator || keccak256(typeHash || encodedData))`).
+
+The EIP-712 `domainSeparator` uses:


I don't see the domain type in the document. Because it differs from the EIP-2612 domain type, I think we need to include it.

EIP712Domain(string name,string version,string chain_name,bytes32 contract_package_hash)

Also, check this comment: https://github.com/casper-network/ceps/pull/99/changes#r3272351456

davidatwhiletrue · 2026-05-20T08:30:25Z

+
+`Address` encoding is defined as 33 bytes, where the first byte is a type tag:
+- `0x00` for `AccountHash`,
+- `0x01` for `PackageHash`.


Hash instead of PackageHash?
o "0x01 for a package Hash"

CEP2612 Permit Extension

97cc79e

davidatwhiletrue reviewed May 13, 2026

View reviewed changes

Updatades to David's comments

d41ed6e

davidatwhiletrue reviewed May 20, 2026

View reviewed changes


		Below definitions use Rust syntax, but they are not Rust specific.

		### Entrypoint interface

Conversation

zie1ony commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidatwhiletrue 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!

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!

davidatwhiletrue May 20, 2026 • 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!

davidatwhiletrue left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidatwhiletrue May 20, 2026 • 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!

davidatwhiletrue May 20, 2026 • 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

zie1ony commented May 12, 2026 •

edited

Loading

davidatwhiletrue May 20, 2026 •

edited

Loading

davidatwhiletrue May 20, 2026 •

edited

Loading

davidatwhiletrue May 20, 2026 •

edited

Loading