Adding poolmanager messages into allowed ICA messages list

The poolmanager module acts as a swap entry point for any pool model on the Osmosis chain. It is responsible for routing swaps across various pools and also performs pool-id management for any on-chain pool. The module accommodates a diverse range of pool implementations, from standard constant product pools (like x/gamm) to the newer Supercharged (x/concentrated-liquidity) pools. A notable feature is that interactions with the Supercharged pools are exclusively facilitated via the poolmanager module.

Protocols native to the Osmosis network have unrestricted interactions with the poolmanager module. However, for protocols from other IBC networks aiming to utilize the Osmosis pools via Interchain Accounts, there’s a need to include specific messages on the icahost.

An example of such a protocol is Nolus which is an appchain in the Cosmos ecosystem that communicates with other networks, such as Osmosis, via IBC and Interchain Accounts.


Currently, Nolus relies on the old standard constant product (x/gamm) pools in the background to facilitate the opening/repayment of lease (borrow) positions. In order to boost capital efficiency and improve the underlying trading experience, a migration to the new Supercharged pools is planned as liquidity in those pools gets deeper, respectively the slippage gets lower compared to the old pools. To make this adjustment, x/gamm messages need to be changed to x/poolmanager messages on Nolus. Since Osmosis is a host network, these x/poolmanager messages need to be whitelisted first via governance in order to be usable. This is currently not the case, so actions such as opening/repayment on a Nolus local development network are not working with x/poolmanager, but are still functioning with x/gamm.


This proposal would grant permissions to ICA accounts to execute the following poolmanager messages:

  • /osmosis.poolmanager.v1beta1.MsgSwapExactAmountIn

  • /osmosis.poolmanager.v1beta1.MsgSwapExactAmountInResponse

  • /osmosis.poolmanager.v1beta1.SwapAmountInRoute

With this adjustment Nolus would be able to tap into the Supercharged pools for its lease positions, thereby boosting their adoption and the overall volume.


No inherent risk for the Osmosis network. Interchain Accounts act as any normal account on the Osmosis network. The difference is that instead of requiring a private key to sign a transaction as it is with any EOA (externally owned address), Interchain Accounts are instead controlled programmatically by counterparty chains via IBC packets.

Osmosis Testnet Results

The three proposed ICA messages have already been successfully included in the icahost allow list on the Osmosis testnet (osmo-test-5) via prop 104 (Interchain Explorer by Cosmostation). This adjustment managed to solve the issue of users not being able to open/repay lease (borrow) positions.

About Nolus

Nolus is a semi-permissioned blockchain bridging lenders and borrowers in a DeFi money market. With its DeFi Lease, borrowers can secure up to 150% financing on their initial investments, and access to the underlying leveraged assets through whitelisted strategies.

Inspired by traditional leasing, where one pays a fraction upfront and gains ownership after repayment, Nolus’ approach cuts down the DeFi sector’s high over-collateralization standards. This boosts capital efficiency and offers borrowers better loan terms.

Nolus emphasizes interoperability, connecting to various liquidity sources across chains without fragmenting assets. The system can swiftly swap assets on any integrated DEX, streamlining lending by negating the need for multiple pools and ensuring liquidity providers handle only stable assets.

Ultimately, Nolus aims to simplify and enhance cross-chain DeFi experiences for everyone.

Read more about Nolus here:


I am seriously starting to wonder whether it would not be more efficient to do a proper analysis of possible useful ICA messages and add them in one proposal.
Instead of having a proposal every 1-2 week to add messages.

I think that having granular proposals is not such a bad idea as it doesn’t overcomplicate things compared to having one big proposal consisting of multiple allowed ICA messages each of which has different use cases. Also, this wouldn’t solve the problem for future integrations that come with new messages. This is a similar case as x/poolmanager is one of the newer included modules.

1 Like

Thanks for your response!

1 Like