ARC-44: Astroport <> Skip - Sharing MEV Back with the Astroport Community

[mag]

Astroport <> Skip Proposal

Skip would like to work with Astroport to co-create a custom MEV solution to recapture MEV and return it to the Astroport community wherever the DEX is deployed 💰

We believe this will create a new source of sustainable, non-inflationary revenue for the Astroport community as it expands across the Cosmos

Please see here for the complete proposal, plus diagrams!

📜 Background

About Skip: Skip builds sovereign, custom MEV solutions for protocols and app-chains. Our mission is to help protocols recapture MEV for their users, to create more sustainable financial rewards.

Astroport MEV: Since Astroport is a DEX, it generates a significant amount of MEV. DEX MEV can take multiple forms, the main ones being:

✅ Backrunning (cyclic arbitrage): this is “good MEV” - capturing it does not affect execution price, and if not recaptured will otherwise leak out of the Astroport ecosystem. These are MEV recapture mechanisms that happen after your trade.

❌ Frontrunning/Sandwiching: this is “bad MEV” - capturing it involves forcing retail users to pay artificially worse execution prices, by buying up assets before you intend to trade, to force the trader to pay a worse price. Skip will not be introducing or recapturing MEV by this method, and will work with the core team to prevent this kind of extraction by any parties, and the proposed solution solves for this.

❌ JIT Liquidity: it is unclear whether this kind of MEV this is positive or negative - it involves frontrunning a trade in a concentrated liquidity DEX to inject liquidity at a very tight band, giving the trader better execution price, but giving the injector all the LP fees. This damages the income of passive LPs over a wider band. Skip will not implement this kind of MEV until Astroport’s concentrated liquidity solutions mature further, and if the community votes to introduce it.

Astroport MEV is already being captured today, and is leaking out of the system. This proposed integration gives the Astroport community a voice at the table in their own MEV recapture to prevent MEV value leakage away from Astroport users.

Skip already enables an active marketplace for Astroport MEV recapture (here is a >$1500 Astroport arb on Terra2 recently that was captured via the Skip Select auction: finder.terra.money/mainnet/blocks/3857105), and is deeply familiar with its MEV ecosystem. We are excited to bring LPs and users to the table via this implementation.

Proposed Solution

Stage 1: Frontend-Implemented, Community-Controlled Backrunning Bot

• Skip wishes to design and build a Skip-maintained backrunning bot that returns MEV revenue to the Astroport community on a per-transaction basis and has spent the last three months familiarizing itself with Astroport (including through discussions with Astroport developers) in order to be in a strong position to do so.

• This solution uses Skip’s existing auction system (”Skip Select”) to create an atomic backrunning tx for each trade. It does not modify the contents of any trades or introduce any new security assumptions.
  • Notably, it does not affect the execution price of the trade in any way (as the backrun happens after the original trade)

• Note that transactions from the frontend will be sent through a private, backrunning-specific RPC endpoint that ensures first right to backrun the transaction (and prevents any frontrunning by other parties!), thus ensuring agreed payout guarantees to the Astroport community

• User Experience
  • The app.astroport.fi frontend will by default send transactions to this “backrun swap” RPC (if available on that chain), and users can untick a box to submit to the regular mempool instead (and not receive any rewards, forfeiting backrunning MEV to mempool searchers)
  • If chosen, a “backrun swap” will return MEV funds via a MsgSend to the user automatically on chain
    • This could also be used to make “gas-free transactions”
  • Note, in the case of chains where Skip does not have 100% validator coverage, a “backrun swap” may take longer than a normal swap as the RPC waits until a Skip validator is proposing a block
    • This may be an extra 5-30s, and much shorter on fast chains (e.g. Injective)
    • This can be configured to be capped (e.g. attempt to backrun for 30s, otherwise send to regular mempool)
    • Stage 2 will remove this timeout
  • Delphi Labs, the owner/operator of app.astroport.fi, has indicated its willingness to integrate the necessary changes if this proposal is approved by the Astroport Assembly.

Stage 2: Router & Smart Contract [Future]

• Although not yet fully designed, this approach will make backrunning more trustless by tying the Astroport router to a wasm smart contract that will automatically backrun every transaction (i.e. on-chain logic similar to ProtoRev on Osmosis)

• This is part of our progressive decentralization approach to move logic on-chain, and removes Skip and its infrastructure as an intermediary

• This would not require coordination with validators as Stage 1 does, and would remove any submission delays

• User Experience
  • There would be no noticeable UX differences for users via this approach, except that txs would be “upgraded” to recapture backrunning after the original trade, and broadcasted as an atomic transaction with the backrun included

Future Explorations

• Skip will maintain lines of communication with Astroport developers and the broader Astroport community to explore further decentralization and new designs, especially those that include multiple searchers in the process of recapture (similar to how the Skip Select auction works today)

• Skip will continue to explore cross-chain MEV recapture solutions as Astroport expands, between outposts on different chains

⏱ Timeline

• April 2023: Deploy Stage 1
  • 1st → Terra2
  • 2nd → Injective
  • Skip will continue to add support as Astroport deploys on more chains

• June/July 2023: Deploy Stage 2
  • Same chain deployment schedule as Stage 1

💰 Compensation

Due to the initial costs of building this MEV recapture infrastructure, we propose compensation for this implementation to follow the same compensation agreement Skip has with the Osmosis community for a similar product (ProtoRev). Note that the implementation details differ dramatically between the products.

Details on this funding agreement are on the Osmosis grants page and the passed Prop 341 on Osmosis.

Initial Grant

• $75k in ASTRO token, vested over 3 milestones:
  • $25k upfront to kick off resourcing and development
  • $25k upon working testnet implementation, according to Stage 1 above
  • $25k upon 4 weeks of functional mainnet implementation, on at least one chain, according to Stage 1 above

Backrunning Payments Distribution

• Profits to Astroport Community
  • 80% (specific distribution to be decided by the Astroport community in a separate proposal)

• Skip fee
  • 20% (decreasing by 50% per year until stabilizing at 5%)

🤝 Contact

Please reach out to us if interested in discussing or collaborating!

Twitter: @SkipProtocol

Discord: https://discord.gg/9Uq8NFMQJ7

Site: skip.money

Telegram: @magmar100

[stefan]

I think this is a well thought out and really timely proposal given the latest discussion around Astroport and MEV. I agree with the approach to start with a RPC endpoint and move toward a smart contract integration further down the line.

Regarding the MEV revenue split, I propose the following:

• 20% goes to Skip as mentioned (in the first year of operation, after which I think it’s fair to do a similar thing you guys plan for Osmosis and take a smaller percentage)
• 60% goes to LPs (from the pool/s used in the swap initialized by the trader on Astroport)
• The remaining 20% goes to xASTRO stakers

Would love to know what others think about this potential split and about the proposal in general!

[MaxCallisto]

Thanks, @mag . What will be the difference between the implementation of Skip with Terra validators & this proposal? Currently, MEV captured by validators will be shared between a % kept by the validator & another % distributed back to all stakers. How does this implementation with Astroport differ from that?

[unsinn]

Not sure if I’m getting this right:

• With the current skip implementation in terra, the skip fee paid by searchers goes back to the network and to the validator proposing the node in different % depending on the validator setup.
• With this new solution mev goes to Astroport. That means:

1. no Searchers are needed.
2. Nothing goes to validator/network?

However skip still needs validators to use skip. What would be the incentive for validators to use skip if mev is going only to Astroport?

[donovan]

I believe this is a fair and well put together proposal. Two things:

1. I agree with Stefan’s split of 20% Skip, 60% LPs and final 20% to xASTRO stakers.
2. From Skip’s side, is this a definite commitment to support all the chains Astroport may deploy on as voted on by governance?

[mag]

Thank you for the support! Interested to see what the community has to say on the split you mention

[mag]

In the V0 approach, yes - if the chain also has a sufficient number of validators running Skip. In the V1 approach, definite yes.

[mag]

Hey Max, this proposal gives Astroport (in particular the frontend) a seat at the table in deciding distribution. Everything that hits the public mempool is still fair game and will be picked up by searchers and run through the Skip auction, according to the validator’s splits.

Given the V0 implementation requires validator buy-in (i.e. they are running a top-of-block building solution), in my opinion they should also receive some of the rewards. The V1 implementation is smart-contract based and therefore is only reliant on transaction modifications.

This is an early, but still fully effective, proposal for Astroport to recapture its backrunning MEV. Future versions of the incentive design will include more searcher involvement, and our hope is that the “generalized” solution of Skip on Terra2 will end up capturing MEV that is much further-reaching than just Astroport over the long run.

[mag]

Hey Unsinn, good to see you from the Discord - answered some questions here but to repost for visibility:

The current implementation you fleshed out is correct. In terms of this proposal:

1. The backrunning, to keep the orderflow private, will first be done by Skip. However once we solve the privacy concern we plan to discuss creating a marketplace for searchers to participate in the future.
2. This is to be decided - the 80% share back to the community will be decided on a separate proposal. This proposal is to give Astroport a seat at the table in deciding redistribution, but exact numbers are not decided here.

I do believe that validators, especially as they are integral specifically for the V0 design, should be considered by the community to receive some of the rewards. However, our hope is that Astroport is not the only form of MEV recapture on Terra2 and other chains in the long run, and the products are complementary.

[John_Galt]

This proposal is very exciting, and definitely gives Astroport a leg up over other DEXes.

But I’m a little underwhelmed by the stage 1 product. Astroport is and will be the only real source of MEV on Terra, Injective, Sei, and Neutron for the lifespan of the stage 1 product. So the only reason for validators to run the Skip software is to get MEV from Astroport, meaning Astroport will have to agree to share a significant amount of profits with validators to incentivize them to run the software. At least 50%, I’d say. And even so, many validators probably won’t run Skip’s software, meaning that wait times for tx processing will likely always be high. So the stage 1 product isn’t that appealing.

But the stage 2 product is very exciting! No wait times for tx processing, and Astroport gets to keep 100% of MEV profits (minus Skip’s share, of course).

Is it possible to just go straight to the stage 2 product? Why is the stage 1 product necessary at all, if it’s just going to be replaced in a few months?

Also, according to this proposal, is Astroport going to have to pay more after the “initial grant”? Since none of the milestones are tied to the stage 2 product, it appears that product my require an additional grant.

[mag]

Hey John!

That’s helpful - the V1 product is not “ideal” but it’s very doable (in fact, much of it is built out already), so we viewed it as a good, fully working POC for the integration overall. We can ship this quickly with few unknowns, and iterate on it to make it better. Also, with the V1, we get some special things:

1. Free gas potential, since it uses the Skip infra
2. Potential to open up to more searchers for competition
3. Simulation (i.e. no reversion) guarantees, if needed
4. Fast iteration, as most logic is offchain

Also, the timeouts shouldn’t be bad - we have growing integrations and coverage on Terra2 (40% of network) and Injective (just launched, growing quickly). It would roughly be an additional 2-3 blocks max for transaction confirmation. We plan to integrate 20-30s timeouts to default to regular tx submissions to preserve UX around this, and potentially the user can adjust these.

V2 does have upsides in the timeout and coverage question, and as we specced we plan to move towards it quickly. We have had success with a team doing iterative product shipping, building towards ideal solutions. We don’t view V2 necessarily as a superior, defacto replacement, but another area of exploration we can try out and, if successful, eventually use to replace V1. And no, we will not ask for an additional grant - this is to cover the entire integration end-to-end

Hope this is helpful, and please let me know if you have any more questions or if I didn’t answer these as you were hoping.

[paletas]

I’m in overall agreement with the proposal but would like to see what “functional mainnet implementation” entails, as of right now the proposal has no constraints on it benefiting the ASTRO community. I’d love to see value capture being a constraint on the last tranche of payment, maybe even an analysis of expected returns over an X amount of time, or we could be paying 75k$ for 100$ returns over a year. Are we even sure there’s an acceptable ROI? Should be something that could be done looking at transaction history and price impact on swaps, but I imagine it could be a lot of work.

Code running in production, with no value capture, brings no value to the community, in a worst-case scenario we could be paying for a worse UX for users (waiting for a skip-compatible validator to mint a block).

As for the distribution, I agree with rewarding LPs but only for LPs with no ASTRO incentives, otherwise we’re paying twice for liquidity. Split should be 80% xASTRO for incentivized LPs and could be the suggested 60% LPs, 20% xASTRO for LPs with no ASTRO incentives, external incentives would not affect the decision.

[codenoodle]

If the Astroport community is paying $75k plus 20% profit share, how long until the MEV capture reaches the breakeven point for this amount paid? What is the estimated expected return over time that justifies an investment in this product? Especially when given, as John Galt mentioned previously, it is only a temporary solution until Stage 2 is ready (which is not included in this cost). I think if we had some good estimates in that regard, then it would make this a very easy decision one way or the other. Thanks!

[MaxCallisto]

Thanks, Mag. Since validators will be receiving some of the rewards, what % from the MEV profits will be routed back to the validators & if Skip’s 20% will make part of the validators’ rewards?

[John_Galt]

I would agree that V1 isn’t ideal.

• It only targets swaps using the Delphi frontend, so it misses MEV created from the fairly-popular Station and TFM frontends
• It introduces a trading delay, which is very bad for UX. Delay might be lower if more vals run Skip software, but we can’t control that
• A significant amount of the profits have to be shared with vals, or they won’t be incentivized to run the software
• And ultimately, Astroport probably doesn’t even generate that much MEV in the first place. (Or does it? Do we have any estimates?)
• And sadly, it appears that the V2 approach isn’t a certainty. It could be that the V2 approach doesn’t work out, and Astroport gets stuck with V1

I would like a couple more questions answered.

Do you have an estimate of how much harvestable MEV Astroport has generated in the past three months?

Also, can you use a percentage to estimate how likely V2 is to work out? Is it 75% likely, or more like 90% likely?

Despite my pessimism, I am in favour of working with Skip. Over the long term, I’m pretty sure this will benefit Astroport. It’s just a little unfortunate that V1 has so many draw-backs, and that V2 isn’t a certainty. Is it possible to alter the proposal slightly so that it focuses more on the V2 product?

[surfers_paradise]

Hey, interesting overall but same question as paletas and codenoodle, can you provide data on current MEV capture on Astroport to justify this cost? Thanks

[mag]

Great points - we can supplement a further iteration of this proposal with more research, which we should share with the Astroport community regardless as MEV recapture of Astroport is already happening - except none of it is returned to LPs or the community at this time.

It’s definitely not $100 though - linked in the proposal was a $1500> MEV arbitrage that happened days ago. It’s hard to add up and estimate all the MEV Astroport will generate over time, but over the last 2 months or so only on Terra2 it’s been >$5,000

Also, there are simple workarounds for the UX issue - for example, if there is not a Skip-running validator next (we know in Tendermint), then it could be submitted normally. I’m confident this could be solved for.

Your last point makes sense - we had planned to leave distribution to a later proposal, as we want to leave this up to the community, however we think there’s more work to be done on our end before a further iteration of this proposal in understanding incentives across the board.

[mag]

We’re not sure yet and ultimately not in a position to decide, but would recommend that validators are considered since they are securing the blocks and providing the infra that Astroport runs on - something to consider as removing their MEV rewards might be a negative outcome for Astroport’s relationship with partner chains.

We can follow up with a more precise suggestion in a future iteration of this proposal.

[mag]

Great points John. We’ll be following up with a further iteration of this RFC with more detail on:

1. Better estimates of MEV recapture on Astroport (of course, this stands to be a lot higher soon with more deployments) - our estimates are that it’s been well over $10,000 over the past three months on Terra2 alone, and $3000 of that has been captured by the Skip auction (see skip.money/activity on Terra2) - and this is not complete as the auction is not maximally competitive and around 40% of the blocks run through the Skip auction
2. More detail on the V2 implementation, the feedback here has shown this as topic of deeper interest. It is doable, but is not a “fix all solution” - on-chain computation is expensive, but we’ll share more on this.
3. Ways to solve around the UX delay (idea - just don’t submit to the Skip RPC if there’s not a Skip validator up now or next block)
4. Thoughts on validator incentives, after discussions with them

I appreciate your feedback on this. Does the above being answered sound like a good next pass? This was a great source of feedback for us on building app-focused MEV solutions.

[mag]

Thanks for the feedback codenoodle. We can include breakeven estimates in the next RFC we post, but do note - V2 is covered in the proposed funding amount, there’s not an additional request for funding afterwards.