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

docs: add documentation for TransferAuthorization #3044

Merged
merged 5 commits into from
Jan 26, 2023
Merged
Show file tree
Hide file tree
Changes from 3 commits
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
5 changes: 5 additions & 0 deletions docs/.vuepress/config.js
Original file line number Diff line number Diff line change
Expand Up @@ -325,6 +325,11 @@ module.exports = {
directory: false,
path: "/apps/transfer/params.html",
},
{
title: "Authorizations",
directory: false,
path: "/apps/transfer/authorizations.html",
},
],
},
],
Expand Down
47 changes: 47 additions & 0 deletions docs/apps/transfer/authorizations.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# `TransferAuthorization`

`TransferAuthorization` implements the `Authorization` interface for `ibc.applications.transfer.v1.MsgTransfer`. It allows a granter to grant a grantee the privilege to submit MsgTransfer on its behalf. Please see the [Cosmos SDK docs](https://docs.cosmos.network/v0.47/modules/authz) for more details on granting privileges via the `x/authz` module.
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume we're adding links here later to the first sentence?


More specifically, the granter allows the grantee to transfer funds over a specified channel that belong to the granter.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
More specifically, the granter allows the grantee to transfer funds over a specified channel that belong to the granter.
More specifically, the granter allows the grantee to transfer funds that belong to the granter over a specified channel.

To avoid potential confusion, it's not the channel that belongs to the granter (nit)


For the specified channel, the granter shall be able to specify a spend limit of a specific denomination they wish to allow the grantee to be able to transfer.
Copy link
Member

Choose a reason for hiding this comment

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

ditto on "shall" wording

Copy link
Contributor

@tmsdkeys tmsdkeys Jan 25, 2023

Choose a reason for hiding this comment

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

additionally, it's also required to set the spend limit right so perhaps 'must' is better here


The granter shall be able to specify the list of addresses that they allow to receive funds. If empty, then all addresses are allowed.
Copy link
Member

Choose a reason for hiding this comment

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

maybe we shouldn't use "shall" wording? what do you think?

Suggested change
The granter shall be able to specify the list of addresses that they allow to receive funds. If empty, then all addresses are allowed.
The granter may specify a list of addresses that they allow to receive funds. If empty, then all addresses are allowed.



It takes:

- a `SourcePort` and a `SourceChannel` which together comprise the unique transfer channel identifier over which authorized funds can be transferred.

- a `SpendLimit` that specifies the maximum amount of tokens the grantee can spend. The `SpendLimit` is updated as the tokens are spent. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes.

- an `AllowList` list that specifies the list of addresses that are allowed to receive funds. If this list is empty, then all addresses are allowed to receive funds from the `TransferAuthorization`.

Setting a `TransferAuthorization` is expected to fail if:
- the spend limit is nil
- the denomination of the spend limit is an invalid coin type
- the source port ID is invalid
- the source channel ID is invalid
- there are duplicate entries in the `AllowList`

Below is the `TransferAuthorization` message:

```golang
func NewTransferAuthorization(allocations ...Allocation) *TransferAuthorization {
return &TransferAuthorization{
Allocations: allocations,
}
}

type Allocation struct {
// the port on which the packet will be sent
SourcePort string
// the channel by which the packet will be sent
SourceChannel string
// spend limitation on the channel
SpendLimit github_com_cosmos_cosmos_sdk_types.Coins
Copy link
Member

Choose a reason for hiding this comment

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

maybe we can just use sdk.Coins?

Suggested change
SpendLimit github_com_cosmos_cosmos_sdk_types.Coins
SpendLimit sdk.Coins

// allow list of receivers, an empty allow list permits any receiver address
AllowList []string
}

```