v_exchanges

A unified library for all crypto exchange interactions, instead of manually wrapping all methods and keeping track of quirks of different exchanges. Before having this, I was never able to get production-ready any project relying on more than one exchange.

Installation

nix build

Usage

Example evocations of crate's methods are exposed in [./examples], with their [[example]] references defined [./v_exchanges/Cargo.toml]. To run:

cargo run -p v_exchanges --example binance_market_perp

The spirit of how the framework is used in code is best described with the following cli example:

use std::str::FromStr as _;

use v_exchanges::prelude::*;

#[tokio::main]
async fn main() {
	let mut args_iter = std::env::args().skip(1);
	//Ex: "binance:BTC-USDT.P"
		let mut args_iter = std::env::args().skip(1);
	let ticker: Ticker = match Ticker::from_str(&args_iter.next().unwrap()) {
		Ok(m) => m,
		Err(e) => {
			eprintln!("Error: {e}");
			std::process::exit(1);
		}
	};
	let client = ticker.exchange_name.init_client();

	let klines: Klines = client.klines(ticker.symbol, "1m".into(), 2.into()).await.unwrap();
	println!("{:#?}", klines.v);
}

if you try the following with different Exchanges and Instruments encoded into the passed ticker string, you can see that we get same well-defined type, irregardless of quirks and differences of each exchange we're interacting with.

Roadmap

• full binance integration
  • Copy over crypto-botters
  • For binance, copy over the struct definitions from binance-rs
  • distribute the current infrastructure to defined boundaries (add _adapters, keep generic-api-client for now (mb rename to _api_generics later)). Get responses with it.
  • go into src/binance/ on ::, implement klines methods with defined xxxResponse structs, have it just cover the websocket and rest for klines. Print both in main.
    • define core types
    • improve error tracing. If the response fails to deserialize, want to know why. Look up how discretionary_engine does it. Want to print the actual response (+ utils functions to concat when too long (add later)), then the target type.
  • now implement Exchange for them (same place for now). Call methods.
  • now implement Exchange for bybit.
• full bybit integration
• [.] polish http interactions in using this API in other projects
• method to execute all known requests in test mode[^1], on successfull responses, persist the returned json objects to use in test later.
• use in btc_line to get Websocket interactions nice and good
• make fitted for the final stage of full integration into discretionary_engine (requires trade execution/followup methods suite), which would signify production-readiness of this crate. upd: really should be just compatible with nautilus-trader; used only for data collection, - not trading

[^1] where allowed, otherwise use min position size or just skip problematic endpoints

Relevant projects and documentations

• crypto-botters, from where I stole the entire generic-api-client (as v_exchanges_api_generics).
• binance-rs, which provided a cheat-sheet for so many binance interactions and best-practices on testing.
• binance-spot-connector-rust

^{This repository follows my best practices and Tiger Style (except "proper capitalization for acronyms": (VsrState, not VSRState) and formatting). For project's architecture, see ARCHITECTURE.md.}

License

^{Licensed under Blue Oak 1.0.0}
_{Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be licensed as above, without any additional terms or conditions.}