Ideal Restructure Of Adapter Contracts

[NotJeremyLiu]

Background

• Skip API contracts consist of 1) a main entry point contract where the exact bytecode is intended to be deployed across all networks, 2) swap adapter contracts that differ between dexes, and 3) IBC transfer adapter contracts that differ between IBC infra (IBC hooks, Neutron Transfer module, etc.)
• The current folder / file structure of the Skip API repo is one where the adapter contracts are separated by Network, where each Network has a parent folder, and within that folder exists an IBC folder containing the IBC transfer adapter contract and a Swap folder containing a single DEX adapter contract.
• It already became apparent at the time of developing just the Osmosis and Neutron adapter contracts that this is not ideal, with many tests shared between the adapter contracts and only specific types being the differentiator on the expected output.

Example Near-Term Future Support

In the near-term, Skip API contracts will be deployed across more networks and dexes, with a realistic example being:

1. Osmosis:
   • Swap Adapter: Poolmanager Module
   • IBC Adapter: IBC-Hooks
2. Neutron
   • Swap Adapter: Astroport CW Contract
   • IBC Adapter: Neutron Transfer Module
3. Terra2
   • Swap Adapters: Astroport CW Contract, WhiteWhale CW Contract
   • IBC Adapter: IBC-Hooks
4. Juno
   • Swap Adapters: WyndDex CW Contract, Hopers CW Contract
   • IBC Adapter: IBC-Hooks
5. Injective
   • Swap Adapters: Astroport CW Contract, Injective Dex module
   • IBC Adapter: IBC-Hooks

This Issue

Serves as a design / tracking issue to work towards a refactor of the repo (incl. tests) that:

1. Makes supporting multiple swap adapter contracts per network as easy as possible
2. Makes developing new swap adapter contracts as easy as possible
3. Makes developing new ibc transfer adapter contracts as easy as possible

easy as possible = least amount of redundant dev/testing work to launch/maintain adapter contracts.

Current Status

• 8/7/2023: Researching Mars protocol's Swapper, but no definitive direction yet: https://github.com/mars-protocol/v2-fields-of-mars/tree/master/contracts/swapper

[dzmitry-lahoda]

Also alternative we are developing (deployed to Centauri and Osmosis now, soon Neutron) to use simple set of instructions , with implementations for different actions, either well know like Exchange or custom raw Calls.
It abstracts away PFM vs true multihop, osmosis hooks vs IBC official release of analog in Q4, batching, or Neutron Transfer Module, and in future multiasset. So frontend does not worries about changes under a lot. Also it gives ultimate routing information on chain in universal way (each chain knows routing on other chain). And will work over Parity XCM (we CW/IBC on parachain) and soon Ethereum EVM (we have draft conract).

general semantic:
https://github.com/ComposableFi/composable/blob/main/code/xcvm/semantic.md

example of adapter:
https://github.com/ComposableFi/composable/blob/01d8c11da7bc16952888ff644a87df666a4eae40/code/xcvm/lib/core/src/service/dex/mod.rs#L20
for future will add Bond and Order, additional to exchange.

here how CW message to swap looks like
https://github.com/ComposableFi/composable/blob/main/code/xcvm/swap-pica-to-osmosis.json

here some example runs:
https://github.com/ComposableFi/composable/blob/main/code/xcvm/tutorial.md#recording

here why asset ids are numbers:
https://github.com/ComposableFi/composable/blob/main/code/xcvm/technical.md#asset-identifier

here is routing configs:
https://github.com/ComposableFi/composable/blob/main/code/xcvm/cvm.json

Now FE team of Composable integrates this, would be aw fesome if you find it useful too.

In general it is inspired by https://github.com/paritytech/xcm-format but very keen on giving users powers, specifically cross chain authz like abilies, layer security, etc. All working is liquidity exisitng on chain. Making all routes verifiable.

Now I do not do validation btw, but easy to add - and in general - do not route swap to bad pools cross chain :)

UPDATE:
we maintain std and no_std(near, solana, similar to ibc-rs compilation design) builds, and in future will run mev as part of devnet (which is nix). and devshell for all envs are also nix.

if any interest I can do demo and codewalkthorugh.

for assets encoding, actually we do global numbers, u128, where 32 bits are network ids prefixes. this gives fancy capabilities on top of hashes and denoms for true cross chain.

12321321321321cvm/200000000000042 - would be osmo on osmosi
12321321321321cvm/300000000000042 - would be osmo on neutron.

we have low code coverage btw so.

UPDATE: or any feedback why it is impossible/hard to use is super awesome