无题
任务记录
9-1
- grpc_tick 多线程优化
- tokio:: spawn 系统整体性多线程优化
- 使用 jup 的网页连接套取对应 token 的 alt - 不可取
- 指令优化 - 提前做的(建 ATA、批准、账户创建)预先做
- 使用jup提前抓取alt数据 - 不可取 放弃
- 使用 astra 啥的直接进行 ddos - 开始收费了 放弃
- 如果遇到超大额交易 进行多池子 arb 不要直接找最小的 直接发多笔交易
- 搭建 grpc 节点
- 查看是否丢失数据 - 不需要看 丢失数据也没有办法
- 解析其它的陌生交易 - 比如加池子 初始化池子交易
- 发现初始化交易的话 只需要少量 sol 可以换取大量 sol - 提交初始化池子识别
- 数据库查询优化 bincode
- 引入 usdc 交易
- http2 的连接复用
- udp 数据发送优化
- 解决抓取数据时的 panic 问题
- 做一下 pinic 过滤
- 合约里面写上日志
- nhtop 那里的 account len 可以取消了 meteora pool 这个可以换 2 种方式
- 指令的精准拼接
- pump交易修改
- 交易金额设定函数 - 基础框架搭建完毕
- pumm_amm的价格计算索引有问题
- 每一个池子的细化合约日志
- 研究“初始化交易”的还在搞一个grpc分析流
- CU setdatasize 啥的应该是合约做好之后在搞的
- 账户静态数据必须精确 必须是 sol或者usdc作为第一token的 如果不是这两个 那么就随机
- 系统账户再过几遍 进行价格审查
- 先把合约搞明白得了
- pamm 的account先是token 再是sol ata 啥的不需要交换
- 如果tick不存在的话就自动返回啥的 防止panic
- 收集信息 - arb常用池子
- 维持原来的池子即可
明天任务
tick 优化 - 有待商榷
数据初始化tx解析
n 发策略
price 的那个查找的key 统一化 sol-token usdc-token
加强指令构建
强化系统
grpc_account 和 grpc_init 账户啥的好好看一下
实现双dex 交易
系统强化 性能优化
V0 交易
amount 函数添加 sol计算和 usdc 计算
合约修改
- 有些最小值输出的地方需要标记为1
借贷指令优化一下
process 那个文件优化一下
tick 账户再优化一下
引入 alt 每一个market存一下alt数据
性能查询测试 就是那么多数据 性能会不会有什莫问题 - 已经优化 加入黑名单机制
最重要的就是多并发交易解析这个方面 不要阻塞
全局数量初始化的时候 也需要进行 key 值无序化操作
如何判断sol买还是sol卖? 就是看那个amount是第一个terfer指令大还是第二个
- 这样还需要引入小数位数 - 不需要引入 特殊点就那几个
如何判断usdc买还是usdc卖?
就是看那个amount是第一个transferChecked指令大还是第二个 其实不一定了 有的token 笔usdc价值大
有且只有一个特例 就是trump 这个 token 单独处理???
现在最大的问题是 tokenA-tokenB的情况 已经解决 目的是无序化
目前任务
-
- 写一下主要数据接收架构
- 准确解析某笔交易谁买了或者卖了多少稳定币
-
如何分析这笔交易是谁换成了谁?
做一下3hop交易啥的
保证每一个token对里面必须有sol或者usdc
还需要检查最终的首尾token是什么 如果首尾token不对 那就添加第三笔交易
标准统一
- 以sol或者usdc作为基础
- 起点和初始点是 sol或者usdc 不一样的时候才可以进行3hop套用
tess solfi 这两个池子直接套用jup合约
添加 perp
动态最优优先费
获取slot的方式需要优化
尝试 DF1ow4tspfHX9JwWJsAb9epbkA8hmpSEAtxXy1V27QBH 这个聚合合约 - 这个不考虑了暂时使用jup
添加这个池子 dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN
meteora_dlmm 的mint地址互换对交易有什么影响
走jito的sendTx 不需要bundle了
存在相同交易对 不同market地址的池子
一笔tx需要检测会使用到哪些池子,如果都是jup指定池子,那就使用jup
- 如果一个Jup,一个自己的合约,那就一半一半
分析优秀的交易以及池子 https://sandwiched.me/arbitrages
遇到超大额交易的话 优先费也一定要大(尽量大吧,毕竟没有什么本金)
超大交易的事件,使用N发送策略,如果遇到带有tick的池子,应该进行单Hop套利
单tick池子arb
搞定那几个大池子的精确解析-所有tx(添加池子或者减少池子等)
需要测试 大数据的全局变量和小数据的全局变量数据查找速度是否一样
只要dex里面存在必须是jup的 那么全部就要使用jup 此时3hop交易对需要进行考虑
添加池子 AQU1FRd7papthgdrwPTTq5JacJh8YtwEXaBfKU3bTz45
添加池子 swapNyd8XiQwJ6ianp9snpu4brUqFxadzvHebnAXjJZ
添加池子 HpNfyc2Saw7RKkQd8nEL4khUcuPhQ7WwY1B2qjx8jxFq
添加池子 zerofi phonix goonfi
添加池子 dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN
开一个rust性能测试小项目
fire_process 应该加入是哪个dex发送的交易
需要重新构建一个抓取小数位数的函数 如果存在则不抓取 不存在 则抓取 那么全局一口气拉去所有token小数位数可不可以呢
对应的合约搞好
match 里面的判断条件可以精细化一下 - 研究 match 的判断条件对于性能的影响
amm config 这个配置不一定是固定的 以后需要修改
tick_array和tick是否需要分开 必须精细化
PROGRAM_RAYDIUM_CLMM_U8 这里小问题
那些池子都写完,正常写
特殊情况,相同交易对不同market
注意这个特殊交易,需要解决
学习资源:keep-alive保活
https://astralane.gitbook.io/docs/products-wiki-zh/di-yan-chi-jiao-yi/ti-jiao-jiao-yi/fu-jia-you-hua
这种交易如何组装?
需要做的
- process构建
- alt构建
- 无await 发送
- nonce发送 - n 服务商发送
- 修修补补代码 - 代码检查
- 性能优化
- 高精度指令构建
- 强化系统架构
- 3hop 策略
今日任务
- grpc_account 必须OK
- process 必须OK
各个池子长度
| 池子 | account长度(不包括program) | 简化版长度 |
|---|---|---|
| meteora_dlmm | 19-4tick | 16(优化3个) |
| meteora_pool | 15/16 | 15/16 |
| meteora_damm | 14 | 12(优化2个) |
| raydium_amm | 17 | 8(优化9个) |
| raydium_clmm | 13-4tick | 13 |
| raydium_cpmm | 13 | 12(优化1个) |
| pamm_buy | 23 | 22 |
| pamm_sell | 21 | 20 |
| orca | 11-3tick | 11 |
| solfi | 8 | 8 |
| lifinity | 13 | 13 |
| humi | 9 | 9 |
| fusion | 14-3tick | 14 |
合约测试
| dex buy/sell | CU | setdata | 备注 |
|---|---|---|---|
| solfi | 55123/55085 | 137649 | |
| lifinity | 78305/78538 | 142631 | |
| orca | 54412/51016 | 165466 | |
| ray_amm | 29751/29761 | 135601 | |
| ray_cpmm | 43614/43616 | 139961 | sell最低是1 |
| mete_pool | 133663/133248 | 147968 | 16位的那个还没测试 |
| pamm | 109346/69006 | 243756/244493 | 啥也不需要换,保证静态数据稳定即可 |
| mete_dlmm | 47277/47009 | 169557 | 换个ata即可 |
| ray_clmm | 79310/70940 | 153065 | |
| mete_damm | 42942/41540 | 136125 | |
| fusion | 58639/54334 | 240200 | |
| humi | 38881/37194 | 136617 | CU:33589 |
| mete_pool-16 | 170287/174689 | 160027 | 第12位账户需要换一下地址 |
方向买入情况(terfer顺序根据买卖是否一样)
| dex | 是否买卖顺序和terfer顺序一样 | 备注 | |
|---|---|---|---|
| mete_dlmm | 是 | ||
| mete_pool | 是 | ||
| mete_damm | 是 | 1 | |
| pamm | 否 | 1 | |
| ray_amm | 是 | 1 | |
| ray_clmm | 是 | 1 | |
| ray_cpmm | 是 | 1 | |
| orca | 是 | 1 | |
| linfity | 是 | 1 | |
| humi | 是 | 1 | 交易方向需要注意 |
| fusion | 是 | 1 | 交易方向需要注意 |
Other
raydium cpmm 的tx读取mint的时候需要识别一下 不需要,只需要指令构建的时候进行检测就可以了




