A simple, modular, and fast framework for writing MEV bots in Rust.

Simple code generation that allows you to enter the following command

cargo run --package cli -- --strategy-name {NAME}

this will generate a new base strategy to make it easier to develop faster.

the implementation could be a lot cleaner and I think this should be added into the base artemis command however I thought I would start a discussion on that within this thread because it may change a bit overtime. I am a big fan of how the forge library and cli is set up and we could migrate to something similar to allow for more cli additions

Description

Add Seaport v1.5 Contract address as part of the Seaport 1.5 release. Without this fix, there is an error when sending the request with the Opensea API. The error is more specifically:

INFO opensea_sudo_arb::strategy: Error getting order from opensea: error decoding response body: missing field protocol at line 1 column 57

References

Seaport 1.5 release: https://docs.opensea.io/changelog/seaport-1-5-release Seaport 1.5 contract address: 0x00000000000000ADc04C56Bf30aC9d3c0aAF14dC

Thought I'd get the ball rolling on this. Currently only added a collector following https://docs.flashbots.net/flashbots-mev-share/searchers/event-stream.

I imagine eventually the MEV-Share implementation will have a complementary executor with shared types, so anyone reading feel free to steal this for yourself if doing that.

Added a test as well but wasn't sure what it should test against, any ideas? Also, because MEV-Share has to send out an event before test completes, the test takes an indeterminate amount of time, sometimes ~5s waiting for a streamed event.

Related #4

A PR for adding more data fields into the block creator. I think it would be beneficial if we had the base_fee_per_gas, the total gas, timestamp, and the extra_data of the block being collected.

Open question: I've set the base fee to be 0 for blocks previous to London. Maybe there's a cleaner way to do this.

P.S.: I'm new to rust and the library, so I wanted to draft a small PR as I learn and explore Artemis further.

Is it possible to replace the use of openssl with rustls? If so, you should be able to change the runtime image to use distroless which would reduce the image size from 137MB to 16.5MB and increase the security of the image since you cannot shell into it or make it execute anything other than app logic.

- FROM ubuntu:20.04 AS runtime
+ FROM gcr.io/distroless/static-debian11

REPOSITORY                                     TAG             IMAGE ID       CREATED          SIZE
artemis                                        distroless      f7648ddb5cfb   45 seconds ago   16.5MB
artemis                                        latest          ffa038e5053e   34 minutes ago   137MB

Looked all around the repo for a getting started guide. Would be nice to have a guide.

I'm keen to build a strategy that listens to pending txs in the mempool and does something (not yet sure, what). Is there a collector for to get all pending txs? Where can I find this?

If a collector doesn't exist, I'm happy to contribute one with some pointers. Thank you.

Firstly if like to say I am a big fan of the design of the project.

I migrated one of my arbitrage searchers to use it over the weekend and only took about an hour.

I had a couple thoughts on the project that may make thinks a little easier to use.

1. Create an init script that allows you to create a repo with artimis core with a --strategy name to construct a bare strategy implementation.
2. Upload some docs to docs.rs

I am happy to create a PR and help out if you need!

Adding support for new protocols and maintaining support for protocol updates is a huge overhead for atomic teams. It would be great if we could collaborate publicly here to share the workload, as it's very high effort / low alpha.

The collectors / strategies / executors is a great base for separating concerns, but to be really useful in a plug-and-play fashion the architecture should also separate the concerns of "protocols".

Protocols should fit a common and extendable interface which is useful for a wide array of strategies. Implementation of new protocols should be test-driven both for accuracy of protocol interactions, and also for speed benchmarks. The idea is essentially to encapsulate the work of supporting new protocols which can then be dropped into strategies.

This feels like a potentially huge win/win for searchers, provided multiple teams are willing to contribute.