#websocket #client #binance #api-bindings #async

nightly v_exchanges

Implementations of HTTP/HTTPS/WebSocket API methods for some crypto exchanges, using crypto-botters framework

15 releases (6 breaking)

Uses new Rust 2024

0.10.2 Apr 29, 2025
0.6.7 Mar 15, 2025

#245 in Asynchronous

Download history 252/week @ 2025-01-13 100/week @ 2025-01-20 180/week @ 2025-01-27 120/week @ 2025-02-03 7/week @ 2025-02-10 32/week @ 2025-02-17 167/week @ 2025-02-24 141/week @ 2025-03-03 159/week @ 2025-03-10 39/week @ 2025-03-17 4/week @ 2025-03-24 1/week @ 2025-04-07 323/week @ 2025-04-28

324 downloads per month
Used in rm_engine

MIT license

110KB
2.5K SLoC

v_exchanges

Minimum Supported Rust Version crates.io docs.rs Lines Of Code
ci errors ci warnings

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.

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

Relevant projects and documentations


This repository follows my best practices and Tiger Style (except "proper capitalization for acronyms": (VsrState, not VSRState) and formatting).

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.

Dependencies

~7–20MB
~233K SLoC