ARC-46: Astroport <> Redpoint - MEV Proposal

Proposals ARC (Astroport Request for Comments)
1

Redpoint Arbitrage

Astroport MEV proposal

Our team

Redpoint Arbitrage is created by a self-funded small business. Its owner, Kyle Moser, has degrees in Computer Science and Cybersecurity and over a decade software engineering experience, including building major public key infrastructure.

In addition, our team helped build Sycamore Tax app and has several grants with Osmosis, including a “Testnet arbitrage” grant to improve testnet price accuracy. Finally, we built the MEV products below, which will aid an understanding of our Astroport proposal.

MEV products

Osmosis Arbitrage Bot

8 months ago Redpoint launched an arbitrage bot on Osmosis which competes with other arbitrage bots to earn revenue. We gained a deep understanding of Tendermint and Cosmos SDK, implementing mempool spying and presigned arbitrage TXs. Our bot supports simple cycles (graph theory) of between 3 and 7 vertices. Most arbitrage can be captured by cycles of length 3 or 4.

  • For cycles of length 3 or 4, we use Johnson’s algorithm to discover the cycles.

  • For all cycles, we use a customized version of the Bellman Ford graph algorithm to discover “negative weight” (e.g., potentially profitable) arbitrage opportunities.

MEV simulator (Redpoint)

Most MEV is wasteful, spamming failed TXs on chain (only one bot can “win” the search). To solve this problem, Redpoint created a simulator API for Osmosis and Junoswap (currently live for Osmosis) which works as follows:

  • The trading website queries our API, asking “what arbitrage trade will be possible if the user makes the following trade {1000 OSMO for ATOM using pool 1}”?

  • The API answers “Trade 300 OSMO through pools 1, 3, 5 to earn 1.5 OSMO in arbitrage”.

  • The website submits a single TX with two swaps, (1) the user’s swap and (2) the arbitrage swap.

  • This technique ends “racing” and TX spamming. Since TXs are atomic, ours wins automatically.

  • On chains that support CosmWasm, the arbitrage swap is submitted through a smart contract.

  • Defiant has a working Junoswap contract for this (which we plan to adapt for Astroport).

Redpoint invented the MEV technique above (on-chain example). We released a CLI tool for Osmosis users to arb their own trades here as well as a Javascript API for partners.

Astroport proposal

Redpoint’s MEV capture solution for Astroport will complete in three stages. Our proposal is designed to begin capturing arbitrage for the protocol during stage one. Our arbitrage algorithms support all pools types used by Astroport (constant product and stableswap invariant).

Our simulator API will be used to find arbitrage routes (see above) and our smart contract will be used to submit trades. Stage one will complete and start capturing arbitrage for Astroport in roughly 6 weeks, and Redpoint will take ZERO payment until stage two is completed.

Arbitrage smart contract

This contract applies to all stages. Our arbitrage smart contract is already tested (for the criteria listed below):

  • Users never send funds or conduct swaps with our smart contract, so there is no risk to the user.

  • A smart contract failure never causes the user’s TX to fail. At a high level, it does this by using submessages.

  • Our system consists of one smart contract that distributes rewards, and one that performs swaps.

  • If there are no rewards, no arbitrage is distributed, but the TX still succeeds.

Stage One: Off chain simulator

Our estimated timeline is 6 weeks since we have already built a simulator and arbitrage smart contract (for other DEXs). Our Astroport smart contract will support splitting arbitrage profits as follows:

  1. A percentage (note: this can be set from 0 to 100%) of all profits will go to an Astroport-controlled grants address, where the grants team can manage the funds to be put towards protocol development.

  2. The remainder of profits will go to the user who initiated the trade.

Redpoint will take NO payments during stage one.

Stage Two: Staker/governance distribution

During stage two, we will modify the distribution mechanism as voted on by the Astral Assembly. We propose sending arbitrage profits to stakers and governance. We propose doing so via the Maker contract, by sending funds to Maker with an arbitrage collection strategy (like the fee collection strategy). Therefore, in stage two:

  1. For one year, ten percent of arbitrage revenue will go to Redpoint (via the smart contract). After one year, the fee will be reduced to five percent.

  2. A preconfigured percentage of all remaining profits will be distributed as decided by Astroport governance. We propose it goes to stakers and governance as defined by the Astroport Maker contract.

  3. The remainder of profits will go to the user who initiated the trade.

We estimate stage two will take approximately 3 months to complete after stage one is delivered.

Stage Three: On-chain simulator

In stage three, Redpoint will build a fully on-chain solution. This means our off-chain simulator will no longer be needed. We will develop a smart contract that solves the arbitrage route problem (using the same algorithm described in this paper, see Differentiators below). Our fee schedule will remain the same (e.g., 5% of arbitrage revenue if it has been more than one year since stage two was introduced). We estimate that stage three will take 6 months to complete after stage two is delivered.

Differentiators

Our tooling is publicly available (see our Twitter and links throughout this proposal). The Astroport community can be assured that we are fully capable and can use our tools rather than taking our word for it.

  • Our arbitrage algorithm is more advanced (faster, and equally as accurate) as any of our competitors.

  • We derived an algebraic solution to the arbitrage problem (how many tokens, what routes).

  • Competitors typically approximate a solution through repeated guessing.

  • Our algorithm works in under 500 microseconds in the worst case (measured on localhost).

  • Our simulator tools are Dockerized, inexpensive, highly available, scalable, and process thousands of requests/second on a single node.

Project Deliverables

Off-chain simulator and Javascript API: Allows Astroport front-end to query the Redpoint API for arbitrage related information and submit to our smart contract.
On-chain smart contract v1 Smart contract created in stage one. Allows Astroport to submit an arbitrage trade. Open source contract and test library which proves our simulator and smart contract correctly produce trade routes & successful earn arb revenue.
On-chain smart contract v2 Smart contract created in stage two. Updated distribution to stakers/governance. Open source contract and test library as above.
On-chain smart contract v3 Smart contract created in stage three. Fully on-chain (Astroport frontend will not need to call any off chain API). Same as smart contract v2.

2 Likes
2

Thank you for the proposal @kyle! Regarding the MEV revenue split, I propose the following for stage one:

  • 80% goes to LPs (from the pool/s used in the swap initialized by the trader on Astroport)
  • The remaining 20% goes to the Maker contract where fees get swapped to ASTRO and sent to xASTRO stakers

As for stage two, I think the following revenue split could work:

  • 10% goes to Redpoint (in the first year once stage two is active, after which it’s 5%)
  • 70% goes to LPs
  • 20% goes to xASTRO stakers (via the Maker contract)

The rest of the plan looks great and I’d love to see feedback from the rest of the community!

1 Like
3

Stefan,

First off, thanks for considering our proposal.

We have no problem distributing the funds that way.

Just a note: that pushes the timeline for stage 1 closer to stage 2, since the distribution mechanism is the main thing we don’t already have implemented. I think everything else in the plan remains the same.

4

Hi @kyle , thanks for the proposal. How is the implementation of this MEV capture different from Skip’s proposal apart from the fact that Redpoint is not asking for a funding grant from Astroport?

5

So, if I understood it correctly, you’re not asking for funding but rather “bidding” to be Astro’s MEV capture provider and earn the fees that come from it, is this correct?

If you are not asking for funding, I believe it would be better if we agree on a timeframe here, we may choose to have you as a MEV provider now, but we should not assume it would be that way forever, and in that case what would the minimum period we should agree upon.

If you are planning to ask for funding, then we should discuss the fee split in terms of, allowing Astro’s to use revenue capture to recoup initial investment, before splitting any fees, or have a lower % until that happens.

In terms of the plan, I do not dislike it but it’s important to state that until stage three, any trades made outside Astroport’s front-end will not result in any MEV capture, such as trades made by routers and aggregators (such as TFM). It is important to know how much of the trading activity happens on Astroport’s front end vs other sources, as that may make stage one and two not worthwhile investment.

Finally, in regard to the split I’d like to state again what I’ve said on Skip’s proposal @stefan, I do not believe MEV capture should be split with LP providers on incentivized pools, we’re already paying for that liquidity, MEV capture revenue should only be split with LP providers for pools with no internal incentives.

1 Like
6

Assuming I understood correctly, I don’t think it’s sound for LPs in the arbed pools to forfeit MEV toward other pools with no incentives.

First, those unincentivized pools don’t have incentives for a reason, most probably because they don’t generate enough trading fees in the first place to make emissions viable.

Second, using some LP funds to generate revenue that then goes to other LPs is not fair. This redistribution is not just subjective, it’s similar to an inneficient central authority deciding how resources are distributed in a society.

1 Like
7

Max, thanks for the reply.

It’s different from Skip’s proposal in several ways. From a pricing standpoint, mine is cheaper for the Astroport community.

  • For year one, Skip is asking for 75K plus 20% of MEV captured. For year two, Skip is asking 10% of MEV, for year three, 5%.
  • I am asking for no money upfront, 10% of MEV year one, and 5% after that.

From a functionality standpoint, Skip’s proposal for their stage one says it will “take longer than a normal swap”. My proposal will not take longer than a normal swap in any of the three proposed stages.

Skip’s stage two is identical to my proposal conceptually (we both plan to implement smart contract solutions to capture MEV in-protocol). If you look at some of my many examples on osmosis, we have been working toward this technology for a while. (The second swap is the arb; on Astroport this would be done with a call to a smart contract).

As it says in the Differentiators section, my technology uses an algebraic formula to figure out what routes to use and what amount of tokens is needed - therefore, it runs in fast, predictable constant time. This is important when implementing on-chain solutions that run after every single swap.

As far as I know, mine is the only company that can do this (at least at present), but I don’t wish to speak for Skip or others - you’d have to ask them.

8

Paletas,

Thanks for the insightful reply.

I am not asking for any funding from Astroport. The monetization (on my end) would be that 10% of MEV capture (for year one) and 5% (thereafter) would go to my company.

You made an excellent point about the timeframe. I think it would be fair for the community to take a yearly vote (after one year of 5% MEV capture is finished) on whether that percentage is still reasonable.

That said, I think it is a worthwhile investment for Astroport: there is little risk on Astroport’s part (since Astroport isn’t paying me anything), only upside.

You are correct that my proposal’s stage 1 and 2 would only capture MEV from the Astroport front-end. Stage 3 (my in-protocol solution), you are correct, would capture MEV across the board (no matter what front-end is used).

I don’t see this as a downside, you can’t capture MEV until you build an in-protocol solution. I am just offering to very quickly start capturing some MEV in stages 1-2.

I will also note that since I already have a smart contract (for Junoswap) that we designed for MEV capture, I am fairly confident in my time estimates, especially for stage 1-2.

Finally, I will say it makes sense to me to distribute funds the way Stephen suggested - it’s fairly straightforward to split the funds so it goes to the pools that the trade routes used. To an extent (as long as I think it’s reasonable to implement e.g. fits into Astroport’s existing mechanisms well) I am open to different distributions.

9

Thanks for the reply, Kyle. From a revenue split perspective, I agree with @stefan’s suggestion on the split. The decision boils down to whether Redpoint is able to do better with no funding vs Skip’s mechanism (with Astroport paying $75k funding). I will leave that decision to those with better technical knowledge in this space.

10

I didn’t say that MEV capture from one LP would go toward others, incentivized LPs MEV capture should either go towards xASTRO holders or towards some fund to buy back ASTRO and build up the incentives pool, so that we may keep paying them.

Each LP pool should only get the capture from that very same pool, in that we agree.

@kyle as for the distribution solution, it shouldn’t be more complex than an address to send revenue to, that way Astroport remains in control of how to distribute that revenue.

Thinking a bit better on the subject, it could be a collection of addresses with the split, which should add up to 100%. The solution would then deduct the payment first and split the rest per the provided configuration.

11

Max,

Great points. The cost difference is also 10% cheaper for year one and 5% cheaper for year two. This may be more significant than the 75K (market dependent).

As far as ability to execute, I have provided links to my existing services and mintscan links, the community has the ability to check out how well these services work.

I would love to have a discussion with the Astroport community to talk about my experience in the MEV space and get into more technical detail about my proposal, is this something the community would be interested in?

12

Hi Kyle. Thanks for the proposal, I also have a few questions.

Wouldn’t the new smart contracts cost a lot more gas to execute? Especially the third stage where the arbitrage algorithms are running on chain.

Regarding this third contract. Will it be open source as well? This means you will expose your algorithm?

And last… could you elaborate on how the stage 3 smart contract would capture MEV when tx are entered from other front-ends. Let’s say I enter a swap from tfm using the tfm router, which calls one or more Astroport pools. How does the Redpoint smart capture the MEV in this case?

Thank you!

16

Could you please check DM ser?

17

Hey unsinn! Love these technical questions and thanks for replying.

wasmd charges gas on a lot of factors including CPU time: so yes, it will cost gas. There is no looping in my core algorithm and runtime is a predictable time (under 500 microseconds). So I think gas cost will be minimal and is an advantage for my algorithm over others.

I think all of the smart contracts will have to be open source according to the Astroport team’s philosophy, I will defer to them on that question. I consider Astroport a major opportunity, and thus, the upside is worth it.

In stage 3 the smart contract can be invoked by the existing Astroport swap contract (for single and multi-hop swaps) through a contract or submessage execution. So it would apply to all clients (Astroport front-end, TFM front-end, CLI tools, etc).

1 Like
18

Done, I messaged you. Thanks!

19

Hey - Maghnus from Skip here. Great to see competing proposals - all good conversation and have high regard for @kyle - we’ve had many conversations in the past.

A lot of these comments are asking about comparisons to our proposal. We are reformulating our proposal given feedback on our RFC with an improved mechanism and incentive alignment, and so I would not index so much on comparing to the first RFC (and it’s funding amounts). Also, we are chatting with @kyle this Thursday to see if any efforts can be aligned. Regardless, we will be posting a follow-up this week for the community’s consideration.

Very exciting to see so much innovation in this space. Confident the right solution will be selected!

4 Likes
20

I feel like v1 and v2 are not necessary, as Astroport could already integrate TFM without needing to pay for the fees. There are options to only use Astroport for trades.

Only interesting is Stage 3. I do like to have a MEV capture by users and LPs of Astroport. I’m looking forward on how it is done without increasing gas costs too much.

What I don’t like is the distribution and I propose the following distribution:
45% to the trader/user
45% to the LP
10% for the platform (first year to redpoint, second year 5% redpoint, 5% astroport stakers)

  1. Users will need to pay for additional gas costs while also increasing their spread instead of the optimal swap.
  2. Without giving a share to the traders, integration of the tool into other DeFi applications to build upon makes no sense.
  3. The trader/user is the one bringing the volume and already paying fees to the LPs and the platform.
  4. The trader/user is the one who is clearly loosing value from using it instead of 0% extraction tools like TFM.
21

Thanks for the feedback Philipp. Does TFM capture MEV directly within a single TX like my v1/v2? I do not believe so but I could be mistaken. Great points on the distribution!

22

On Terra they will aggregate multiple routes in a single TX, but based on the screenshot they probably don’t extract the maximum possible value, as they use often have a uniform distribution between multiple dexes.

image
image1249×942 51.6 KB

23

Agreed and thanks again for the discussion. I will definitely revise my proposal with some clearer diagrams etc. when I post a v2, I think that would help distinguish the arbitrage mechanism I’m using from aggregator solutions.

BTW, @mag, great proposal from you guys as well and looking forward to chatting.