ibc
ibc copied to clipboard
cosmos
ICS 101: interchain Liquidity
ICS-101 Interchain Swaps enables chains their own token pricing mechanism and exchange protocol via IBC transactions. Each chain can thus play a role in a fully decentralised exchange network.
Thank you for submitting this new spec, @liangping. I will try to give it a first review this quarter, but realistically you should expect that it gets merged somewhere in Q3.
too low level about implementation about pools to tbh
any tips for improvement?
you specifying that there is pool.with xyk. why not making swap to be buy or sell messages. we do not care what inside. as long limits satisfied, protocol is correct. given any packet can be async one, no ack on same block is fact. and you have timeout already too for orders.
you specifying that there is pool.with xyk. why not making swap to be buy or sell messages. we do not care what inside. as long limits satisfied, protocol is correct. given any packet can be async one, no ack on same block is fact. and you have timeout already too for orders.
I'm not entirely sure I understand, but we have ICS 100 which enables the sending of buy/sell messages to the counterparty chain.
This specification is designed to facilitate quick asset swaps between two chains without requiring voucher assets. Currently, we do not have plans to implement complex pools like those found in DEFI Hubs such as Osmosis or Uniswap.
But we are happy if we can work together to improve this spec.
you specifying that there is pool.with xyk. why not making swap to be buy or sell messages. we do not care what inside. as long limits satisfied, protocol is correct. given any packet can be async one, no ack on same block is fact. and you have timeout already too for orders.
I'm not entirely sure I understand, but we have ICS 100 which enables the sending of buy/sell messages to the counterparty chain.
This specification is designed to facilitate quick asset swaps between two chains without requiring voucher assets. Currently, we do not have plans to implement complex pools like those found in DEFI Hubs such as Osmosis or Uniswap.
But we are happy if we can work together to improve this spec.
i do not refer to ics 100, nor vouchers, nor telling of any protocol requiring 2 ibc packets.
why you are implemwnting pools inside ibc protocol?
you specifying that there is pool.with xyk. why not making swap to be buy or sell messages. we do not care what inside. as long limits satisfied, protocol is correct. given any packet can be async one, no ack on same block is fact. and you have timeout already too for orders.
I'm not entirely sure I understand, but we have ICS 100 which enables the sending of buy/sell messages to the counterparty chain. This specification is designed to facilitate quick asset swaps between two chains without requiring voucher assets. Currently, we do not have plans to implement complex pools like those found in DEFI Hubs such as Osmosis or Uniswap. But we are happy if we can work together to improve this spec.
i do not refer to ics 100, nor vouchers, nor telling of any protocol requiring 2 ibc packets.
why you are implemwnting pools inside ibc protocol?
you specifying that there is pool.with xyk. why not making swap to be buy or sell messages. we do not care what inside. as long limits satisfied, protocol is correct. given any packet can be async one, no ack on same block is fact. and you have timeout already too for orders.
The use of "pool.with xyk" in the specification is to indicate the involvement of the XYK (Automated Market Maker) pool in the swapping process. The specification may use "pool.with xyk" to abstract the underlying implementation details of the buy and sell operations.
By using "pool.with xyk" instead of explicit "buy" or "sell" messages, the specification remains agnostic about the specific actions being taken. This allows for flexibility in the implementation and supports different types of swapping mechanisms.
The focus of the specification is on ensuring that the necessary limits and protocols are satisfied for the swapping process. As long as the requirements are met and the protocol is correctly followed, the specific actions being performed (buying or selling) can be abstracted within the "pool.with xyk" implementation.
Regarding the suggestion to remove non-essential text from the specification about "xyk," it can be considered if it does not impact the clarity and completeness of the specification. However, it is important to ensure that the essential information about the involvement of the XYK pool and its purpose is adequately conveyed in the specification.
In summary, the use of "pool.with xyk" in the specification allows for flexibility in the implementation of the swapping process while ensuring that the necessary limits and protocols are satisfied. The decision to abstract the actions as "pool.with xyk" instead of explicit "buy" or "sell" messages enables different swapping mechanisms and simplifies the specification by focusing on the essential requirements.
Note: ics-100 is just order book, ics-101 is just AMM. I'm not sure how to answer about your question. "There are order book, why do we have to use AMM" ????
too low level about implementation about pools to tbh
It's just initial steps to reflects weighted pools, there are continuously improvement to support various swap algorithm.
https://github.com/osmosis-labs/osmosis-rust/blob/f686934e74a7abc5695775e8995e6d4412086f9b/packages/osmosis-std/src/types/osmosis/gamm/v1beta1.rs#L410
https://github.com/osmosis-labs/osmosis-rust/blob/f686934e74a7abc5695775e8995e6d4412086f9b/packages/osmosis-std/src/types/osmosis/gamm/v1beta1.rs#L448
see buy and sell on stable swap and constant swap
same here https://github.com/apollodao/cw-dex/
we were thinking about xc exchanges a lot - seems like pool/amm specific for swap is not so useful
other ecosystem also does not tells if that pool or not https://github.com/paritytech/xcm-format/blob/master/README.md#exchangeasset
if xyk/amm or anything else does swap is not essential
if you want to specify atomicity, you can still have buy/sell but name protoocl atomic swap. but the problem, you cannot be atomic as target module may be async, and do not confirm nor timeout packet, so one may not have that too. really it is not atomic but single packet buy or sell
https://github.com/osmosis-labs/osmosis-rust/blob/f686934e74a7abc5695775e8995e6d4412086f9b/packages/osmosis-std/src/types/osmosis/gamm/v1beta1.rs#L410
https://github.com/osmosis-labs/osmosis-rust/blob/f686934e74a7abc5695775e8995e6d4412086f9b/packages/osmosis-std/src/types/osmosis/gamm/v1beta1.rs#L448
see buy and sell on stable swap and constant swap
same here https://github.com/apollodao/cw-dex/
we were thinking about xc exchanges a lot - seems like pool/amm specific for swap is not so useful
other ecosystem also does not tells if that pool or not https://github.com/paritytech/xcm-format/blob/master/README.md#exchangeasset
if xyk/amm or anything else does swap is not essential
if you want to specify atomicity, you can still have buy/sell but name protoocl atomic swap. but the problem, you cannot be atomic as target module may be async, and do not confirm nor timeout packet, so one may not have that too. really it is not atomic but single packet buy or sell
Thank you for sharing the links and providing feedback on the existing implementations of AMMs and cross-chain exchanges. The references you shared from the Osmosis Rust repository demonstrate specific implementations of AMMs using buy and sell operations for stable swap and constant swap mechanisms. These implementations are valuable examples that showcase the functionality and behavior of AMMs in those specific contexts.
However, the goal of creating a generalized crosschain AMM package as a standard for ICS-101 (IBC-Go) is to provide a broader solution that can be utilized in various AMM implementations across different ecosystems. By developing a standardized approach, you aim to enhance interoperability and facilitate seamless asset exchange across different blockchain networks.
While specific AMM implementations may focus on the details of individual pools or AMM types, the emphasis of your work is on providing a generalized framework that can be adopted by different projects and ecosystems. This framework will allow for cross-chain asset swaps without being tied to a particular AMM pool or implementation. It provides a common interface and standard protocols for interacting with AMMs, enabling easy integration and compatibility across diverse blockchain networks.
The mentioned XCM Format from the Parity Technologies repository is another valuable resource in the realm of cross-chain communication and asset exchange. It further reinforces the importance of establishing interoperable standards to enable efficient cross-chain operations.
By creating a generalized crosschain AMM package as a standard for ICS-101 (IBC-Go), you contribute to the broader blockchain ecosystem by providing a consistent and interoperable solution for asset exchange. Your work aims to streamline the development and adoption of AMM functionality across different projects and networks, facilitating increased liquidity and cross-chain functionality.
In summary, while existing AMM implementations focus on specific pools and mechanisms, your work on a generalized crosschain AMM package as a standard for ICS-101 (IBC-Go) serves a broader purpose by establishing interoperable protocols and interfaces. This standardized approach enhances cross-chain asset exchange and contributes to the overall advancement of the blockchain ecosystem
yes, thank you. just to be sure this ics supports(does not prevents) any kind of swaps and hopefully fully compatible with ics20 assets(unlike ics100).