13次发布
0.0.14 | 2023年10月21日 |
---|---|
0.0.13 | 2023年10月14日 |
0.0.10 | 2023年7月24日 |
0.0.9 | 2023年6月3日 |
0.0.3 | 2023年3月20日 |
#2520 in 神奇豆子
每月85次下载
用于 chaiwala
98KB
2K SLoC
基于异步Rust的KuCoin三角套利框架
这是一个异步Rust项目,用于实现零风险加密三角套利,探索生成被动收入(即睡觉赚钱!)的技术可行性。
循环套利的原理
假设我们持有USDT,它会检查所有可以与BTC和USDT进行交易的上市加密货币(例如ETH),并通过以下方式比较利润:
- 买-卖-卖:购买ETH(卖出USDT),卖出ETH(购买BTC),卖出BTC(购买USDT)
- 买-买-卖:购买BTC(卖出USDT),购买ETH(卖出BTC),卖出ETH(购买USDT)
以上是三角套利,它是循环套利的最简单形式。我们可以找到更复杂的路径,比如找到最赚钱的路线,或者在造市价格下单以减少费用。
Python中的前错误
两年前我编写了一个Python脚本,在KuCoin中运行三角套利,但它有几个技术问题,最终没有跟进。
https://github.com/kanekoshoyu/Kucoin-Triangular-Arbitrage
- 使用Python和REST轮询实现的方式过于缓慢,无法获取有效的套利机会。
- 通常Python REST API会导致相当高的通信错误率,这需要额外的时间来解决。
- 它没有计算套利订单的实际规模,这意味着脚本持续购买一些垃圾代币,无法正确卖出。
- 它简单地取平均值价格而不是最佳买卖价,这意味着在每一次套利中,它都采取了每个动作的造市头寸,并且没有及时执行套利。
如何运行示例可执行文件
- 将config_sample.toml重命名为config.toml,并使用您自己的KuCoin API凭据设置API密钥。配置事件监控间隔和循环套利每次迭代的美元预算。
[KuCoin Credentials]
api_key="YOUR_API_KEY"
secret_key="YOUR_SECRET_KEY"
passphrase="YOUR_PASSPHRASE"
[Behaviour]
# Performance monitor interval in seconds
monitor_interval_sec=120
# max amount of USD to use in a single cyclic arbitrage
usd_cyclic_arbitrage=100
- 在项目根目录(kucoin_arbiitrage)中运行以下命令
cargo run --bin event_triangular
event_triangular
是实现[XXX-BTC, XXX-USDT, BTC-USDT]三角套利的示例可执行程序之一。在bin
目录中还有其他可执行程序。
概述
代码结构
项目分为以下组件
示例可执行程序
bin
包含示例可执行代码。其中一些用于网络测试。
内部结构(独立于交易所API)
model
包含用于抽象表示市场的内部通用数据结构。这应该是独立于交易所API的,以便套利策略算法可以在不同的交易所中执行。event
包含用于在不同组件之间传递状态和数据的事件。出于同样的原因,它使用内部模型。strategy
包含套利策略算法的实现。这些算法建立在内部模型和事件之上。monitor
包含用于监控每个广播通道的MPS(每秒消息数)的计数器,以及通过字符串映射的全局定时器,便于调试访问。
链接到交易所API(例如KuCoin)
translator
包含将交易所API对象转换为内部模型以及反向转换的功能。它使用特性和每个API模型实现的特性。broker
包含运行API调用并转换为内部数据结构的任务。
使用Tokio Broadcast进行事件发布/订阅
事件广播增强了任务的模块化。每个异步任务通过事件,使用tokio的广播进行pub/sub相互通信。以下是event_triangular.rs
的示例
频道 | 发布者 | 订阅者 |
---|---|---|
orderbook | task_pub_orderbook_event | task_monitor_channel_mps, task_sync |
orderbook_best | task_sync | task_monitor_channel_mps, task_pub_chance_all_taker_btc_usd |
chance | task_pub_chance_all_taker_btc_usd | task_monitor_channel_mps, task_gatekeep_chances |
order | task_gatekeep_chances | task_monitor_channel_mps, task_place_order |
orderchange | task_pub_orderchange_event | task_monitor_channel_mps, task_gatekeep_chances |
使用Tokio JoinSet的任务池
使用JoinSets对任务进行分组和生成。我们可以使用join!
等待所有任务结束,或者使用select!
或join_next
等待单个任务结束。这为我们提供了完全控制任务的方式。以下是event_triangular.rs
中声明的任务池的示例
TaskPool | Task |
---|---|
taskpool_infrastructure | task_sync_orderbook, task_pub_chance_all_taker_btc_usd, task_gatekeep_chances, task_place_order |
taskpool_subscription | task_pub_orderbook_event, task_pub_orderchange_event |
taskpool_monitor | task_monitor_channel_mps, task_log_mps |
当任务池中的任务返回时,其结果通过join_next
接收,然后由核心的select!
接收。当接收到外部信号或核心返回错误时,由主程序中的select!
检测到,并终止程序。
主要结构改进
- 使用编译后的Rust代码,以整洁、高效和正确的方式编写代码
- 通过WebSocket订阅实时订单簿以获取所有最新的买卖价和数量
- 仅根据最新的最优买卖价/数量进行买方位置
- 将数据带宽监控和套利性能监控作为任务实现
- 使用内部模型和事件抽象订单簿同步和套利策略
- 同步和策略任务的并发
功能进度列表
功能 | 状态 |
---|---|
白名单所有可以与两种其他报价币(例如ETH,用于ETH-BTC,ETH-USDT)进行交易的代币 | 可用 |
基于最佳要价/出价价格寻找套利机会,并计算百分比利润 | 可用 |
实时复制并同步本地订单簿 | 可用 |
结构上允许并行运行多个策略 | 可用 |
在三角形套利机会上放置订单 | 可用 |
针对无法成交的限价订单采取补救措施 | 挂起 |
中间币不是BTC的完整三角形套利(例如ETH-USD,ALT-ETH,ALT-USD) | 挂起 |
部署
请参阅我另一个实现服务级封装的repo: chaiwala
社区
- Rust问题: GitHub仓库讨论
- 套利问题: Discord服务器
依赖项
~13–30MB
~468K SLoC