😊 全能顶级web3科学家 😊 初代攻防逆向工具开发者 🍏 全平台逆向分析，你听过没听过的都干过 💔 游戏脱机(web,pc,android,ios) 💜 量化\套利\新闻交易\山寨合约 💚 O-AI (暂停) 蓝V回关
Joined March 2017
- Tweets890
- Following2.9K
- Followers5K
- Likes1K
反向教学如何15天亏掉几十万U
不缺天天教赚钱的，其实能信的只有标点符号。看我这个是不是真实一点，引以为戒，远离垃圾项目方。
我要说的就是edgex这个是傻x项目。
一、=========当时的项目分析============
Edgex的参与赔率分析
Edgex的Pre-Tge Season按照当前的情况来看：
（1）在3月TGE（也就是最后时间）的概率极大，按照规定，会增加5%的token发放
（2）之前的Points总量约为7,311,219.3，对应TGE为30%-35%左右的token 份额，那么5%的token对应积分为：104W-120W
（3）每周的XP上限为120W，那么从1月7号计算，到3月31前大概12周，那么总量XP大概为1440W
（4）计算XP对应的point比例为14-12xp/point
再根据实际的数据来计算获取xp的效率：
EDGEX的新手任务是：手机端交易5W交易量可以获得10xp+30maru
（1）方案为：edgex采用双边对冲，一边是maker，一边是taker，maker的费率是万分之1.5，taker的费率是万分之3.6，返佣按照35%计算，实际测试磨损为：单号14-15U
（2）叠加充提币（edgex提出币需要千一的费用），约为2U，则单号损耗为16-17U
（3）30maru大概1.5U，但是因为maru需要100个才能充提，归集需要减少10maru，所以单号的maru按照1u来回归计算，则单号损耗为15-16U
（4）由于交易量也会获得xp，所以单号的xp大概是14-15
（5）所以1xp的实际成本约为1.1U，单号的point获得约为1
最后根据Point的价格预估来计算赔率：
（1）按照当前OTC的价格来看，Edgex的Point积分~60U/point，对应FDV是2B
（2）考虑到当前行情的走弱，可以适当降低积分价值到~30U/point，对应FDV是1B
（3）那么15-16的损耗，获得的价值大概为：30U，赔率为2X；如果项目能到2B，那么赔率就是4X
二、技术分析
因为要移动端才有加成，所以需要模拟成手机
大年30到初五我都基本没什么睡觉，一直分析还原签名算法。
他这个app是fullter写的，随机移动端UA (Dart/3.8)
JA3/JA4 TLS指纹，WebSocket Sec-WebSocket-Key随机等底层一些防女巫。
1.身份隔离
用了日韩新加坡的加宽代理池。A/B账号不同IP，运行时动态代理旋转;
2.行为拟人等一些处理
当然当时细节考虑太多，也就不展开了，毕竟要是女巫了我这压力就大了。
三、产品实现与跑动
几天时间陆续做了3万号
也不想说了，看下面视频
四、回报
最后1xp给了0.2edgex吧我都忘记了，时间久了，总之是赔率分析划中的十分之一（赔率分析是找到之前文档）。
听说这个项目有人请几十个人拿手机左右互戳的， 我算是没要什么人工，除了回报损失，也就一点ip费用了。
不说了，牛市来了，要从交易中去割回来了😉。
#web3 #撸毛
5
11
2,126
O-AI 之合约交易-自动驾驶机器人 工作回报💕
1. rtx-5090D 测试也只能跑14B左右的模型，准备用14B 模型微调，目前还是接deepseek测试.
2. 仓位管理还需要调整.
3. 独立一个全局风险管理.
4. tw api 港卡有问题开不通了(所以o-ai 的空投一直暂停)
链上数据还没整理好.
5. 计划修改接入多家交易所(还需要构思下细节).
6. 新闻目前采集了币安、巴比特、华尔街见闻、路透社、金色财经还有国内十几个做低权重参考，有什么新闻站推荐欢迎告知.
接前面底座模式的介绍，等理顺畅开源python端
1. 两端完全独立，python端直接启动也是功能一样，不用做任何修改独立运行的命令行界面.
2. 如果启动UI端，就会如下图界面显示.
#web3 #meme #撸毛
2
5
1,356
合约交易自动驾驶机器人
上一篇写了一个开源底座， 今天就用一天时间来写个用户友好的AI 合约交易机器人组成第一个工具雏形， 顺带讲下原理，欢迎共识之士交流。
为什么称为自动驾驶，只是为了方便快速理解我这款工具当前的思路。 通常自动驾驶主要有个三个主要模块，称三驾马车。
1.外界感知层：摄像头，雷达等
2.算法决策层：根据感知建模分析，确定操作命令
3.命令控制层: 根据决策，执行 油门，刹车，方向等
同理 AI 交易机器人：
外界感知层（最近造了太多底座，下面描述的都也造七七八八，等合并调优了）：
●实时市场数据：当前价格、24小时涨跌幅、资金费率、持仓量等
●多周期K线数据：5分钟、15分钟、1小时、4小时、1天等多个时间周期的K线
●技术指标：RSI、MACD、EMA、SMA、布林带、ATR等
●监控推特信息，分多块，但主要2块(监控指定一批kol,根据搜索结果)
●监控平台消息，如华尔街见闻 ，博社，路透社.，雅虎财经，国内主流平台等(中文社区的FOMO情绪可能先于外媒反应)
●监控交易所上币，新闻，公告
●链上数据
算法决策层：
●资金管理
●目前直接用deepseek这类api，抽取上一层的数据即时分析。也同样有训练底座，本地可以秒分析，模型迭代很快，成熟了逐渐调优，延迟在快速变化的市场中是致命问题。
●多数时间应都是要花在调整策略与提示词了，支持直接策略脚本，与提示词
●写一个mcp，来对接ai跟 交易所
命令控制层:
决策层已经生成好命令了，直接调用api即可，分层是为了调优追踪开单成功率。
三驾马车描述完了，其实还有重要的三个，方便速记，那就叫两个中心一个基本点吧。
风控层（中心）：
分离式独立出来， 像车自动驾驶的风控只能是放到决策层，因为意外情况你能怎么办呢？刹车也可能是最坏的操作，但是我们交易不同，随时可以立即终止，比如舆情突发，黑天鹅，ai决策也连续误判等，因此妥妥放到顶层设计，简单粗暴，方便调优。
监控运维层（中心）:
同样放到顶层，用来监控全链路健康，比如那些采集服务器中断，AI模型漂移，MCP下单成功率，风控是否工作正常等，及时推送消息。
反馈学习与策略优化层（基本点）
都这个时代了，个人英雄玩不转了，那就协同来优化
●记录每笔交易的完整上下文
●分析盈利/亏损交易的模式特征
●计算策略在不同市场环境下的表现指标
●用新的交易数据微调本地模型
●协助优化决策提示词模板
●生成和测试新的交易策略
●回测所有数据，让AI又来分析结果给我们汇报，最后自我进化成擎天柱吧
入行不久，抛转引玉
有什么可以抄作业的地方，请留言告诉我， 让我走别人的路，让别人打车去吧。
#web3 #meme
github.com/CodeNightOwl/delp…
Delphi-Python 共享内存双向微秒级通信项目
开发动机
Python 和 Golang 在界面开发方面存在明显短板，而对于普通用户而言，要求其配置环境、使用命令行操作是反人类的体验——正常的解决方案应该是直接交付可执行的 EXE 文件，所以我们可以python来开发功能，Delphi来开发界面(还可以动态执行python脚本)。
Delphi 能够在短时间内开发出大型 ERP 系统界面，更不用说小型工具了。尽管常被认为是一门"过时"的语言，主要依靠销售 IDE 盈利，但它仍能长期稳居编程语言排行榜前十左右。
设计思路可扩展到其他语言组合，选择 Python 是因为其生态丰富（例如需要对接 150 个交易所通讯的场景，无需重复造轮子），ai编程对他来说支持也是最好的，Delphi这种依赖IDE又稍偏门的语言你用Ai跑一个晚上早上醒来他执行几百次都不对的时候，可能自己几分钟写出来了。
因为我现在需要做高频交易，所以对延迟有严格的要求，不说需要多快，只能说能快就快。
性能要求
微秒级通信延迟是针对高频交易场景的硬性需求，需要实时响应和处理交易指令。Delphi 自身能够实现 C 语言的性能，部分核心模块也可直接用 Delphi 开发。
独立运行
用Python4Delphi 虽然能执行python脚本，但独立性不足，且 Python 的版本管理和包依赖处理较为复杂。而本方案中：
Python 端打包为独立 EXE
Delphi 端编译为独立 EXE
除通信接口外，双方完全隔离开发，无耦合依赖
Delphi 通过创建进程方式启动 Python 可执行文件（如将 Python EXE 嵌入 Delphi 资源，则可实现单文件部署）
传输协议性能对比
通信方式典型延迟RESTful API5-10msWebSocket约 5msgRPC约 3mszeroMq毫秒级(如果局域网可选择)命名管道毫秒级共享内存微秒级
核心技术要点
序列化选择
重要提示：切勿使用 JSON 进行数据传输！切勿使用 JSON 进行数据传输！切勿使用 JSON 进行数据传输！ JSON 的编码解码效率极低，使用后将无法实现微秒级性能，毫秒级保证不了。
MessagePack 采用二进制序列化，效率显著更高。对于交易所 API 通常使用 JSON 的情况，Python 的字典结构天然兼容 JSON 和 MessagePack，我们只需在传输时进行一次序列化转换即可。
性能优化：
Python 的 JSON 序列化使用 orjson（底层由 Rust 实现，效率极高）
Python 的 MsgPack 序列化使用 (底层由 C 实现 )
可突破 GIL限制，结合语言特性实现极致速度
双向通信机制
Python → Delphi 方向
Python 向 Python 写区（PYTHON_WRITE_OFFSET）写入数据
Python 发送通知给 Delphi
Delphi 从 Python 写区（PYTHON_WRITE_OFFSET）读取数据
Delphi → Python 方向
Delphi 向 Delphi 写区（DELPHI_WRITE_OFFSET）写入数据
Delphi 发送通知给 Python
Python 从 Delphi 写区（DELPHI_WRITE_OFFSET）读取数据
系统架构特点
共享内存双向通信 + 事件通知 + MessagePack 封装 + 线程池优先级执行任务，专为高速数据交换场景优化设计。
技术优势
极致性能：基于 Windows 共享内存，彻底消除网络延迟
全双工通信：Delphi 和 Python 可同时互相发送和接收数据，支持实时事件通知
低延迟响应：微秒级响应时间，基于事件驱动机制
共享内存设计
总内存大小：400MB（可根据实际需求调整）
分区策略：Python 写区：0-199MB（200MB 容量）
Delphi 写区：200-399MB（200MB 容量）
编码格式：MsgPack 二进制序列化
事件通知：基于 Windows 事件对象的双向通知机制
消息格式：4 字节消息长度头 + MsgPack 序列化数据
线程池设计
线程数：根据 CPU 核心数动态调整（默认值为核心数）
任务队列：无界队列，支持高并发任务提交
任务优先级：根据任务类型（如实时事件、普通消息）分配不同优先级，确保关键任务及时处理
项目编译
Delphi：使用 Delphi 10.3 或更高版本编译
Python：使用 Python 3.10 或更高版本编译
测试程序
启动 Python 端 main.py (必须先启动)
启动 Delphi 端
启动 发送给delphi队列性能验证.py 可以测试批量发送给delphi的性能
点击 delphi 界面按钮，发送给main.py的消息，main.py会收到并打印在控制台上
视频中python端提示“网络延迟” 是笔误，内存通讯，没有网络， 时间是内存写入+事件通知+messagePack解包的总时间。
#web3 #meme
3
1,450
