尧图网站建设 
Kuru 链上订单簿是什么jev-trader 如何读取 MON-USDC 实时盘口getL2Book 完全解析【免费下载链接】jev-traderOne AI trade decision every Monad block. Jev on Kuru MON-USDC.项目地址: https://gitcode.com/gh_mirrors/je/jev-traderjev-trader是一个跑在 Monad 公链上的 AI 交易机器人它每 300ms 一个区块读取一次 Kuru 交易所的 MON-USDC 链上订单簿order book让 AI 做出买或卖的一个决策并立刻挂出一张 post-only 限价单。整条热路径上只发生两次 RPC 往返核心就是本次主角getL2Book()一次eth_call拿回整本盘口。下面带你完整解析 Kuru 链上订单簿是什么、盘口数据长什么样、以及 jev-trader 如何用最少的往返把它读成模型能用的实时报价。一、Kuru 链上订单簿是什么Kuru 是 Monad 链上的一台链上交易所每个交易对比如 MON-USDC对应一个市场合约买卖盘口直接保存在链上状态里任何人通过一次eth_call就能读到当前最新的盘口这就是链上订单簿on-chain order book的含义。与传统中心化交易所相比它有三个鲜明特点特点说明盘口在链上报价就是合约存储里的状态无需信任任何服务器读取零成本eth_call是模拟调用不花 gas不产生交易与出块同频Monad 出块约 300ms盘口理论上每秒变化 3 次以上jev-trader 盯上的正是 Kuru 的 MON-USDC 市场合约地址在 src/config.ts 中写死MARKET环境变量可覆盖。项目文档 README.md 一句话概括了这个玩法一个 AI 交易决策每 Monad 区块一次。二、getL2Book一次 eth_call 拿到整本盘口Kuru 市场合约提供了一个只读函数getL2Book()函数选择器selector为0x46fdfbb1见 src/book.ts。jev-trader 不走 ethers 封装而是直接对公共 RPC 发起最原始的 JSON-RPC 请求方法eth_call目标MON-USDC 市场合约数据0x46fdfbb1区块标签latest返回的是一段 ABI 编码的字节流。为什么不直接用 Kuru 官方 SDK因为 SDK 的getFormattedL2OrderBook会串行发两次eth_call先getL2Book再对返回区块发getVaultParams用来合并 Kuru AMM 金库的报价。而在 MON-USDC 上AMM 金库的挂单量恒为 0第二次调用纯属浪费延迟。于是 jev-trader 在 src/book.ts 里自写了读取器readBook()默认只发一次eth_call公共 RPC 上实测约18ms返回整本盘口。这一个数字直接决定了每 300ms 一个决策是否放得下盘口读取只占热路径的一小部分详见第五节。三、解码盘口getL2Book 返回的数据结构getL2Book()的返回值是一个 ABI 编码的bytesjev-trader 的解码流程在 src/book.ts 的decodeL2Book中可以拆成三步剥开 ABI 外壳前两个 32 字节分别是偏移量和长度之后才是真正的有效载荷abiBytesPayloadsrc/book.ts。读出区块号载荷的前 32 字节是出这个盘口的区块高度保证数据属于哪一块链上状态可追溯。成对读取盘口档位之后每 64 字节一对先是价格、再是数量uint256 整数读到价格为 0时表示本侧结束接着读另一侧。买盘bids和卖盘asks各读一遍。整数档位再经过一层整形核心规则在 src/book.ts 的formatLevels价格先按市场精度转成小数toFloatsrc/book.ts买盘价格向下取整到 tick卖盘价格向上取整到 tick避免挂单意外交叉同一价格的多档合并累加与官方 SDK 的输出逐位对齐这是刻意为之保证自写读取器和 SDK 算出的 mid、spread、imbalance 完全一致。最终buildBooksrc/book.ts把原始档位压缩成模型真正消费的几个指标字段含义bid/ask/mid最优买价、最优卖价、中间价spreadBps价差以基点计例7.07 bps 0.0707%imbalance中间价 1% 范围内买卖深度差取值 -1 到 1levels买卖两侧各前 5 档[价格, 数量]depthBps中间价 ±10/25/50 bps 内的累计深度四、AMM 金库什么时候才需要第二次调用Kuru 盘口里藏着一个备胎AMM 金库vault通过另一个函数getVaultParams()selector0x88bb4f60读取。当金库激活vaultBidOrderSize非零且金库地址非零地址判断逻辑见 src/book.ts时它的报价要按等比数列逐级展开成一条AMM 阶梯与 L2 盘口档位合并ammLevelssrc/book.ts。jev-trader 的取舍很克制热路径默认不发getVaultParams每 200 个区块在热路径之外抽查一次src/trader.ts只有确认金库激活才把两个调用打包进同一个 JSON-RPC 批处理一次 HTTP 往返拿到两份数据延迟增量几乎为零。这套精确性 延迟双指标可以用仓库自带的基准脚本随时验证scripts/bench-read.ts自写读取器 vs 官方 SDK逐区块对比精确匹配率和延迟分布scripts/probe-book.ts连读 3 次盘口并打印参数快速摸一下线上数据scripts/dry-encode.ts离线验证下单 calldata 与 SDK 编码完全一致。五、盘口如何变成 300ms 内的一个交易决策读盘口的意义在于喂给决策循环。整个循环在 src/trader.ts 的onBlock中每个区块做三件事market.readBook()读盘口src/market.ts一次eth_call约 18ms把盘口指标 最近 400 个 mid 序列交给模型模型回答 buy 或 sell按决策挂单价格选在对手侧最优价向内 1 个 tick的位置quotePricesrc/market.tsspread 太窄时自动贴回 touch永不交叉然后eth_sendRawTransaction发出。预算怎么算的300ms 区块内只有两次 RPC读盘口 ~18ms 发交易RPC 收到 hash 即返回。没有estimateGasMonad 按 gas limit 收费limit 启动时算一次就写死、没有同步等待回执、没有 gas 价查询静态 type-2 费用。官方 README 给出的实测读盘口 p50 18ms整个循环 p50 100ms。回执、成交别人的 taker 单砸中我们挂着的 maker 单经eth_getLogs的 Trade 日志得知都在后续区块异步处理不占用热路径。六、快速上手三步跑通盘口读取仓库只读可在线浏览想本地跑起来的话git clone https://gitcode.com/gh_mirrors/je/jev-trader cd jev-trader bun install bun run scripts/probe-book.ts # 打印市场参数 3 次盘口读取延迟不带PRIVATE_KEY时机器人以 dry-run 运行真实盘口、真实决策、模拟成交见 README.md。想对比自写读取器和 SDK 的延迟与精确性执行bun run scripts/bench-read.ts。七、FAQ关于 Kuru 盘口读取的三个疑问Q1getL2Book 返回的是最新数据吗是latest区块状态且返回值里自带区块号消费端可以做新鲜度校验。jev-trader 每次循环都用当次读到的盘口挂单区块过期就丢弃重来。Q2自己解码而不依赖 SDK值得吗值得。省掉的是串行第二次eth_call的一整个 RTT付出的代价是必须和 SDK 保持逐位一致。仓库用bench-read.ts把同区块精确匹配率 100%变成了可回归的测试。Q3spreadBps 和 imbalance 分别提示什么spreadBps决定挂单空间价差窄到放不下一个 tick 时就贴 touch 挂imbalance是盘口压力指标接近 1 说明买侧深度占优两者都会进入模型输入。小结Kuru 链上订单簿的本质是用一次eth_call即可读取的链上状态jev-trader 通过手写getL2Book解码器把读取压缩到单次往返~18ms再配合 tick 对齐、深度与不平衡指标让每 300ms 一个真实决策在 Monad 的出块节奏内稳稳落地。核心源码都集中在 src/book.ts盘口读取与解码、src/market.ts下单与确认和 src/trader.ts决策主循环配合 scripts/ 目录下的探针脚本可以完整复现本文的每一步。【免费下载链接】jev-traderOne AI trade decision every Monad block. Jev on Kuru MON-USDC.项目地址: https://gitcode.com/gh_mirrors/je/jev-trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kuru 链上订单簿是什么？jev-trader 如何读取 MON-USDC 实时盘口（getL2Book 完全解析）
Kuru 链上订单簿是什么jev-trader 如何读取 MON-USDC 实时盘口getL2Book 完全解析【免费下载链接】jev-traderOne AI trade decision every Monad block. Jev on Kuru MON-USDC.项目地址: https://gitcode.com/gh_mirrors/je/jev-traderjev-trader是一个跑在 Monad 公链上的 AI 交易机器人它每 300ms 一个区块读取一次 Kuru 交易所的 MON-USDC 链上订单簿order book让 AI 做出买或卖的一个决策并立刻挂出一张 post-only 限价单。整条热路径上只发生两次 RPC 往返核心就是本次主角getL2Book()一次eth_call拿回整本盘口。下面带你完整解析 Kuru 链上订单簿是什么、盘口数据长什么样、以及 jev-trader 如何用最少的往返把它读成模型能用的实时报价。一、Kuru 链上订单簿是什么Kuru 是 Monad 链上的一台链上交易所每个交易对比如 MON-USDC对应一个市场合约买卖盘口直接保存在链上状态里任何人通过一次eth_call就能读到当前最新的盘口这就是链上订单簿on-chain order book的含义。与传统中心化交易所相比它有三个鲜明特点特点说明盘口在链上报价就是合约存储里的状态无需信任任何服务器读取零成本eth_call是模拟调用不花 gas不产生交易与出块同频Monad 出块约 300ms盘口理论上每秒变化 3 次以上jev-trader 盯上的正是 Kuru 的 MON-USDC 市场合约地址在 src/config.ts 中写死MARKET环境变量可覆盖。项目文档 README.md 一句话概括了这个玩法一个 AI 交易决策每 Monad 区块一次。二、getL2Book一次 eth_call 拿到整本盘口Kuru 市场合约提供了一个只读函数getL2Book()函数选择器selector为0x46fdfbb1见 src/book.ts。jev-trader 不走 ethers 封装而是直接对公共 RPC 发起最原始的 JSON-RPC 请求方法eth_call目标MON-USDC 市场合约数据0x46fdfbb1区块标签latest返回的是一段 ABI 编码的字节流。为什么不直接用 Kuru 官方 SDK因为 SDK 的getFormattedL2OrderBook会串行发两次eth_call先getL2Book再对返回区块发getVaultParams用来合并 Kuru AMM 金库的报价。而在 MON-USDC 上AMM 金库的挂单量恒为 0第二次调用纯属浪费延迟。于是 jev-trader 在 src/book.ts 里自写了读取器readBook()默认只发一次eth_call公共 RPC 上实测约18ms返回整本盘口。这一个数字直接决定了每 300ms 一个决策是否放得下盘口读取只占热路径的一小部分详见第五节。三、解码盘口getL2Book 返回的数据结构getL2Book()的返回值是一个 ABI 编码的bytesjev-trader 的解码流程在 src/book.ts 的decodeL2Book中可以拆成三步剥开 ABI 外壳前两个 32 字节分别是偏移量和长度之后才是真正的有效载荷abiBytesPayloadsrc/book.ts。读出区块号载荷的前 32 字节是出这个盘口的区块高度保证数据属于哪一块链上状态可追溯。成对读取盘口档位之后每 64 字节一对先是价格、再是数量uint256 整数读到价格为 0时表示本侧结束接着读另一侧。买盘bids和卖盘asks各读一遍。整数档位再经过一层整形核心规则在 src/book.ts 的formatLevels价格先按市场精度转成小数toFloatsrc/book.ts买盘价格向下取整到 tick卖盘价格向上取整到 tick避免挂单意外交叉同一价格的多档合并累加与官方 SDK 的输出逐位对齐这是刻意为之保证自写读取器和 SDK 算出的 mid、spread、imbalance 完全一致。最终buildBooksrc/book.ts把原始档位压缩成模型真正消费的几个指标字段含义bid/ask/mid最优买价、最优卖价、中间价spreadBps价差以基点计例7.07 bps 0.0707%imbalance中间价 1% 范围内买卖深度差取值 -1 到 1levels买卖两侧各前 5 档[价格, 数量]depthBps中间价 ±10/25/50 bps 内的累计深度四、AMM 金库什么时候才需要第二次调用Kuru 盘口里藏着一个备胎AMM 金库vault通过另一个函数getVaultParams()selector0x88bb4f60读取。当金库激活vaultBidOrderSize非零且金库地址非零地址判断逻辑见 src/book.ts时它的报价要按等比数列逐级展开成一条AMM 阶梯与 L2 盘口档位合并ammLevelssrc/book.ts。jev-trader 的取舍很克制热路径默认不发getVaultParams每 200 个区块在热路径之外抽查一次src/trader.ts只有确认金库激活才把两个调用打包进同一个 JSON-RPC 批处理一次 HTTP 往返拿到两份数据延迟增量几乎为零。这套精确性 延迟双指标可以用仓库自带的基准脚本随时验证scripts/bench-read.ts自写读取器 vs 官方 SDK逐区块对比精确匹配率和延迟分布scripts/probe-book.ts连读 3 次盘口并打印参数快速摸一下线上数据scripts/dry-encode.ts离线验证下单 calldata 与 SDK 编码完全一致。五、盘口如何变成 300ms 内的一个交易决策读盘口的意义在于喂给决策循环。整个循环在 src/trader.ts 的onBlock中每个区块做三件事market.readBook()读盘口src/market.ts一次eth_call约 18ms把盘口指标 最近 400 个 mid 序列交给模型模型回答 buy 或 sell按决策挂单价格选在对手侧最优价向内 1 个 tick的位置quotePricesrc/market.tsspread 太窄时自动贴回 touch永不交叉然后eth_sendRawTransaction发出。预算怎么算的300ms 区块内只有两次 RPC读盘口 ~18ms 发交易RPC 收到 hash 即返回。没有estimateGasMonad 按 gas limit 收费limit 启动时算一次就写死、没有同步等待回执、没有 gas 价查询静态 type-2 费用。官方 README 给出的实测读盘口 p50 18ms整个循环 p50 100ms。回执、成交别人的 taker 单砸中我们挂着的 maker 单经eth_getLogs的 Trade 日志得知都在后续区块异步处理不占用热路径。六、快速上手三步跑通盘口读取仓库只读可在线浏览想本地跑起来的话git clone https://gitcode.com/gh_mirrors/je/jev-trader cd jev-trader bun install bun run scripts/probe-book.ts # 打印市场参数 3 次盘口读取延迟不带PRIVATE_KEY时机器人以 dry-run 运行真实盘口、真实决策、模拟成交见 README.md。想对比自写读取器和 SDK 的延迟与精确性执行bun run scripts/bench-read.ts。七、FAQ关于 Kuru 盘口读取的三个疑问Q1getL2Book 返回的是最新数据吗是latest区块状态且返回值里自带区块号消费端可以做新鲜度校验。jev-trader 每次循环都用当次读到的盘口挂单区块过期就丢弃重来。Q2自己解码而不依赖 SDK值得吗值得。省掉的是串行第二次eth_call的一整个 RTT付出的代价是必须和 SDK 保持逐位一致。仓库用bench-read.ts把同区块精确匹配率 100%变成了可回归的测试。Q3spreadBps 和 imbalance 分别提示什么spreadBps决定挂单空间价差窄到放不下一个 tick 时就贴 touch 挂imbalance是盘口压力指标接近 1 说明买侧深度占优两者都会进入模型输入。小结Kuru 链上订单簿的本质是用一次eth_call即可读取的链上状态jev-trader 通过手写getL2Book解码器把读取压缩到单次往返~18ms再配合 tick 对齐、深度与不平衡指标让每 300ms 一个真实决策在 Monad 的出块节奏内稳稳落地。核心源码都集中在 src/book.ts盘口读取与解码、src/market.ts下单与确认和 src/trader.ts决策主循环配合 scripts/ 目录下的探针脚本可以完整复现本文的每一步。【免费下载链接】jev-traderOne AI trade decision every Monad block. Jev on Kuru MON-USDC.项目地址: https://gitcode.com/gh_mirrors/je/jev-trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考