Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: authz rules grant specific #3

Draft
wants to merge 30 commits into
base: vitwit/v0.50.5
Choose a base branch
from
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions x/auth/ante/authz_rules_spec.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# Description

Problem:
The existing authorization (authz) module lacks the flexibility to grant permissions (authz grants) for various types of messages along with specific conditions or rules. This limitation constrains users from customizing their transaction behavior based on specific needs or strategies.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The existing authorization (authz) module lacks the flexibility to grant permissions (authz grants) for various types of messages along with specific conditions or rules. This limitation constrains users from customizing their transaction behavior based on specific needs or strategies.
The current authorization (authz) module lacks the flexibility needed to grant permissions (authz grants) for various types of messages along with specific conditions or rules. This limitation prevents users from customizing their transaction behavior according to specific needs or strategies.
To address this issue, we propose enhancing the authz module to support more granular permissions and conditional rules, allowing for greater customization and control over transaction authorization.


## Specific Examples of Limitations:
Swapping Reward Tokens:
- Currently, users cannot set a rule to swap their reward tokens or any other tokens for another token with a specified limit.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Swapping Reward Tokens:
- Currently, users cannot set a rule to swap their reward tokens or any other tokens for another token with a specified limit.
Managing Reward Tokens:
At present, users are able to restake their tokens via authz. But it can do more. Currently users are unable to establish rules for swapping their reward tokens as a strategy as it requires IBCTransfer or PacketForward msgs access. It's not secure to give this grant currently as the recipient address can be anything and grantee can behave maliciously. But if there's a way to restrict recipient address to match with granter's address, this problem is solved. This functionality is necessary to enable users to automate and customize their token management strategies effectively.

Sending Tokens to Selected Addresses:
- Users are unable to authorize sending tokens to a pre-defined or selected address, restricting the ability to control where tokens are transferred.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Users are unable to authorize sending tokens to a pre-defined or selected address, restricting the ability to control where tokens are transferred.
- Users currently cannot authorize sending tokens to a pre-defined or selected address. This restriction limits their ability to control and automate the transfer of tokens to specific recipients, thereby reducing the efficiency and flexibility of their token management strategies. For example, if an organization wants to authorize an accountant to process salaries every month, the current system's limitations prevent this. Implementing an authz grant to recurrently allow a user to send a specified amount to certain accounts would solve this issue. This feature would automate salary payments, ensuring timely and accurate transactions while reducing administrative overhead.

Staking Tokens with Limitations:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

replace it with gov usecase..

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, consider spec format of cosmos-sdk. It describes the problem, but clearly explain about solution, conclusion etc instead of PR diff.

- The module does not allow users to grant permission to stake tokens with certain limits or to stake only with selected validators. This limits the user's control over staking decisions.

## PR diff:
This PR adds a feature which an authz can be granted with some rules,
for example:
- if a staker wants to stake some portion of rewards he can do that by allowing max stake amount
- if he wants to stake only to selected validators
- swap some portion of rewards to another token or liquid staked token
- also we can add rules to every message before granting.

Changes:
updated the ante handlers flow to check in the message is executing the authz message and any rules need to be checked before processing the message. if the message is not reaching the rules then it will eventually fail.

added an extra ante handler:
```
// handleCheckSendAuthzRules returns true if the rules are voilated
func (azd AuthzDecorator) handleSendAuthzRules(ctx sdk.Context, msg *banktypes.MsgSend, grantee []byte) error {
granter, err := azd.ak.AddressCodec().StringToBytes(msg.FromAddress)
if err != nil {
return err
}

_, rules := azd.azk.GetAuthzWithRules(ctx, grantee, granter, sdk.MsgTypeURL(&banktypes.MsgSend{}))
for _, rule := range rules {
if rule.Key == authztypes.AllowedRecipients {
isAllowed := false
for _, allowedRecipient := range rule.Values {
if msg.ToAddress == allowedRecipient {
isAllowed = true
break
}
}

if !isAllowed {
return errorsmod.Wrap(sdkerrors.ErrTxDecode, "Recipient is not in the allowed list of the grant")
}
}

if rule.Key == authztypes.MaxAmount {
limit, err := sdk.ParseCoinsNormalized(strings.Join(rule.Values, ","))
if err != nil {
return err
}
if !limit.IsAllGTE(msg.Amount) {
return errorsmod.Wrap(sdkerrors.ErrTxDecode, "Amount exceeds the max_amount limit set by the granter")
}
}

}

return nil
}
```
the above snippet checks the rules for `MsgSend` likewise we can add checks to every messages.
Loading