FIX: whitelist state issue#164
Conversation
| setHasSignature(params.hasSignature); | ||
| setLastCheckedAddressForSignature(address); | ||
| // On first load, if we have params - consume them, if user switched accounts - strictly check | ||
| const shouldConsumeParams = !hasUsedInitialSignatureParams && params.hasSignature !== undefined; |
There was a problem hiding this comment.
- What is params.hasSignature and where does come from?
- Why can't we just simply check signature from file for any address, without
hasUsedInitialSignatureParamswhich exists only to become true?
There was a problem hiding this comment.
- What is params.hasSignature and where does come from?
params.hasSignature comes from URL query parameters passed to the Vault page. When a user lands on the vault page via a special link (e.g., from an email or marketing campaign), the link contains pre-computed whitelist information:
/0x...?hasSignature=true&isWhitelisted=true
This allows the UI to immediately show the correct whitelist state without waiting for on-chain/config lookup.
- Why can't we just simply check signature from file for any address, without
hasUsedInitialSignatureParamswhich exists only to become true?
We do check the signature from the config file for any address — but we need to know when to trust URL params vs. when to check the file.
When a user first lands on the page via a whitelisted link, the URL contains hasSignature=true. We want to use this immediately so the UI shows the correct state without delay. So on initial load, we trust params.hasSignature and set our state from it.
But here's the problem: if the user then switches their wallet to a different account, the URL params are still the same — they still say hasSignature=true for the original address. If we kept trusting the params, we'd incorrectly show that the new account is whitelisted when it might not be.
3 participants
No description provided.