Create ics27-multiplexed-requirements.md #6281
Conversation
womensrights
requested review from
colin-axner,
AdityaSripal,
crodriguezvega,
charleenfei,
damiannolan,
chatton,
DimitrisJim and
srdtrk
as code owners
WalkthroughWalkthroughThe Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Out of diff range and nitpick comments (7)
docs/requirements/ics27-multiplexed-requirements.md (7)
11-11: Consider adding a comma after "Account Flexibility" for better readability.
13-13: Consider using "time-consuming" with a hyphen for correct spelling.
19-19: Use "add-on" with a hyphen in this context for correct spelling.
26-26: Use "per-user" with a hyphen when used as an adjective.
56-56: Consider adding a comma after "requirements" for better readability.
83-83: Use "per-user" with a hyphen when used as an adjective.
85-85: Ensure consistency in spelling; use either "acknowledgement" or "acknowledgment" throughout the document.
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/requirements/ics27-multiplexed-requirements.md (1 hunks)
Additional Context Used
LanguageTool (7)
docs/requirements/ics27-multiplexed-requirements.md (7)
Near line 11: Possible missing comma found.
Context: ... are listed: - Account Flexibility - Currently host accounts can only be of type `Base...
Near line 13: This word is normally spelled with a hyphen.
Context: ...uts and subsequent channel closures are time consuming and difficult to manage - *Scalability...
Near line 19: This noun is usually spelled with a hyphen.
Context: ...iddleware solves this problem but is an add on to the application rather than a defaul...
Near line 26: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...nt management for accounts created on a per user basis - To streamline workflows using t...
Near line 56: Possible missing comma found.
Context: ...desirable, it is out of scope for these requirements as a solution is applicable to applicat...
Near line 83: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...implementing additional middleware on a per user basis | ------------ | ------ | | 3.06 ...
Near line 85: Do not mix variants of the same word (‘acknowledgement’ and ‘acknowledgment’) within a single text.
Context: ...in account and return the result in the acknowledgement | ------------ | ------ | ### 4 - Ho...
GitHub Check Runs (1)
lint failure (3)
docs/requirements/ics27-multiplexed-requirements.md: [failure] 53-53: Headings should be surrounded by blank lines
docs/requirements/ics27-multiplexed-requirements.md:53 MD022/blanks-around-headings Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "# Functional requirements"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md
docs/requirements/ics27-multiplexed-requirements.md: [failure] 54-54: Headings should be surrounded by blank lines
docs/requirements/ics27-multiplexed-requirements.md:54 MD022/blanks-around-headings Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Above] [Context: "## Assumptions and dependencies"] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md022.md
Path-based Instructions (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
| # Functional requirements | ||
| ## Assumptions and dependencies |
There was a problem hiding this comment.
Ensure that headings are surrounded by blank lines for proper markdown formatting.
+ Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| # Functional requirements | |
| ## Assumptions and dependencies | |
| # Functional requirements | |
| ## Assumptions and dependencies |
There was a problem hiding this comment.
Actionable comments posted: 9
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/requirements/ics27-multiplexed-requirements.md (1 hunks)
Additional Context Used
LanguageTool (7)
docs/requirements/ics27-multiplexed-requirements.md (7)
Near line 13: This word is normally spelled with a hyphen.
Context: ...uts and subsequent channel closures are time consuming and difficult to manage - *Scalability...
Near line 17: Possible missing comma found.
Context: ...nsfer could succeed and the ICA message fail resulting in an incomplete workflow. ...
Near line 19: This noun is usually spelled with a hyphen.
Context: ...iddleware solves this problem but is an add on to the application rather than a defaul...
Near line 26: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...nt management for accounts created on a per user basis - To streamline workflows using t...
Near line 57: Possible missing comma found.
Context: ...desirable, it is out of scope for these requirements as a solution is applicable to applicat...
Near line 84: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...implementing additional middleware on a per user basis | ------------ | ------ | | 3.06 ...
Near line 86: Do not mix variants of the same word (‘acknowledgement’ and ‘acknowledgment’) within a single text.
Context: ...in account and return the result in the acknowledgement | ------------ | ------ | ### 4 - Ho...
Path-based Instructions (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
| The Interchain Accounts feature has enabled control of an account on a host chain remotely from a controller chain. This has opened up many possibilities for more complex cross-chain workflows beyond token transfer alone, but the current architecture is not easy to use for the case where there are on the order of 1000s of host accounts controlled by many controllers. These requirements aim to alleviate current pain points and ehance the usability of the feature. | ||
|
|
||
| ## Problem | ||
|
|
||
| The current pain points for existing ICA users are listed: | ||
|
|
||
| - *Account Flexibility* - Currently host accounts can only be of type `BaseAccount` | ||
|
|
||
| - *Ordered Channels* - Timeouts and subsequent channel closures are time consuming and difficult to manage | ||
|
|
||
| - *Scalability* - When there are many interchain accounts, and many channels (in the order of 1000s), relayers struggle with the number of queries on startup and performance is compromised. Additionally, account registration being linked to the channel means that multiple packet round trips are required before your host account can execute messages. | ||
|
|
||
| - *Workflows requiring tokens in ICA* - there are no atomic guarantees for a workflow containing multiple applications - i.e. a token transfer followed by an ICA message. The transfer could succeed and the ICA message fail resulting in an incomplete workflow. | ||
|
|
||
| - *Lack of default callbacks* - users are still relying on custom auth modules for packet callbacks, the callbacks middleware solves this problem but is an add on to the application rather than a default | ||
|
|
||
| - *Whitelisiting messages* - this devex is more complicated than having a blacklist | ||
|
|
||
| ## Objectives | ||
|
|
||
| - Enable different account types, to be coontrolled remotely | ||
| - To facilitate performant cross-chain account management for accounts created on a per user basis | ||
| - To streamline workflows using token transfer and interchain accounts in combination | ||
|
|
||
| ## Scope | ||
|
|
||
| | Features | Release | | ||
| | --------- | ------- | | ||
| | Multi-plexed Interchain Accounts | ibc-go v10.0.0 | | ||
|
|
||
| # User requirements | ||
|
|
||
| ## Use cases | ||
|
|
||
| Existing use cases have been detailed in ics27 and ics27 v2 requirements, some other notable use cases used in production are cross chain liquid staking, yield through leveraged lending and cross chain NFT minting. | ||
|
|
||
| ### Liquid Staking | ||
|
|
||
| Chains such as Stride, Quicksilver and pStake control Interchain Accounts on a host chain to stake tokens on behalf of their users and mint representative liquid staking tokens so that users can transact with liquid tokens, rather than a locked staked asset but still earn staking rewards through autocompounding on the Interchain Account. More information on Stride's technical architecture can be found [here](https://github.com/Stride-Labs/stride/tree/main?tab=readme-ov-file#strides-technical-architecture). | ||
|
|
||
| ### Leveraged Lending | ||
|
|
||
| Nolus enables users to borrow assets and use the inflation from staking rewards to repay the interest on the principle. e.g. a user could deposit 10 OSMO as collatoral for a 25 OSMO position. When a user opens a position, an Interchain Account is opened on Osmosis and the loan amount is sent to the account with management of the account through the Nolus chain. | ||
|
|
||
| ### Cross-chain NFT minting | ||
|
|
||
| Nomos enable NFTs to be minted on Injective on host accounts controlled from the Xion chain, providing a single interface for users, enabling chain abstraction. | ||
|
|
||
| # Functional requirements | ||
|
|
||
| ## Assumptions and dependencies | ||
|
|
||
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone. | ||
| - Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required. | ||
| - Assumes use of the `x/accounts` sdk module. | ||
|
|
||
| ## Features | ||
|
|
||
| ### 1 - Configuration | ||
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | | ||
| | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ | | ||
|
|
||
| ### 2 - Registration | ||
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | | ||
| | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | ------------ | ------ | | ||
| | 2.02 | A registered interchain account can be any account type supported by `x/accounts` | ------------ | ------ | | ||
|
|
||
| ### 3 - Control | ||
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | | ||
| | 3.01 | The channel type through which a controller sends transactions to the host should be unordered | ------------ | ------ | | ||
| | 3.02 | The message execution order should be determined at the packet level | ------------ | ------ | | ||
| | 3.03 | Many controllers can send messages to many host accounts through the same channel | ------------ | ------ | | ||
| | 3.04 | The controller of the interchain account should be able to receive information about the balance of the interchain account in the acknowledgment after a transaction was executed by the host | ------------ | ------ | | ||
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per user basis | ------------ | ------ | | ||
| | 3.06 | Callbacks on the packet lifecycle should be supported by default | ------------ | ------ | | ||
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgement | ------------ | ------ | | ||
|
|
||
| ### 4 - Host execution | ||
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | | ||
| | 4.01 | It should be possible to ensure a packet lifecycle from a different application completes before a message from a controller is executed | ------------ | ------ | | ||
| | 4.02 | It should be possible for a controller to authorise a host account to execute specific actions on a host chain without needing a packet round trip each time (e.g. auto-compounding) | ------------ | ------ | | ||
|
|
||
| # Non-functional requirements | ||
|
|
||
| ## 5 - Performance | ||
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | | ||
| | 5.01 | The number of packet round trips to register an account, load the account with tokens and execute messages on the account should be minimised | ------------ | ------ | |
There was a problem hiding this comment.
Remove trailing spaces found in multiple lines.
- Lines with trailing spaces: 5, 15, 17, 25, 39, 47, 51, 57, 58, 65, 66, 67, 71, 73, 78, 90, 99
+ Corrected lines without trailing spaces.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| The Interchain Accounts feature has enabled control of an account on a host chain remotely from a controller chain. This has opened up many possibilities for more complex cross-chain workflows beyond token transfer alone, but the current architecture is not easy to use for the case where there are on the order of 1000s of host accounts controlled by many controllers. These requirements aim to alleviate current pain points and ehance the usability of the feature. | |
| ## Problem | |
| The current pain points for existing ICA users are listed: | |
| - *Account Flexibility* - Currently host accounts can only be of type `BaseAccount` | |
| - *Ordered Channels* - Timeouts and subsequent channel closures are time consuming and difficult to manage | |
| - *Scalability* - When there are many interchain accounts, and many channels (in the order of 1000s), relayers struggle with the number of queries on startup and performance is compromised. Additionally, account registration being linked to the channel means that multiple packet round trips are required before your host account can execute messages. | |
| - *Workflows requiring tokens in ICA* - there are no atomic guarantees for a workflow containing multiple applications - i.e. a token transfer followed by an ICA message. The transfer could succeed and the ICA message fail resulting in an incomplete workflow. | |
| - *Lack of default callbacks* - users are still relying on custom auth modules for packet callbacks, the callbacks middleware solves this problem but is an add on to the application rather than a default | |
| - *Whitelisiting messages* - this devex is more complicated than having a blacklist | |
| ## Objectives | |
| - Enable different account types, to be coontrolled remotely | |
| - To facilitate performant cross-chain account management for accounts created on a per user basis | |
| - To streamline workflows using token transfer and interchain accounts in combination | |
| ## Scope | |
| | Features | Release | | |
| | --------- | ------- | | |
| | Multi-plexed Interchain Accounts | ibc-go v10.0.0 | | |
| # User requirements | |
| ## Use cases | |
| Existing use cases have been detailed in ics27 and ics27 v2 requirements, some other notable use cases used in production are cross chain liquid staking, yield through leveraged lending and cross chain NFT minting. | |
| ### Liquid Staking | |
| Chains such as Stride, Quicksilver and pStake control Interchain Accounts on a host chain to stake tokens on behalf of their users and mint representative liquid staking tokens so that users can transact with liquid tokens, rather than a locked staked asset but still earn staking rewards through autocompounding on the Interchain Account. More information on Stride's technical architecture can be found [here](https://github.com/Stride-Labs/stride/tree/main?tab=readme-ov-file#strides-technical-architecture). | |
| ### Leveraged Lending | |
| Nolus enables users to borrow assets and use the inflation from staking rewards to repay the interest on the principle. e.g. a user could deposit 10 OSMO as collatoral for a 25 OSMO position. When a user opens a position, an Interchain Account is opened on Osmosis and the loan amount is sent to the account with management of the account through the Nolus chain. | |
| ### Cross-chain NFT minting | |
| Nomos enable NFTs to be minted on Injective on host accounts controlled from the Xion chain, providing a single interface for users, enabling chain abstraction. | |
| # Functional requirements | |
| ## Assumptions and dependencies | |
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone. | |
| - Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required. | |
| - Assumes use of the `x/accounts` sdk module. | |
| ## Features | |
| ### 1 - Configuration | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ | | |
| ### 2 - Registration | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | ------------ | ------ | | |
| | 2.02 | A registered interchain account can be any account type supported by `x/accounts` | ------------ | ------ | | |
| ### 3 - Control | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 3.01 | The channel type through which a controller sends transactions to the host should be unordered | ------------ | ------ | | |
| | 3.02 | The message execution order should be determined at the packet level | ------------ | ------ | | |
| | 3.03 | Many controllers can send messages to many host accounts through the same channel | ------------ | ------ | | |
| | 3.04 | The controller of the interchain account should be able to receive information about the balance of the interchain account in the acknowledgment after a transaction was executed by the host | ------------ | ------ | | |
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per user basis | ------------ | ------ | | |
| | 3.06 | Callbacks on the packet lifecycle should be supported by default | ------------ | ------ | | |
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgement | ------------ | ------ | | |
| ### 4 - Host execution | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 4.01 | It should be possible to ensure a packet lifecycle from a different application completes before a message from a controller is executed | ------------ | ------ | | |
| | 4.02 | It should be possible for a controller to authorise a host account to execute specific actions on a host chain without needing a packet round trip each time (e.g. auto-compounding) | ------------ | ------ | | |
| # Non-functional requirements | |
| ## 5 - Performance | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 5.01 | The number of packet round trips to register an account, load the account with tokens and execute messages on the account should be minimised | ------------ | ------ | | |
| The Interchain Accounts feature has enabled control of an account on a host chain remotely from a controller chain. This has opened up many possibilities for more complex cross-chain workflows beyond token transfer alone, but the current architecture is not easy to use for the case where there are on the order of 1000s of host accounts controlled by many controllers. These requirements aim to alleviate current pain points and ehance the usability of the feature. | |
| ## Problem | |
| The current pain points for existing ICA users are listed: | |
| - *Account Flexibility* - Currently host accounts can only be of type `BaseAccount` | |
| - *Ordered Channels* - Timeouts and subsequent channel closures are time consuming and difficult to manage | |
| - *Scalability* - When there are many interchain accounts, and many channels (in the order of 1000s), relayers struggle with the number of queries on startup and performance is compromised. Additionally, account registration being linked to the channel means that multiple packet round trips are required before your host account can execute messages. | |
| - *Workflows requiring tokens in ICA* - there are no atomic guarantees for a workflow containing multiple applications - i.e. a token transfer followed by an ICA message. The transfer could succeed and the ICA message fail resulting in an incomplete workflow. | |
| - *Lack of default callbacks* - users are still relying on custom auth modules for packet callbacks, the callbacks middleware solves this problem but is an add on to the application rather than a default | |
| - *Whitelisiting messages* - this devex is more complicated than having a blacklist | |
| ## Objectives | |
| - Enable different account types, to be coontrolled remotely | |
| - To facilitate performant cross-chain account management for accounts created on a per user basis | |
| - To streamline workflows using token transfer and interchain accounts in combination | |
| ## Scope | |
| | Features | Release | | |
| | --------- | ------- | | |
| | Multi-plexed Interchain Accounts | ibc-go v10.0.0 | | |
| # User requirements | |
| ## Use cases | |
| Existing use cases have been detailed in ics27 and ics27 v2 requirements, some other notable use cases used in production are cross chain liquid staking, yield through leveraged lending and cross chain NFT minting. | |
| ### Liquid Staking | |
| Chains such as Stride, Quicksilver and pStake control Interchain Accounts on a host chain to stake tokens on behalf of their users and mint representative liquid staking tokens so that users can transact with liquid tokens, rather than a locked staked asset but still earn staking rewards through autocompounding on the Interchain Account. More information on Stride's technical architecture can be found [here](https://github.com/Stride-Labs/stride/tree/main?tab=readme-ov-file#strides-technical-architecture). | |
| ### Leveraged Lending | |
| Nolus enables users to borrow assets and use the inflation from staking rewards to repay the interest on the principle. e.g. a user could deposit 10 OSMO as collatoral for a 25 OSMO position. When a user opens a position, an Interchain Account is opened on Osmosis and the loan amount is sent to the account with management of the account through the Nolus chain. | |
| ### Cross-chain NFT minting | |
| Nomos enable NFTs to be minted on Injective on host accounts controlled from the Xion chain, providing a single interface for users, enabling chain abstraction. | |
| # Functional requirements | |
| ## Assumptions and dependencies | |
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone. | |
| - Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required. | |
| - Assumes use of the `x/accounts` sdk module. | |
| ## Features | |
| ### 1 - Configuration | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ | | |
| ### 2 - Registration | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | ------------ | ------ | | |
| | 2.02 | A registered interchain account can be any account type supported by `x/accounts` | ------------ | ------ | | |
| ### 3 - Control | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 3.01 | The channel type through which a controller sends transactions to the host should be unordered | ------------ | ------ | | |
| | 3.02 | The message execution order should be determined at the packet level | ------------ | ------ | | |
| | 3.03 | Many controllers can send messages to many host accounts through the same channel | ------------ | ------ | | |
| | 3.04 | The controller of the interchain account should be able to receive information about the balance of the interchain account in the acknowledgment after a transaction was executed by the host | ------------ | ------ | | |
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per user basis | ------------ | ------ | | |
| | 3.06 | Callbacks on the packet lifecycle should be supported by default | ------------ | ------ | | |
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgement | ------------ | ------ | | |
| ### 4 - Host execution | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 4.01 | It should be possible to ensure a packet lifecycle from a different application completes before a message from a controller is executed | ------------ | ------ | | |
| | 4.02 | It should be possible for a controller to authorise a host account to execute specific actions on a host chain without needing a packet round trip each time (e.g. auto-compounding) | ------------ | ------ | | |
| # Non-functional requirements | |
| ## 5 - Performance | |
| | ID | Description | Verification | Status | | |
| | -- | ----------- | ------------ | ------ | | |
| | 5.01 | The number of packet round trips to register an account, load the account with tokens and execute messages on the account should be minimised | ------------ | ------ | |
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 24
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/requirements/ics27-multiplexed-requirements.md (1 hunks)
Additional Context Used
LanguageTool (7)
docs/requirements/ics27-multiplexed-requirements.md (7)
Near line 11: Possible missing comma found.
Context: ... are listed: - Account Flexibility - Currently host accounts can only be of type `Base...
Near line 13: This word is normally spelled with a hyphen.
Context: ...uts and subsequent channel closures are time consuming and difficult to manage - *Scalability...
Near line 19: This noun is usually spelled with a hyphen.
Context: ...iddleware solves this problem but is an add on to the application rather than a defaul...
Near line 26: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...nt management for accounts created on a per user basis - To streamline workflows using t...
Near line 57: Possible missing comma found.
Context: ...desirable, it is out of scope for these requirements as a solution is applicable to applicat...
Near line 84: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...implementing additional middleware on a per user basis | ------------ | ------ | | 3.06 ...
Near line 86: Do not mix variants of the same word (‘acknowledgement’ and ‘acknowledgment’) within a single text.
Context: ...in account and return the result in the acknowledgement | ------------ | ------ | ### 4 - Ho...
Path-based Instructions (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
|
|
||
| - *Account Flexibility* - Currently host accounts can only be of type `BaseAccount` | ||
|
|
||
| - *Ordered Channels* - Timeouts and subsequent channel closures are time consuming and difficult to manage |
There was a problem hiding this comment.
Add a hyphen to "time-consuming".
- Timeouts and subsequent channel closures are time consuming and difficult to manage
+ Timeouts and subsequent channel closures are time-consuming and difficult to manageCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| - *Ordered Channels* - Timeouts and subsequent channel closures are time consuming and difficult to manage | |
| - *Ordered Channels* - Timeouts and subsequent channel closures are time-consuming and difficult to manage |
|
|
||
| - *Workflows requiring tokens in ICA* - there are no atomic guarantees for a workflow containing multiple applications - i.e. a token transfer followed by an ICA message. The transfer could succeed and the ICA message fail resulting in an incomplete workflow. | ||
|
|
||
| - *Lack of default callbacks* - users are still relying on custom auth modules for packet callbacks, the callbacks middleware solves this problem but is an add on to the application rather than a default |
There was a problem hiding this comment.
Add a hyphen to "add-on".
- the callbacks middleware solves this problem but is an add on to the application rather than a default
+ the callbacks middleware solves this problem but is an add-on to the application rather than a defaultCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| - *Lack of default callbacks* - users are still relying on custom auth modules for packet callbacks, the callbacks middleware solves this problem but is an add on to the application rather than a default | |
| - *Lack of default callbacks* - users are still relying on custom auth modules for packet callbacks, the callbacks middleware solves this problem but is an add-on to the application rather than a default |
|
|
||
| ## Assumptions and dependencies | ||
|
|
||
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone. |
There was a problem hiding this comment.
Consider adding a comma after "requirements".
- it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone.
+ it is out of scope for these requirements, as a solution is applicable to applications beyond Interchain Accounts alone.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone. | |
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements, as a solution is applicable to applications beyond Interchain Accounts alone. |
Remove trailing space.
- Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone.
+ Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements as a solution is applicable to applications beyond Interchain Accounts alone. |
| | 3.04 | The controller of the interchain account should be able to receive information about the balance of the interchain account in the acknowledgment after a transaction was executed by the host | ------------ | ------ | | ||
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per user basis | ------------ | ------ | | ||
| | 3.06 | Callbacks on the packet lifecycle should be supported by default | ------------ | ------ | | ||
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgement | ------------ | ------ | |
There was a problem hiding this comment.
Ensure consistency in the spelling of "acknowledgment".
- in the acknowledgement
+ in the acknowledgmentCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgement | ------------ | ------ | | |
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgment | ------------ | ------ | |
There was a problem hiding this comment.
Actionable comments posted: 3
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/requirements/ics27-multiplexed-requirements.md (1 hunks)
Additional Context Used
LanguageTool (3)
docs/requirements/ics27-multiplexed-requirements.md (3)
Near line 17: Possible missing comma found.
Context: ...nsfer could succeed and the ICA message fail resulting in an incomplete workflow. ...
Near line 26: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...nt management for accounts created on a per user basis - To streamline workflows using t...
Near line 84: In this context, “per-user” forms an adjective and is spelled with a hyphen.
Context: ...implementing additional middleware on a per user basis | ------------ | ------ | | 3.06 ...
GitHub Check Runs (1)
lint failure (2)
docs/requirements/ics27-multiplexed-requirements.md: [failure] 26-26: Lists should be surrounded by blank lines
docs/requirements/ics27-multiplexed-requirements.md:26 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- To facilitate performant cro..."] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md032.md
Path-based Instructions (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 5
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/requirements/ics27-multiplexed-requirements.md (1 hunks)
Additional Context Used
LanguageTool (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Near line 11: Possible missing comma found.
Context: ... are listed: - Account Flexibility - Currently host accounts can only be of type `Base...
GitHub Check Runs (1)
lint failure (3)
docs/requirements/ics27-multiplexed-requirements.md: [failure] 26-26: Lists should be surrounded by blank lines
docs/requirements/ics27-multiplexed-requirements.md:26 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- To facilitate performant cro..."] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md032.md
docs/requirements/ics27-multiplexed-requirements.md: [failure] 73-73: Table column count
docs/requirements/ics27-multiplexed-requirements.md:73:145 MD056/table-column-count Table column count [Expected: 4; Actual: 6; Too many cells, extra data will be missing] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md056.md
Path-based Instructions (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 13
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/requirements/ics27-multiplexed-requirements.md (1 hunks)
Additional Context Used
LanguageTool (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Near line 11: Possible missing comma found.
Context: ... are listed: - Account Flexibility - Currently host accounts can only be of type `Base...
GitHub Check Runs (1)
lint failure (2)
docs/requirements/ics27-multiplexed-requirements.md: [failure] 26-26: Lists should be surrounded by blank lines
docs/requirements/ics27-multiplexed-requirements.md:26 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- To streamline workflows usin..."] https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md032.md
Path-based Instructions (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
|
|
||
| The current pain points for existing ICA users are listed: | ||
|
|
||
| - *Account Flexibility* - Currently host accounts can only be of type `BaseAccount` |
There was a problem hiding this comment.
Consider adding a comma after "listed" for better readability.
- The current pain points for existing ICA users are listed:
+ The current pain points for existing ICA users are listed:Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| - *Account Flexibility* - Currently host accounts can only be of type `BaseAccount` |
| Enable different account types, to be controlled remotely | ||
| - To streamline workflows using token transfer and interchain accounts in combination |
There was a problem hiding this comment.
Lists should be surrounded by blank lines for proper markdown formatting.
- Enable different account types, to be controlled remotely
- To streamline workflows using token transfer and interchain accounts in combination
+
+ Enable different account types, to be controlled remotely
+ - To streamline workflows using token transfer and interchain accounts in combination
+ Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| Enable different account types, to be controlled remotely | |
| - To streamline workflows using token transfer and interchain accounts in combination | |
| Enable different account types, to be controlled remotely | |
| - To streamline workflows using token transfer and interchain accounts in combination | |
| ## Assumptions and dependencies | ||
|
|
||
| - Although having atomic transfer plus action workflows with Interchain Accounts is desirable, it is out of scope for these requirements, as a solution is applicable to applications beyond Interchain Accounts alone. | ||
| Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required. |
There was a problem hiding this comment.
Remove trailing space at the end of the line.
- Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required.
+ Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required. | |
| Migration of an existing Interchain Account using a prior version of Interchain Accounts that does not satisfy these requirements is not required. |
There was a problem hiding this comment.
Actionable comments posted: 12
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/requirements/ics27-multiplexed-requirements.md (1 hunks)
Additional Context Used
Path-based Instructions (1)
docs/requirements/ics27-multiplexed-requirements.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
|
|
||
| # Business requirements | ||
|
|
||
| The Interchain Accounts feature has enabled control of an account on a host chain remotely from a controller chain. This has opened up many possibilities for more complex cross-chain workflows beyond token transfer alone, but the current architecture is not easy to use for the case where there are on the order of 1000s of host accounts controlled by many controllers. These requirements aim to alleviate current pain points and enhance the usability of the feature. |
There was a problem hiding this comment.
Remove trailing space at the end of the line.
- These requirements aim to alleviate current pain points and enhance the usability of the feature.
+ These requirements aim to alleviate current pain points and enhance the usability of the feature.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| The Interchain Accounts feature has enabled control of an account on a host chain remotely from a controller chain. This has opened up many possibilities for more complex cross-chain workflows beyond token transfer alone, but the current architecture is not easy to use for the case where there are on the order of 1000s of host accounts controlled by many controllers. These requirements aim to alleviate current pain points and enhance the usability of the feature. | |
| The Interchain Accounts feature has enabled control of an account on a host chain remotely from a controller chain. This has opened up many possibilities for more complex cross-chain workflows beyond token transfer alone, but the current architecture is not easy to use for the case where there are on the order of 1000s of host accounts controlled by many controllers. These requirements aim to alleviate current pain points and enhance the usability of the feature. |
|
|
||
| - *Scalability* - When there are many interchain accounts, and many channels (in the order of 1000s), relayers struggle with the number of queries on startup and performance is compromised. Additionally, account registration being linked to the channel means that multiple packet round trips are required before your host account can execute messages. | ||
|
|
||
| - *Workflows requiring tokens in ICA* - there are no atomic guarantees for a workflow containing multiple applications - i.e. a token transfer followed by an ICA message. The transfer could succeed and the ICA message fail, resulting in an incomplete workflow. |
There was a problem hiding this comment.
Remove trailing space at the end of the line.
- The transfer could succeed and the ICA message fail, resulting in an incomplete workflow.
+ The transfer could succeed and the ICA message fail, resulting in an incomplete workflow.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| - *Workflows requiring tokens in ICA* - there are no atomic guarantees for a workflow containing multiple applications - i.e. a token transfer followed by an ICA message. The transfer could succeed and the ICA message fail, resulting in an incomplete workflow. | |
| - *Workflows requiring tokens in ICA* - there are no atomic guarantees for a workflow containing multiple applications - i.e. a token transfer followed by an ICA message. The transfer could succeed and the ICA message fail, resulting in an incomplete workflow. |
|
|
||
| - *Lack of default callbacks* - users are still relying on custom auth modules for packet callbacks, the callbacks middleware solves this problem but is an add-on to the application rather than a default | ||
|
|
||
| *Whitelisting messages* - this devex is more complicated than having a blacklist |
There was a problem hiding this comment.
Consider changing "Whitelisiting" to "Whitelisting".
- *Whitelisiting messages* - this devex is more complicated than having a blacklist
+ *Whitelisting messages* - this devex is more complicated than having a blacklistCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| *Whitelisting messages* - this devex is more complicated than having a blacklist | |
| *Whitelisting messages* - this devex is more complicated than having a blacklist |
| - Enable different account types, to be controlled remotely | ||
| - To streamline workflows using token transfer and interchain accounts in combination |
There was a problem hiding this comment.
Lists should be surrounded by blank lines for proper markdown formatting.
+
- Enable different account types, to be controlled remotely
- To streamline workflows using token transfer and interchain accounts in combination
+ Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| - Enable different account types, to be controlled remotely | |
| - To streamline workflows using token transfer and interchain accounts in combination | |
| - Enable different account types, to be controlled remotely | |
| - To streamline workflows using token transfer and interchain accounts in combination | |
|
|
||
| ### Leveraged Lending | ||
|
|
||
| Nolus enables users to borrow assets and use the inflation from staking rewards to repay the interest on the principle. e.g. a user could deposit 10 OSMO as collatoral for a 25 OSMO position. When a user opens a position, an Interchain Account is opened on Osmosis and the loan amount is sent to the account with management of the account through the Nolus chain. |
There was a problem hiding this comment.
Correct the spelling of "collatoral" to "collateral".
- e.g. a user could deposit 10 OSMO as collatoral for a 25 OSMO position.
+ e.g. a user could deposit 10 OSMO as collateral for a 25 OSMO position.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| Nolus enables users to borrow assets and use the inflation from staking rewards to repay the interest on the principle. e.g. a user could deposit 10 OSMO as collatoral for a 25 OSMO position. When a user opens a position, an Interchain Account is opened on Osmosis and the loan amount is sent to the account with management of the account through the Nolus chain. | |
| Nolus enables users to borrow assets and use the inflation from staking rewards to repay the interest on the principle. e.g. a user could deposit 10 OSMO as collateral for a 25 OSMO position. When a user opens a position, an Interchain Account is opened on Osmosis and the loan amount is sent to the account with management of the account through the Nolus chain. |
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | | ||
| | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ | |
There was a problem hiding this comment.
Remove trailing space at the end of the line.
- | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ |
+ | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ |Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ | | |
| | 1.01 | The host chain should accept all message types by default and maintain a blacklist of message types it does not permit | ------------ | ------ | |
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | | ||
| | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | -- | ----------- | |
There was a problem hiding this comment.
Correct the table formatting by ensuring the correct number of cells per row.
- | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | -- | ----------- |
+ | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | ------------ | ------ |Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | -- | ----------- | | |
| | 2.01 | The controller of the interchain account must have authority over the account on the host chain to execute messages | ------------ | ------ | |
| | 3.02 | The message execution order should be determined at the packet level | ------------ | ------ | | ||
| | 3.03 | Many controllers can send messages to many host accounts through the same channel | ------------ | ------ | | ||
| | 3.04 | The controller of the interchain account should be able to receive information about the balance of the interchain account in the acknowledgment after a transaction was executed by the host | ------------ | ------ | | ||
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per-user basis | ------------ | ------ | |
There was a problem hiding this comment.
Add a hyphen to "per-user" to form the correct adjective.
- The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per-user basis | ------------ | ------ |
+ The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per-user basis | ------------ | ------ |Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per-user basis | ------------ | ------ | | |
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per-user basis | ------------ | ------ | |
| | 3.04 | The controller of the interchain account should be able to receive information about the balance of the interchain account in the acknowledgment after a transaction was executed by the host | ------------ | ------ | | ||
| | 3.05 | The user of the controller should be able to receive all the information contained in the acknowledgment without implementing additional middleware on a per-user basis | ------------ | ------ | | ||
| | 3.06 | Callbacks on the packet lifecycle should be supported by default | ------------ | ------ | | ||
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgment | ------------ | ------ | |
There was a problem hiding this comment.
Remove trailing space at the end of the line.
- | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgment | ------------ | ------ |
+ | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgment | ------------ | ------ |Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgment | ------------ | ------ | | |
| | 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgment | ------------ | ------ | |
| ## 5 - Performance | ||
|
|
||
| | ID | Description | Verification | Status | | ||
| | -- | ----------- | ------------ | ------ | |
There was a problem hiding this comment.
Remove trailing space at the end of the line.
- | 5.01 | The number of packet round trips to register an account, load the account with tokens and execute messages on the account should be minimised | ------------ | ------ |
+ | 5.01 | The number of packet round trips to register an account, load the account with tokens and execute messages on the account should be minimised | ------------ | ------ |Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| | -- | ----------- | ------------ | ------ | | |
| | -- | ----------- | ------------ | ------ | |
Description
Requirements for to enable multiplexed interchain accounts - many controllers controlling many host accounts through a single channel
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.
docs/).godoccomments.Files changedin the GitHub PR explorer.SonarCloud Reportin the comment section below once CI passes.Summary by CodeRabbit