Skip API contract upload

Proposal Discussion DApps / Tooling
1

Original Thread: Commonwealth

TLDR

This is a proposal to give the address osmo1raa4kyx5ypz75qqk3566c6slx2mw3qzsu6rymw permission to upload CosmWasm contracts to Osmosis without seeking governance approval for subsequent uploads.

Deploying this contract will allow Skip to leverage Osmosis swap hooks to build a service that simplifies cross-chain transfers, swaps, and fee management. Skip will provide this functionality via our free API, which enables applications anywhere in Cosmos to seamlessly draw on Osmosis liquidity.

Proposal

The Skip API is a unified RPC service that helps developers create seamless cross-chain product experiences using IBC. Our goal is to enable frontend developers to be as productive as possible by offering the following IBC functionality out of the box:

  • One-click, any-to-any, cross-chain transfers and swaps
  • Multi-hop, cross-chain transfers and “token unwinding”
  • Denom and IBC channel path recommendations for any asset and chain
  • Multi-denom fee estimation for composite transfer and swap routes
  • Multi-hop transaction lifecycle tracking
  • Protection from common cross-chain UX failures (e.g. bridging to a chain where the end user doesn’t have gas)

To provide these capabilities the Skip API consists of two components, one off-chain and one on-chain, the later of which requires a contract deployment on Osmosis. More specifically:

  1. The off-chain system indexes a variety of chain data, including deployed IBC version, IBC packet forward middleware support, and accepted fee tokens for each chain. Skip’s off-chain service then combines this will realtime oracle feeds and fee market data to create a recommendation system that can build arbitrarily complex cross-chain routes + the corresponding Cosmos SDK messages to craft a complete transaction sequence.
  2. The resulting transaction sequence is then sent to Skips on-chain system , which uses the ICS-20 memo field to chain together a series of transactions that use Packet Forward Middleware and IBC hooks, wherever supported, to create a one-click experience to move from any-to-any chain and any-to-any token.

Skip’s contracts are currently undergoing an audit by Oak security. Any contract revisions will be uploaded and the audit report will be posted on this forum before contracts are used in production. The Skip contracts do not escrow funds, automatically refunding transactions in the event of workflow disruption.

Contract payload

  • Contract repo: GitHub - skip-mev/skip-api-contracts: Contracts for Skip API
  • Commit hash: 08e2ff80c86936f03bef001ca3aa5786cf4fd44b
  • Compiler Version: cosmwasm/workspace-optimizer-arm64:0.13.0
  • Contract checksums:
    • skip_swap_entry_point-aarch64.wasm = 599f3ebacaf7a56d6f703c4bd2a7ce2dc27e31f416fc35aa5b1f352c50985bb3
    • skip_swap_osmosis_ibc_transfer-aarch64.wasm = 16ab3cbf84617b78bb21b408292d51d5cd68afac680e0b0dd2781e77e29152c0
    • skip_swap_osmosis_poolmanager_swap-aarch64.wasm = b6752f85ec262b6f6b60e0b3c501a167a0b2337efc8aed06692ad02ffe64ebdc

About Skip

Skip helps developers provide extraordinary user experiences across all stages of the transaction lifecycle, from transaction construction, through cross-chain relaying + tracking, to block construction.

We build two main products:

  • Protocol-owned-builder (POB): Developed in partnership with Osmosis as an extension of our collaboration on ProtoRev. POB is a Cosmos SDK module for creating customized mempools that provide MEV recapture + protection, advanced fee markets, oracles, and more.
  • Skip API: A unified REST/RPC service and SDK that helps developers create more seamless cross-chain experiences for their end users with IBC. The Skip API is carefully designed to enable developers who are new to IBC to build applications that offer powerful cross chain functionality.

Contact

sam@skip.money

Twitter: https://twitter.com/skipprotocol

Discord: Skip

Website: https://skip.money/

Target on-chain date

06 July, 2023

2


Leonoor’s Cryptoman
osmo14amd

•

7/2/2023

Can you tell a bit more on;

  • the tests done,
  • audits (if any),
  • can the community test,
  • did some others already check the code?
3

Barry Plunkett | Skip
osmo1tsmt

•

7/4/2023

Hi @Leonoor’s Cryptoman ,

(Apologies in advance for the long answer!)

Thanks for the question! We take security and quality very seriously at Skip for all of the products we build. As most folks probably know, we have a history of building very sensitive software in Cosmos at all layers of the stack – from consensus algorithms on up through frontend dashboards – and distributing it widely without production incidents.

A couple of my favorites that we’ve built:

  • ProtoRev: Recaptures MEV for the Osmosis community by computing and executing a multi-hop backrun after every swap. It’s been running in production since March and has recently undergone a major refactor to support the upcoming CL launch
  • mev-tendermint + mev-cometbft: Allows validators and their delegates to recapture MEV by selling valuable top-of-block blockspace to traders who submit bundles of transactions to an auction, while preventing harmful MEV (e.g. frontrunning, sandwich attacks). It’s been installed on more than 500 validator nodes since launching in November 2022 and some chains (Migaloo, Juno, Neutron) have replaced tendermint/comet with mev-tendermint/mev-cometbft upstream.

Both of these examples are consensus-critical products, where non-determinism (or worse in the case of mev-tendermint) is a very real possibility, so we are obsessive about getting them right. Fortunately, our CosmWasm contracts almost certainly don’t pose the same level of risk to the chain (thanks to brilliant folks who’ve contributed to CosmWasm). Even still, we’ll bring the same extremely high standards to them. So you’ll see us being very exacting and very enthusiastic about deploying only high-quality code to Osmosis here.

Tests Done

Overall, we’ve been really careful to thoroughly test our code in a variety of ways:

  • Thorough unit tests for all the contracts: You can find these for each contract in its respective tests folder in the open-source repo. Here’s a link to one of the test files for the main entry point contract: https://github.com/skip-mev/skip-api-contracts/blob/main/contracts/entry-point/tests/test_execute_swap_and_action.rs
  • End-to-end tests on other networks: We ran e2e tests of all the contracts on Neutron testnet + mainnet. The entrypoint contract we deployed and tested on these other networks is identical to what we’re proposing to deploy on Osmosis, and the DEX and IBC adapter contracts differ only slightly. Here are the contract addresses of each contract on Neutron mainnet:
    • Swap Adapter: “neutron1khswzgxzjfeqesff3mk0ghs7m6904e70ddfhn6n3evhu5jadg58s7pve5u”
    • IBC Transfer Adapter “neutron1kuu469eu03v7dsgaptrcnhl8q8jqh5rta006lzlgyxxlxmsp3gaq3vleht”
    • Entrypoint: “neutron1grhx4mkt04aay5vnufyxxc98q44va72c80dgxdwu9dv29sxvq3usv9z8yv”
  • End-to-end tests on Osmosis testnet: We’ve also run e2e tests of all the contracts we’re going to deploy to mainnet on Osmosis testnet. Here are the testnet contract addresses:
    • Swap adapter: “osmo1ttv6e7mv3hwsy8u7erzfxhvfx55nxz5w422705jht6xk6hly745sj6aala”
    • IBC transfer adapter: “osmo16yn7gmgmsq55tlvly27tqnyrz2jry8m720k34w88jrfr0nhpgmhq4vec03”
    • Entrypoint contract: “osmo1hjzln3e58qtfljce4g3c9e9x7p8wygvlu55d9edcwukpd2uww4ssqqg7m6”

Audits

We’re currently undergoing a comprehensive audit from Oak Security. We’ll publish the results and make any requested changes before deploying our contracts on chain.

Who else has checked the code

The code is visible to anyone who wants to take a look: GitHub - skip-mev/skip-api-contracts: Contracts for Skip API. I know the Oak Security team and many members of our team have spent a long time with it. I’m unsure if there are other teams who’ve dived in for a close look, but we welcome everyone to do so!

How the community can test

The community can execute/test the Skip API Entry Point contract on Osmosis testnet by going to the following Celatone execute contract link: Osmosis Explorer | Celatone

We made a quick guide on how to do this for specific example flows that you may be interested in testing (swap and ibc transfer, swap and transfer with affiliate fees, refund works as expected on failed ibc transfers). Check it out here: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

If anybody has issues with testing the contract via Celatone and/or wants to talk directly with a Skipper as they are testing/reviewing the code, feel free to shoot jeremy@skip.money an email or ask in our discord, we’d be more than happy to assist!

4


Mike Purvis
osmo1yhqf

•

6/30/2023

Excited for this! Tremendous potential having a private mempool. Not just for DeFi directly, but anything that touches DeFi.

Highly supportive :handshake:

5

hxrts
osmo1wxfx

•

6/30/2023

ok so @Johnny Wyles has informed me that it’s standard practice to wait 3 days for permissioned contract upload proposals. so unless there are objections we’ll probably put this up on monday instead

6


Leonoor’s Cryptoman
osmo14amd

•

7/2/2023

It is even worth :slight_smile:

In Interchain Explorer by Cosmostation we agreed on a time of 7 days for smart contract uploads to be on Commonwealth.

7


Johnny Wyles
osmo1

•

7/3/2023

Probably something to fix in future, but we have that 7 day requirement for store-code proposal, whereas these are parameter changes which only need 3 days.

Since the code can be freely changed by these addresses without a further proposal these become more about whether the team is trusted with this access. This conversation is happening elsewhere on commonwealth though and I’ll add my thoughts there instead :slight_smile:

8

Leonoor’s Cryptoman
osmo14amd

•

7/4/2023

But this is then in fact 2 proposals at once.

1 is to upload the code

2 is to whitelist the address

Passing the proposal as mentioned in the first post will upload a contract, hence a storecode proposal and thus requiring 7 days according to our current agreements :slight_smile:

9


Johnny Wyles
osmo1

•

7/5/2023

The proposal can only be a storecode type or a paramchange type for the whitelist though.

I agree that the address permission is almost the same as the storecode and should be 7 days, but that isn’t what we have defined in prop 438 right now.