# ADR 030: Authorization Module
- 2019-11-06: Initial Draft
- 2020-10-12: Updated Draft
- 2020-11-13: Accepted
- 2020-05-06: proto API updates, use
sdk.ServiceMsg(the latter concept was removed from Cosmos SDK)
This ADR defines the
x/authz module which allows accounts to grant authorizations to perform actions
on behalf of that account to other accounts.
The concrete use cases which motivated this module include:
- the desire to delegate the ability to vote on proposals to other accounts besides the account which one has delegated stake
- "sub-keys" functionality, as originally proposed in #4480 (opens new window) which
is a term used to describe the functionality provided by this module together with
fee_grantmodule from ADR 029 and the group module (opens new window).
The "sub-keys" functionality roughly refers to the ability for one account to grant some subset of its capabilities to other accounts with possibly less robust, but easier to use security measures. For instance, a master account representing an organization could grant the ability to spend small amounts of the organization's funds to individual employee accounts. Or an individual (or group) with a multisig wallet could grant the ability to vote on proposals to any one of the member keys.
The current implementation is based on work done by the Gaian's team at Hackatom Berlin 2019 (opens new window).
We will create a module named
authz which provides functionality for
granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations
must be granted for a particular
Msg service methods one by one using an implementation
Authorizations determine exactly what privileges are granted. They are extensible
and can be defined for any
Msg service method even outside of the module where
Msg method is defined.
Msgs using their TypeURL.
For example a
SendAuthorization like this is defined for
MsgSend that takes
SpendLimit and updates it down to zero:
A different type of capability for
MsgSend could be implemented
Authorization interface with no need to change the underlying
# Router Middleware
Keeper will expose a
DispatchActions method which allows other modules to send
to the router based on
tx exec Method
When a CLI user wants to run a transaction on behalf of another account using
can use the
exec method. For instance
gaiacli tx gov vote 1 yes --from <grantee> --generate-only | gaiacli tx authz exec --send-as <granter> --from <grantee>
would send a transaction like this:
tx grant <grantee> <authorization> --from <granter>
This CLI command will send a
authorization should be encoded as
JSON on the CLI.
tx revoke <grantee> <method-name> --from <granter>
This CLI command will send a
# Built-in Authorizations
- Users will be able to authorize arbitrary actions on behalf of their accounts to other users, improving key management for many use cases
- The solution is more generic than previously considered approaches and the
Authorizationinterface approach can be extended to cover other use cases by SDK users
- Initial Hackatom implementation: https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation
- Post-Hackatom spec: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#delegation-module
- B-Harvest subkeys spec: https://github.com/cosmos/cosmos-sdk/issues/4480