The current "Sign-In with Ethereum" EIP provides the following description of the Not-Before field, which is quite ambiguous:

not-before (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message will become valid.

So, in case the user is asked to sign a message where "Not-Before" is set in the future at the time of signature request, the above can be interpreted in two ways:

  1. The message is invalid now, hence you cannot sign it. It will only become valid after the "Not-Before" date.
  2. The message is valid and can be signed now, but the signature can be used only after the "Not-Before" date.

Which one is it? Should "Not-Before" set in the future make the message invalid? Should wallet providers prohibit signing such messages?

2 Answers 2


I agree that the specification is a bit ambiguous.

Looking at the source code, as a client, you can sign the message now but the message is not yet valid. When the server verifies the message, verification fails before the signature is checked (see implementation).

To answer your questions:

  • Setting "Not-Before" in the future makes the message invalid now but it will become valid in the future (if other parameters and signature are valid) (e.g. see phantom wallet docs).
  • As a wallet provider, I would allow signing such messages because the message is verified on the server side. There may be use cases, where it may be useful to sign a message today that can be used in the future to sign in.

Option number 2 (The message is 'valid' and can be signed now, but the signature can be used only after the "Not-Before" date.).

"Valid" is perhaps the tricky word here, since in terms of whether a specific Sign-in With Ethereum (SIWE) can be used as authentication, all messages are "invalid" until signed. If an end user is not permitted to sign "an invalid message", then no draft SIWE messages could be signed. So, "valid" to be used for authentication and "valid" for the user to sign have to be two separate things.

If the Sign-in With Ethereum (SIWE) specification only allowed end users to create messages with not-before dates in the past, then the parameter would be useless because issued-at also exists in the specification and is required. If both issued-at and not-before dates were required to be in the past, then there's no real point in the duplication.

Therefore, a SIWE message is "valid" to be signed if the structure is appropriate (i.e. if not-before is present, it's an ISO-formatted date). Similar to a "postdated" paper check: if a paper check has a date on it in the future, it's still "a check" (it is a valid message), but it's only actionable if the owner has signed it. Similarly, the SIWE message is a valid message if structured properly, but not actionable until paired with a signature from the owning address.

What is likely ambiguous is how each site will handle valid, signed SIWE messages that do have a not-before date in the future. If a site knows their own login process never "postdates" a SIWE message, they may view a client connection that presents a SIWE with a not-before date in the future as an attacker and silently flag that client connection as malicious (e.g. take strikes toward an IP block). While another site that does provide a mechanism for users to take an action in the future (e.g. start of a rental period, or as authorization for a third-party to take an action on their behalf but it must be within a certain time window) might parse it and display it as a formatted notification to the end-user, for the context it means on their site ("Alice, your rental period hasn't started yet; come back at "). I think that's fine for sites to handle it differently like this, and it can be a user education point that users should be asking questions of the apps they interact with to know how that specific project handles this field.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.