AuthZ module: Education on the risks is needed!

As we see more and more Cosmos based chains rolling out the “AuthZ” module we think it is important to have a larger debate on the potential security breach it can cause to unaware users. It is even more important to be proactive right here in the Hub because we also have the Liquid Staking Module module (LSM) which can further fuel the fire if combined with malicious AuthZ usage. As we wait to get an appropriate response from wallet providers introducing visible warnings on potential risky transactions approval, we need to have our community informed of both the wonders and the dangers that come along with this module.

Source: x/authz | Explore the SDK

x/authz is an implementation of a Cosmos SDK module, per ADR 30, that allows granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of the Authorization interface.

To give a bit of context for regular Cosmos users, this module makes it possible to use services like REStake | Auto-compound your staking rewards. Its utility covers a much wider range of potential use cases, including advanced account management, with many more expected to come in the future.

What users are less aware of is the dangerous capabilities this also carries. To explain what those are, let’s have a look at the types of transactions the authZ module can execute:

  • MsgGrant​: This is the initiation transaction to allow a certain type of action as well as specifying the conditions associated with that (more details later).
  • MsgRevoke​: To remove an existing Grant.

Therefore, users should pay extra attention to any transaction they sign on their wallet that is related to the MsgGrant function.

Here is an example of the signature required by Restake to perform their actions on your behalf, in which you can find the aforementioned MsgGrant as well as all the details associated with that request:

At the current time, there is no specific warning sign in the Keplr wallet related to an authz transaction. But it is imperative that users pay an extreme amount of attention to these custom transactions and understand what they are signing. It is unfortunate that protections are not yet in place to prevent users from signing without reading carefully. It will likely happen in the future, but in the meantime, the risk is real, and careless users could face serious harm if they sign malicious authZ transactions without reading.

To understand what a malicious authZ could look like, let’s break down the types of permissions that a MsgGrant can ask for:

  • GenericAuthorization​: implements the Authorization interface that gives unrestricted permission to execute the provided Msg on behalf of granter’s account. YOU SHOULD BE VERY CAREFUL SIGNING SUCH TRANSACTION unless being strictly in control of what you’re about to do. These one can allow access to any module’s msg transaction types. For example, you may me comfortable signing a msg type corresponding to claiming rewards if it is related to a restake protocol. But if you have any doubts, always make sure to delay the operation and reach out to a competent person. Most of the time your validator representatives will be there to help you figuring out what is safe and what is not.
  • SendAuthorization​: implements the MsgSend authorization, allowing the grantee to send coins from the granter’s balance. Arguments take a (positive) SpendLimit that specifies the maximum amount of tokens the grantee can spend and an optional AllowList that specifies to which addresses a grantee can send token.
  • StakeAuthorization​: it takes an AuthorizationType to specify whether you want to authorise delegating, undelegating or redelegating (i.e. these have to be authorised seperately). It also takes a required MaxTokens that keeps track of a limit to the amount of tokens that can be delegated/undelegated/redelegated. If left empty, the amount is unlimited. Additionally, this Msg takes an AllowList or a DenyList, which allows you to select which validators you allow or deny grantees to stake with.

Now you have all the necessary information to understand what an authZ transaction can do. It can be used for great purposes, but if left unchecked and signed carelessly, any malicious actor could be empowered with enormous capabilities over your wallet. It could spend your coins or do even more than that if you ever grant an unwanted GenericAuthorization to a scammer.

As we wait until wallets implement necessary warnings regarding authZ transaction signatures, it is up to the users to be extra careful themselves. This is why we think that it is our responsability as active community members right here in this forum to take the necessary actions in order to inform the broader community of Cosmos users.

We hope to hear from anyone having propositions to assess this situation. Anyone having direct contact to the wallet providers would be welcomed to initiate discussions on this matter with them. Influencers and content creators should also use their wider audience to inform users. These are the suggestions we have, don’t hesitate to share your own solutions if you have more.

Thanks for reading,
Govmos (the governance arm of the PRO Delegators’ Validator)


This is vital. I wish there was something similar to Walletguard for Cosmos. It tells you in plain text exactly the rights you are granting, what signing does, etc.

Also has functionality to scan existing grants from your address so you can remove risky site permissions.

1 Like

We’re working on this as well as many other projects I guess. This is another crucial feature we badly need into the mainstream wallet providers.


I’m agree, a warning is required
I won’t be so radical on GenericAuthorization, I imagine it can be useful otherwise we should simply delete it !?
But indeed Authz must be used with caution.

1 Like

Happy to take additional feedback, and thank you for bringing up this discussion.

FYI you can already scan for AuthZ permissions you have given out on Keplr:

CleanShot 2024-02-29 at 23.10.27

Also we show additional warnings when users are about to MsgGrant a generic exec or send txs

1 Like

Thank you for providing more context to the matter. Unfortunately the screenshot I provided in this topic is dated from the moment of that post. Which means that improvements are still required on the alerting as it hasn’t been applied to the case presented above. Of course those custom transactions can take multiple forms which likely explains the difficulty to cover them all at the moment.

Anyway, it is evident that things are moving in the right direction and we couldn’t be happier to see this.

If we can suggest additional security features, we would recommend locking the “Approve” button for at least 10s before accepting the user’s action. This would ensure no one is clicking on it following a repetitive routine and inadvertently clicking before considering the additional warning displayed.


IMHO, the most valuable work in this direction should be done by explorers and wallets. Todays UI isnt ready to educate newly onboarded users, alas. Agreed, education here is vital