Authorization Module (x/authz)
Thex/authz module enables one account (the granter) to grant arbitrary privileges to another account (the grantee) to execute messages on their behalf. This powerful delegation mechanism allows for flexible authorization patterns across your blockchain application.
Overview
x/authz implements ADR 030 to provide a framework where accounts can authorize other accounts to perform specific actions without sharing private keys. Authorizations are granted per message type and can include spending limits, time expiration, and custom validation logic.
Key Concepts
Authorization Interface
TheAuthorization interface is the core abstraction that all authorization types must implement:
Accept method is called to validate the request:
Grant Storage
Grants are stored with a composite key:- Authorization: The specific authorization logic (e.g., SendAuthorization)
- Expiration: Optional timestamp when the grant expires
Built-in Authorization Types
GenericAuthorization
Grants unrestricted permission to execute any message of a specific type:- Allowing a trading bot to execute trades on your behalf
- Granting a service account permission to submit governance proposals
SendAuthorization
Restricts token transfers with spending limits and optional allow-lists:StakeAuthorization
Controls delegation, undelegation, and redelegation operations:AllowList or DenyList must be specified, but not both.
Message Handlers
MsgGrant
Create or update an authorization grant:- Granter and grantee must be different addresses
- Expiration must be in the future (if provided)
- Authorization must be a valid implementation
- Message type must have a registered handler
MsgRevoke
Revoke an existing authorization:MsgExec
Execute authorized messages on behalf of the granter:Grant Expiration & Pruning
The authz module automatically prunes expired grants using a grant queue:BeginBlock, the keeper removes all grants with expiration times before the current block time:
Query Endpoints
Grants
Query all grants between a granter and grantee:Gas Considerations
Iterating over grant queues and validator lists consumes gas:StakeAuthorization, gas is charged for iterating through allowed/denied validator lists to prevent DoS attacks.
Use Cases
Trading Bot Authorization
Recurring Payments
Governance Delegation
Events
The authz module emits events for all grant operations:EventGrant
EventRevoke
CLI Examples
Grant Authorization
Execute Authorized Action
Revoke Authorization
Query Grants
Integration Guide
To use authz in your module:- Define a custom authorization:
- Register your authorization:
Best Practices
- Always set expiration times for grants to limit exposure
- Use specific authorizations (like SendAuthorization) over generic ones when possible
- Monitor grant usage through events to detect anomalies
- Revoke grants when they’re no longer needed
- Test authorization logic thoroughly before deploying
- Consider gas costs when iterating over large validator sets in StakeAuthorization
Security Considerations
- Granting
GenericAuthorizationgives unrestricted access to execute any message of that type - Always validate that grantee addresses are trusted before creating grants
- Monitor for unexpected
MsgExectransactions from your account - Set conservative spending limits on
SendAuthorizationgrants - Be cautious with long expiration times on sensitive authorizations