From 60f84658ef39726bf6d75263ae376c96d3679099 Mon Sep 17 00:00:00 2001 From: womensrights Date: Wed, 8 May 2024 19:45:36 +0200 Subject: [PATCH 01/10] Create ics27-multiplexed-requirements.md --- .../ics27-multiplexed-requirements.md | 100 ++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 docs/requirements/ics27-multiplexed-requirements.md diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md new file mode 100644 index 00000000000..59961a5134d --- /dev/null +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -0,0 +1,100 @@ + + +# 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 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 | ------------ | ------ | From b766721d71f4bc41e5c6a6ada9d2de1a448824c4 Mon Sep 17 00:00:00 2001 From: womensrights Date: Wed, 8 May 2024 19:49:07 +0200 Subject: [PATCH 02/10] Update ics27-multiplexed-requirements.md --- docs/requirements/ics27-multiplexed-requirements.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index 59961a5134d..eb3c09ab84a 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -51,6 +51,7 @@ Nolus enables users to borrow assets and use the inflation from staking rewards 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. From 7715ce35dbfe9a78e2b3c6ba3d93d7bdfda5cdbb Mon Sep 17 00:00:00 2001 From: Susannah Evans <65018876+womensrights@users.noreply.github.com> Date: Wed, 8 May 2024 21:44:54 +0200 Subject: [PATCH 03/10] Update docs/requirements/ics27-multiplexed-requirements.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- docs/requirements/ics27-multiplexed-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index eb3c09ab84a..c6a6bdf056e 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -2,7 +2,7 @@ # 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 ehance 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. ## Problem From f36ba37e239280e05cb22dfda834082d846a0aa8 Mon Sep 17 00:00:00 2001 From: Susannah Evans <65018876+womensrights@users.noreply.github.com> Date: Wed, 8 May 2024 21:45:26 +0200 Subject: [PATCH 04/10] Update docs/requirements/ics27-multiplexed-requirements.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- docs/requirements/ics27-multiplexed-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index c6a6bdf056e..01cd9441bfc 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -22,7 +22,7 @@ The current pain points for existing ICA users are listed: ## Objectives -- Enable different account types, to be coontrolled remotely +Enable different account types, to be controlled 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 From 6a0e49a9f59c586f48b2376dc41a6f76bf3018aa Mon Sep 17 00:00:00 2001 From: Susannah Evans <65018876+womensrights@users.noreply.github.com> Date: Wed, 8 May 2024 21:46:03 +0200 Subject: [PATCH 05/10] Update docs/requirements/ics27-multiplexed-requirements.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- docs/requirements/ics27-multiplexed-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index 01cd9441bfc..06310deb041 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -83,7 +83,7 @@ Nomos enable NFTs to be minted on Injective on host accounts controlled from the | 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 | ------------ | ------ | +| 3.07 | A user can perform module safe queries through a host chain account and return the result in the acknowledgment | ------------ | ------ | ### 4 - Host execution From ebf6dbc2eef1af9166790ddb5e8ff49aa702090c Mon Sep 17 00:00:00 2001 From: Susannah Evans <65018876+womensrights@users.noreply.github.com> Date: Wed, 8 May 2024 21:47:45 +0200 Subject: [PATCH 06/10] Apply suggestions from code review Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- docs/requirements/ics27-multiplexed-requirements.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index 06310deb041..47cded290a3 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -10,15 +10,15 @@ 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 +- *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 +- *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 +*Whitelisting messages* - this devex is more complicated than having a blacklist ## Objectives @@ -54,7 +54,7 @@ Nomos enable NFTs to be minted on Injective on host accounts controlled from the ## 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. +- 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. From 0933ce70ba0f4a2feb5c2ce2e7e6dec1f0a84e76 Mon Sep 17 00:00:00 2001 From: Carlos Rodriguez Date: Thu, 9 May 2024 09:13:37 +0200 Subject: [PATCH 07/10] Apply suggestions from code review Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- .../ics27-multiplexed-requirements.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index 47cded290a3..0e81e725e50 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -2,7 +2,7 @@ # 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. +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. ## Problem @@ -12,9 +12,9 @@ The current pain points for existing ICA users are listed: - *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. +- *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. +- *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 @@ -23,7 +23,7 @@ The current pain points for existing ICA users are listed: ## Objectives Enable different account types, to be controlled remotely -- To facilitate performant cross-chain account management for accounts created on a per user basis +- 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 @@ -36,7 +36,7 @@ Enable different account types, to be controlled remotely ## 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. +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 @@ -44,50 +44,50 @@ Chains such as Stride, Quicksilver and pStake control Interchain Accounts on a h ### 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. +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. +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. +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 | ------------ | ------ | +| 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 | +| 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.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 | +| 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.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 | ------------ | ------ | ### 4 - Host execution -| ID | Description | Verification | Status | +| 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) | ------------ | ------ | @@ -96,6 +96,6 @@ Nomos enable NFTs to be minted on Injective on host accounts controlled from the ## 5 - Performance -| ID | Description | Verification | Status | +| 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 | ------------ | ------ | From d4b9f0b73ef86ffeedbf613a29ee84d3124f7216 Mon Sep 17 00:00:00 2001 From: Susannah Evans <65018876+womensrights@users.noreply.github.com> Date: Tue, 14 May 2024 12:02:39 +0200 Subject: [PATCH 08/10] Apply suggestions from code review Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- docs/requirements/ics27-multiplexed-requirements.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index 0e81e725e50..4daca28ca6e 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -14,7 +14,7 @@ The current pain points for existing ICA users are listed: - *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. +- *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 @@ -22,8 +22,7 @@ The current pain points for existing ICA users are listed: ## Objectives -Enable different account types, to be controlled remotely -- To facilitate performant cross-chain account management for accounts created on a per-user basis +Enable different account types, to be controlled remotely - To streamline workflows using token transfer and interchain accounts in combination ## Scope @@ -70,7 +69,7 @@ Migration of an existing Interchain Account using a prior version of Interchain | 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.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 From 48f69848bb84d9bc396c750eb656f961c7d773ad Mon Sep 17 00:00:00 2001 From: womensrights Date: Tue, 14 May 2024 12:20:27 +0200 Subject: [PATCH 09/10] Update ics27-multiplexed-requirements.md --- docs/requirements/ics27-multiplexed-requirements.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index 4daca28ca6e..5f4a99c4fe4 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -22,8 +22,9 @@ The current pain points for existing ICA users are listed: ## Objectives -Enable different account types, to be controlled remotely +- Enable different account types, to be controlled remotely - To streamline workflows using token transfer and interchain accounts in combination +- To enable scalable and efficient account creation ## Scope From c69b856cdffe5e4910130e157c50a325d7adcd05 Mon Sep 17 00:00:00 2001 From: Susannah Evans <65018876+womensrights@users.noreply.github.com> Date: Fri, 16 Aug 2024 16:56:05 +0200 Subject: [PATCH 10/10] Update docs/requirements/ics27-multiplexed-requirements.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- docs/requirements/ics27-multiplexed-requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/requirements/ics27-multiplexed-requirements.md b/docs/requirements/ics27-multiplexed-requirements.md index 5f4a99c4fe4..4416423ccfa 100644 --- a/docs/requirements/ics27-multiplexed-requirements.md +++ b/docs/requirements/ics27-multiplexed-requirements.md @@ -44,7 +44,7 @@ Chains such as Stride, Quicksilver and pStake control Interchain Accounts on a h ### 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. +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. ### Cross-chain NFT minting