Test voting delegation #857
In order to make voting more convenient for the contributors, we are exploring delegation of voting rights. The flow of the delegation is the following: Granter gives grantee permission to send specific message types on their behalf. The grantee uses MsgExec to run those messages; the chain checks the authz grant and treats the message as coming from the granter.
Permissions needs to: 1. be granted 2. allow action under permission to be executed 3. be revoked if necessary
Testnet will be used for the flow verification.
💬 Comments (4)
Hey @mayveskii, could you please clarify why you referenced this issue in [d4e74c4] and [e5995db]? Do you have any issues with delegating?
Hey @Mayveskii, could you please clarify why you referenced this issue in [d4e74c4] and [e5995db]? Do you have any issues with delegating?
Hi, Tanya! I'm interested in participating as a grantee in the delegation test.
My address: gonka1l38meyucc0ajwdhn6ssevsj0xpvm3dysu59mh8 Account registered on-chain: account_number 1130693
Could you also send a small amount of tokens to this address so I can participate? Currently working on GIP #859 (semantic cache) and need tokens for both the delegation test and inference validation.
Hey @Mayveskii, could you please clarify why you referenced this issue in [d4e74c4] and [e5995db]? Do you have any issues with delegating?
I referenced it intentionally — while working on GIP #859 I found that MsgSubmitCacheQualitySummary was missing from InferenceOperationKeyPerms, which was blocking the Grant→Exec→Revoke flow you're testing in #857. Fixed it as part of the same permissions audit. No issues with delegating.
🔄 Auto-synced from Issue #857 every hour.
all test cases on testnet PASSED with a caveat that the TX does not fail explicitly. (Expected: Tx fails (e.g. “authorization not found” / “unauthorized”). Reality: Nothing indicating that the voting did not go through)
1. [pass] Happy path
2. [pass] Revoke
3. [pass] Overwrite / double vote
Grantee votes Yes via authz exec → granter votes No (or Yes) with main key.
Expected: second vote replaces first (only one vote per address)
Grantee votes → revoke → granter votes with main key.
Expected: Granter’s direct vote is valid; grantee can no longer vote (revoke test).
4. [pass] Wrong signer / wrong grantee
JSON has grantee = A, but you sign with key for B (or granter key).
Expected: Tx fails (e.g. “authorization not found” / “unauthorized”). ——— fail here! Nothing indicating that the voting did not go through
grantee in JSON is not the address that was actually granted.
Expected: Tx fails when chain checks authz.
Grant is for MsgVote; grantee sends vote for proposal_id that doesn’t exist or is not in voting.
Nothing indicating that the voting did not go through
Grant is only for /cosmos.gov.v1beta1.MsgVote. Grantee sends authz exec with a different message (e.g. Send).
Nothing indicating that the voting did not go through - however the money was not sent
Create grant with short expiration, wait until after expiry, then grantee votes.
Nothing indicating that the voting did not go through
8. [pass] Multiple grantees
Expected: second exec overwrites.
9. [pass] Tally and visibility
9. Summary table (for your setup)
Test | Action | Expected -- | -- | -- Happy path | Grant → grantee exec (Yes) | Success; granter has Yes on proposal Revoke | Revoke → grantee exec | Fail (no permission) Overwrite (no revoke) | Grantee votes → granter votes on main | Second vote replaces or fails (define) Overwrite (with revoke) | Grantee votes → revoke → granter votes | Granter vote succeeds; grantee cannot vote Change vote | Grantee Yes → grantee No (same proposal) | Replace or “not allowed” (define) Wrong signer | exec with --from ≠ grantee | Fail Wrong grantee in JSON | grantee ≠ actual grantee | Fail Wrong proposal | Vote for invalid/wrong proposal_id | Fail Wrong message type | Exec a non‑granted message type | Fail Expired grant | Vote after grant expiration | Fail Tally | Query votes after success | Granter appears with correct option