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

Deprecate GetTransferAccount in ics20 #545

Closed
3 tasks
colin-axner opened this issue Nov 17, 2021 · 2 comments · Fixed by #1250
Closed
3 tasks

Deprecate GetTransferAccount in ics20 #545

colin-axner opened this issue Nov 17, 2021 · 2 comments · Fixed by #1250
Assignees
Labels
20-transfer type: refactor Architecture, code or CI improvements that may or may not tackle technical debt.

Comments

@colin-axner
Copy link
Contributor

Summary

A module account for ics20 is created and there exists an associated GetTransferAccount function. We never use the transfer module account as every escrow address is created as a regular account. We may want to migrate the escrow addresses to sub-accounts in the future, but a GetTransferAccount function will not be needed for this purpose (escrows will never be made to the module account)


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@crodriguezvega
Copy link
Contributor

crodriguezvega commented Nov 22, 2021

Is the following the work needed for this?

  1. Delete this function.
  2. Delete this function.
  3. Remove this in InitGenesis.

Since we're changing the InitGenesis function, is there any considerations that we need to take care of when releasing this?

@crodriguezvega crodriguezvega added this to the v2.0.2 milestone Nov 23, 2021
@colin-axner
Copy link
Contributor Author

Is the following the work needed for this?

Correct.

Since we're changing the InitGenesis function, is there any considerations that we need to take care of when releasing this?

No, since this is API breaking, it needs to be included in a major release and thus state machine breaking considerations don't matter. Chains needs to run on the same minor or major release

@crodriguezvega crodriguezvega modified the milestones: v2.0.2, v3.0.0 Nov 25, 2021
@crodriguezvega crodriguezvega modified the milestones: v3.0.0, v5.0.0 Dec 16, 2021
@crodriguezvega crodriguezvega added the type: refactor Architecture, code or CI improvements that may or may not tackle technical debt. label Jan 3, 2022
@crodriguezvega crodriguezvega moved this to Backlog in ibc-go Jan 3, 2022
@crodriguezvega crodriguezvega self-assigned this Mar 22, 2022
@crodriguezvega crodriguezvega moved this from Backlog to Todo in ibc-go Apr 4, 2022
@crodriguezvega crodriguezvega moved this from Todo to In review in ibc-go Apr 13, 2022
Repository owner moved this from In review to Done in ibc-go Apr 13, 2022
CosmosCar pushed a commit to caelus-labs/ibc-go that referenced this issue Nov 6, 2023
- rename go module
- rename imports
- rename all comments
- rename variables/structs/etc with opti and optimint in their name
- fix links (badges/etc)
- update ADRs
- grep entire directory to ensure full rename

Reference: cosmos#535
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
20-transfer type: refactor Architecture, code or CI improvements that may or may not tackle technical debt.
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants