Revert #778: gate EVM submitters at their EVM address, not the derived Zilliqa address#780
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reverts #778 (
f0339c68).Why
#778 derived a MetaMask user's Legacy/Zilliqa (SHA256) address from the signature and used it for the gZIL gate / scoring / members. That assumption was wrong: on Zilliqa, a MetaMask account holds its ZRC2 tokens (gZIL) at its EVM (Keccak) address, not at the legacy Zilliqa address.
Verified against a real account (same private key in MetaMask + ZilPay):
0x8307a100…167198(zil1svr6zq…)0xaaA6833…035f34(zil142ngx…)The user signed in with MetaMask (the EVM account, which holds the 40 gZIL), but #778 normalized
body.addressto the legacy account (0xaaA6833…, empty) and the gate returnedMIN_BALANCE. #778's derivation was correct (it does compute the legacy address) — but it pointed the balance check at the wrong one of the user's two accounts.What this restores
The original behavior: gate/scoring/members use the address the user signed with (
body.address):gZIL[0x8307a100…]= 40 → passes.This is also the correct governance rule and avoids double-counting voting power: a user's gZIL is counted once, at the address controlled by the wallet they signed with (signing with the other wallet yields its own balance, typically 0). Forcing everyone onto the legacy address (keeping #778) would instead require every MetaMask holder to move their gZIL across accounts.
Scope
zilliqaAddressFromEVMSignaturehelper + its test + thebody.addressnormalization + thepackage.jsontest-script line (all of fix(governance-api): normalize EVM (MetaMask) submitters to their Zilliqa address #778).timeoutSec: 90) — unaffected.sig.message === body.msgguard, is a separate open PR and is independent.)Verify on staging
With MetaMask account
0x8307a100…(40 gZIL), create a gZIL-space proposal → expect201;GET /api/gzil/proposalsshows the author as the EVM address. ZilPay holders continue to work as before.