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: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: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

@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"

mssteuer · 2026-05-22T00:46:45Z

@zie1ony once @davidatwhiletrue's remaining comments are addressed/responded to, we can finalize this

davidatwhiletrue · 2026-05-22T10:38:12Z

+- `0x01` for `PackageHash`.
+
+The encoded message data hashed alongside the typehash is the
+concatenation of `CLValue` representations, in order, of:


I would simplify this sentence to:
"The encodeData value is the concatenation of the following EIP-712-encoded fields, in order:"

'the concatenation of CLValue representations' is not correct.

I'd use uint256 instead of U256.

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

mssteuer self-requested a review May 22, 2026 00:46

davidatwhiletrue reviewed May 22, 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!

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!

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!

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!

mssteuer commented May 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 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