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: payee registration and fee distribution for relayer operators #1577

Merged
merged 7 commits into from
Jun 27, 2022

Conversation

damiannolan
Copy link
Member

Description

  • About fees and pay out semantics
  • How to register payee addresses for reverse/timeout relayer fee distribution
  • How to register counterparty addresses for forward relayer fee distribution
  • Message defs, validity of fields and example CLIs

ref: #1408


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes


Packet fees are divided into 3 distinct amounts in order to compensate relayer operators for packet relaying on fee enabled IBC channels.

- `RecvFee`: The sum of all packet receive fees distributed to a payee for successful execution of `MsgRecvPacket`.
Copy link
Contributor

@seantking seantking Jun 24, 2022

Choose a reason for hiding this comment

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

Seeing as we're saying the sum of all packet receive fees it might be worth noting above that a packet fee can be 'topped up' multiple times. wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe that could be added to the section Escrowing and paying out fees of @charleenfei's PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, possibly adding to @charleenfei's PR would be a nice idea and segway into linking to this docs page.

#1572 (comment)

Copy link
Member

Choose a reason for hiding this comment

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

Yea, though the fact that the fees are stored as separate structs is an implementation detail imo. I think it makes sense to say that RecvFee here is the fee that will be distributed to the payee for a successful execution of RecvPacket

And in the escrowing section we can document that the recvFee along with other fees can be topped up multiple times. wdyt?

Copy link
Contributor

@crodriguezvega crodriguezvega left a comment

Choose a reason for hiding this comment

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

Nice work! I left just some nits.

docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved
docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved

Packet fees are divided into 3 distinct amounts in order to compensate relayer operators for packet relaying on fee enabled IBC channels.

- `RecvFee`: The sum of all packet receive fees distributed to a payee for successful execution of `MsgRecvPacket`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe that could be added to the section Escrowing and paying out fees of @charleenfei's PR.

docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved
docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved
docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved
docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved
docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved
docs/middleware/ics29-fee/fee-distribution.md Outdated Show resolved Hide resolved
Co-authored-by: Carlos Rodriguez <carlos@interchain.io>
Co-authored-by: Sean King <seantking@users.noreply.github.com>
@damiannolan damiannolan enabled auto-merge (squash) June 27, 2022 14:26
@damiannolan damiannolan merged commit 8be6a10 into main Jun 27, 2022
@damiannolan damiannolan deleted the damian/1408-fee-mw-relayer-ops branch June 27, 2022 14:28

# Fee distribution

Learn about payee registration for the distribution of packet fees. The following document is intended for relayer operators. {synopsis}
Copy link
Member

Choose a reason for hiding this comment

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

Nice. This is a meta-level comment but perhaps we can have who the document is intended for as its own seperate section at the top?


Packet fees are divided into 3 distinct amounts in order to compensate relayer operators for packet relaying on fee enabled IBC channels.

- `RecvFee`: The sum of all packet receive fees distributed to a payee for successful execution of `MsgRecvPacket`.
Copy link
Member

Choose a reason for hiding this comment

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

Yea, though the fact that the fees are stored as separate structs is an implementation detail imo. I think it makes sense to say that RecvFee here is the fee that will be distributed to the payee for a successful execution of RecvPacket

And in the escrowing section we can document that the recvFee along with other fees can be topped up multiple times. wdyt?

The counterparty payee address registered on the destination chain is encoded into the packet acknowledgement and communicated as such to the source chain for fee distribution.
If a counterparty payee is not registered for the forward relayer on the destination chain, the escrowed fees will be refunded upon fee distribution.

A transaction must be submitted to the desintation chain including a `CounterpartyPayee` address of an account on the source chain.
Copy link
Member

Choose a reason for hiding this comment

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

destination

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants