Test voting delegation

[maria-mitina]

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.

[maria-mitina]

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

• [pass] Grant → Grantee votes (Yes) with authz exec → Tx succeeds → Proposal votes show granter with Yes.
• [pass] same for Abstain, No, and NoWithVeto.

2. [pass] Revoke

• Revoke MsgVote for that grantee.
• Grantee runs authz exec again (same or new proposal).
• Expected: Tx fails (e.g. “authorization not found” / “unauthorized”). ——— fail here! Nothing indicating that the voting did not go through
• [pass] Variant: Revoke, then re-grant → grantee votes again → expected success.

3. [pass] Overwrite / double vote

• [pass] 3a. Grantee votes, then granter votes (no revoke)

Grantee votes Yes via authz exec → granter votes No (or Yes) with main key.

Expected: second vote replaces first (only one vote per address)

• [pass] 3b. Grantee votes, then revoke, then granter votes

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

• [pass] 4a. Wrong --from

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

• [pass] 4b. Wrong grantee in JSON

grantee in JSON is not the address that was actually granted.

Expected: Tx fails when chain checks authz.

1. [pass] Authorization boundaries

• [pass] 5a. Wrong proposal

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

• [pass] 5b. Wrong message type

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

• [pass] 5c. Expired grant

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

• Granter grants MsgVote to grantee A and grantee B (two grants).
• A votes Yes, B votes No (or abstain) on behalf of the same granter.

Expected: second exec overwrites.

9. [pass] Tally and visibility

• After a successful authz exec, query proposal votes by proposal id.
• Expected: Listed voter is granter address, option matches what you sent (Yes/No/Abstain/NoWithVeto).

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

[tcharchian]

Hey @Mayveskii, could you please clarify why you referenced this issue in [d4e74c4] and [e5995db]? Do you have any issues with delegating?

[Mayveskii]

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.

[Mayveskii]

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.