Slush zkLogin signPersonalMessage produces stale/invalid maxEpoch, breaks downstream SessionKey retrieval

[aionchainops]

Summary

signPersonalMessage on a zkLogin Slush account produces an envelope with an
invalid maxEpoch value. This breaks any downstream flow that depends on a
correctly epoch-bound personal message signature — in our case, Seal
SessionKey retrieval fails 100% of the time for zkLogin accounts.

On-chain transaction signing on the same wallet, in the same session, is
unaffected — the fault is isolated to signPersonalMessage specifically.

Evidence

A captured signPersonalMessage envelope from a zkLogin Slush account showed:

maxEpoch: 8

against a current network epoch of ~1229 at time of capture.

This is not staleness or decay from an earlier session — epoch 8 corresponds
to mainnet's first fortnight (May 2023). The account in question did not
exist then. The same wallet's own on-chain transactions in the same time
window correctly carried maxEpoch: 1230, confirming transaction signing
reads the epoch correctly while signPersonalMessage does not.

Reproduction

1. Create or use an existing zkLogin account in Slush (web or extension).
2. Call signPersonalMessage on any message.
3. Inspect the resulting envelope's maxEpoch field.
4. Compare against the actual current network epoch at time of signing.

Expected: maxEpoch reflects a value consistent with the current epoch
(matching what the same wallet's transaction signing produces).

Actual: maxEpoch returns a stale/fixed value (observed: 8), regardless of
current epoch or session freshness.

Impact

Any dApp relying on signPersonalMessage output for epoch-bound verification
(e.g. Seal SessionKey retrieval) will fail for 100% of zkLogin Slush users,
on the first attempt, not intermittently. This is currently blocking a
production payment flow that uses Slush as its primary zkLogin onramp.

Environment

• Wallet: Slush (web)
• Login method: zkLogin (social login)
• Confirmed via: direct envelope inspection + cross-reference against the
  same wallet's correctly-signed on-chain transactions in the same window

[github-actions]

Thank you for opening this issue, a team member will review it shortly. Until then, please do not interact with any users that claim to be from Sui support and do not click on any links!

[aionchainops]

i posted it here, last week, https://forums.sui.io/t/slush-web-wallet-signpersonalmessage-builds-an-expired-zklogin-envelope/49422

[williamrobertson13]

@aionchainops thanks for the report! can you try calling signPersonalMessage with the chain argument set to sui:mainnet? right now the Slush Web wallet interface defaults to sui:devnet which is a poor default. I'm working on updating that, but it would be good if you could see if this resolves your issue in the meantime!

[aionchainops]

Already on it, and thanks for the fast turnaround.

Applied chain: "sui:mainnet" at our signPersonalMessage call site and it's
deployed to our QA build. End-to-end retrieval test is tomorrow — I'll
report back either way.

One detail from our side that may be useful confirmation: every
signTransaction call in our app already passed chain: "sui:mainnet".
Only signPersonalMessage omitted it. That single omission is exactly why
payments always worked and SessionKey retrieval never did, which lines up
with your read that the default is the problem.

Agree the default change is still worth landing. The failure surfaces well
downstream of the call, at signature verification against mainnet, so
without the chain in hand it's a hard one to trace back — maxEpoch 8 reads
as a stale value rather than a correctly-formed devnet one.

[aionchainops]

Reporting back as promised — the workaround works.

Passing chain: "sui:mainnet" explicitly at our signPersonalMessage call
site resolved it on the pinned @mysten/slush-wallet 1.1.13. Confirmed with
diagnostics: the envelope now carries maxEpoch 1239 against a current epoch
of ~1239, where the broken value was 8.

We've since had successful end-to-end Seal retrievals on desktop Chrome,
iPad Brave, iPad Chrome and iPhone Safari, all on a zkLogin account. The
whole chain works: SessionKey, signature, key servers, decrypt.

Two things that might be useful to you:

Every signTransaction call in our app already passed chain explicitly.
Only signPersonalMessage omitted it. That single omission was the whole
difference between payments always working and SessionKey retrieval never
once working, which is why it looked like a Seal problem for weeks rather
than a wallet-standard default.

And the failure surfaces a long way downstream — at signature verification
against mainnet, not at the call. maxEpoch 8 reads as a stale or
uninitialised value rather than a correctly-formed devnet one, which sent
us looking in the wrong place.

Worth landing the default change regardless. The workaround only helps
people who already know what's wrong.