BSC 自动化做市机器人项目白皮书（商家版）

面向合作伙伴、渠道方与专业用户的正式介绍文档
版本：v1.0（基于当前项目实现）

一、项目定位与价值主张

我们推出的这套 BSC 自动化做市机器人，不是“概念型脚本”，而是一套可长期运行、可持续迭代、可运营复盘的交易执行系统。
项目围绕 BNB Chain 生态构建，聚焦三个核心问题：执行效率、系统稳定性、数据沉淀能力。

在链上环境中，策略优劣只是结果的一部分，执行层的质量往往决定了上限。我们在项目设计上坚持工程化原则，通过标准化配置、服务化架构、任务调度、数据持久化与日志体系，让交易行为从“人工操作”升级为“系统运营”。

我们坚持的原则

• 不夸大收益，不承诺不可控结果。
• 不做短期情绪营销，强调长期系统能力。
• 以可验证的技术实现为核心交付。
• 支持后续扩展，不把用户锁死在单一玩法上。

二、项目总体架构

当前项目采用分层式架构，整体可以归纳为：配置层 -> 服务上下文层 -> 数据层 -> 业务服务层 -> 路由接口层 -> 基础设施层。

1）启动与调度入口

主入口位于 cmd/main.go，启动顺序具备清晰职责分工：

1. 加载服务上下文（配置、日志、数据库、缓存、模型）
2. 启动钱包监听服务（Wallet Watch）
3. 启动任务相关服务（价格监听、任务初始化）
4. 启动 HTTP 服务并对外提供接口能力

这意味着系统具备“交易逻辑 + 接口服务”双重属性，既可自动运行，也可被后台控制调用。

2）配置中心

配置文件位于 config/app.yaml，可统一管理：

• 服务端地址与模式（server.host、server.port、server.mode）
• 日志路径、名称与级别（log.path、log.name、log.level）
• 数据库类型与连接（db.type、db.dns）
• 管理账号（account.username、account.password）
• 链上 RPC 节点（bnbchain.rpc.https、bnbchain.rpc.wss）
• 运行密钥（key）

通过配置解耦，项目可快速适配测试环境、预发布环境与生产环境。

3）服务上下文（ServiceContext）

internal/server/svc/servicecontext.go 负责依赖装配，统一注入：

• DB 连接实例（GORM）
• Cache 客户端
• 各业务 Model 实例

这一层相当于系统“依赖容器”，保证业务模块调用一致、便于维护和扩展。

4）数据访问层（DB + Model）

数据层以 GORM 为核心，支持两类存储形态：

• sqlite（默认，轻量快速部署）
• mysql/clickhouse（配置切换扩展）

系统启动时执行 AutoMigrate 自动迁移，确保核心表结构可用，降低初始化门槛。

主要数据实体覆盖：

• 钱包信息
• 任务配置
• 交易日志
• 交易记录
• 地址记录
• BNB 相关扩展数据模型（Data Wallet / Task / TradeLog / Swap / PnL）

5）业务服务层（BSC Domain Services）

业务核心位于 internal/server/service/bnbchain，按能力拆分为：

• wallet：钱包监听、余额相关处理、归集能力
• task：任务初始化、执行逻辑、价格监听、策略流程
• bnbchainrpc：链上余额、签名、转账、价格等 RPC 交互封装
• common：通用服务能力与复用逻辑

从命名与职责看，该层已经具备“按领域组织代码”的基础，便于继续扩充策略模块。

6）交易执行与 DEX 适配层

交易相关实现位于 internal/server/swap/bnbchain，当前可见能力包括：

• PancakeSwap V2 适配（报价、路由、合约调用）
• PancakeSwap V3 适配（Quoter、Factory、Pool、Router）
• FourMeme 模块相关合约适配能力
• 统一 swap 抽象入口

这一层的意义在于把链上协议细节“收敛到适配层”，上层业务不需要直接接触过多合约细节。

7）路由与接口层

HTTP 服务基于 Gin，路由位于 internal/server/router，当前包含：

• 登录认证相关能力（JWT）
• 钱包相关接口
• 交易相关接口
• 任务相关接口
• 中间件（CORS、鉴权）

并且项目已包含前端静态资源目录，具备“后台 UI + API”一体化运行基础。

8）运行与生命周期管理

internal/server/server.go 实现了标准 HTTP Server 生命周期管理：

• 读写超时设置
• 优雅关闭（os.Interrupt）
• 独立文件服务协程

这使项目在生产部署中的可控性明显优于临时脚本。

三、技术栈明细（基于当前代码）

1）语言与基础框架

• Go 1.22.x
• Gin（Web API）
• Logrus（日志）
• YAML 配置解析

2）链上交互与交易相关

• go-ethereum（EVM 链交互）
• Pancake V2 / V3 合约调用封装
• 多 RPC 节点接入（HTTPS / WSS）

3）数据层技术

• GORM（ORM）
• SQLite（默认，已采用 github.com/glebarez/sqlite 纯 Go 驱动）
• ClickHouse/MySQL 扩展入口（按配置分支）

4）认证与安全

• JWT 令牌机制（登录态管理）
• 鉴权中间件（接口访问控制）
• 密钥参数配置化管理（key）

5）工程可运维能力

• 自动建表（AutoMigrate）
• 日志目录与级别可配置
• 可跨平台构建与部署
• 模块化目录结构，便于团队协作

四、核心功能清单（详细）

以下功能为当前项目中可识别的核心业务能力：

A. 钱包体系能力

• 钱包监听与状态维护
• 钱包余额读取能力
• 钱包归集流程相关能力
• 地址记录及关联数据持久化

B. 任务体系能力

• 任务初始化（系统启动后自动加载）
• 价格监听（例如 BNB/USDC 相关观察逻辑）
• 任务执行调度（不同策略任务分模块实现）
• 洗量、拉升、砸盘等任务流程化组织（由任务模块命名可见）

C. 交易执行能力

• DEX 协议差异封装（V2/V3）
• 买卖交易调用路径抽象
• 交易日志写入与复盘支撑
• 滑点、报价、路由等执行参数处理

D. 数据分析与沉淀能力

• 交易记录（Transaction）沉淀
• 交易日志（TradeLog）沉淀
• 任务维度数据沉淀（TaskConfig）
• 扩展数据模型（Swap / PnL 等）支持后续运营分析

E. 接口与后台能力

• 登录鉴权
• 钱包管理接口
• 交易管理接口
• 任务配置与任务操作接口
• 静态资源服务（便于后台管理页面集成）

五、部署与运维建议

1）最小可用部署路径

1. 配置 config/app.yaml（节点、账号、数据库、端口）
2. 确认 db.type 与 db.dns
3. 启动服务，自动建表
4. 通过接口或后台进行任务管理与状态观察

2）生产建议

• 使用稳定的 RPC 服务商，避免单点节点质量波动。
• 对关键日志目录做持久化与轮转策略。
• 为数据库文件/实例配置定期备份策略。
• 将策略参数配置化，避免直接改代码上线。
• 对交易相关接口增加调用审计与操作权限控制。

3）可扩展方向

• 多链扩展（抽象链适配层）
• 风控引擎（限额、限频、异常熔断）
• 任务编排中心（可视化策略流程）
• 指标监控与告警（Prometheus/Grafana）
• 多租户后台与权限体系

六、为什么这套系统更适合长期业务

和“脚本化机器人”相比，这套项目更适合团队化运作，原因在于：

• 有明确架构边界，而非代码堆叠。
• 有数据沉淀与日志系统，可复盘、可审计。
• 有 API 与后台基础，便于运营协同。
• 有协议适配层，支持后续交易能力扩展。
• 有依赖注入和模型层，便于多成员并行开发。

简单说，我们交付的不只是“自动下单”，而是“可运营的自动化交易系统底座”。

七、合作场景与客户价值

适配客户类型

• 个人技术交易者（需要稳定执行系统）
• 小型量化团队（需要标准化流程）
• 代理/工作室（需要可交付的系统基础）
• 技术服务商（需要二次开发底座）

可量化价值（建议口径）

• 降低人工盯盘与操作成本
• 提升执行一致性与时效性
• 增强交易行为可追踪性
• 缩短从策略到落地的工程周期

八、风险提示与合规声明

我们始终坚持负责任的商业表达。请在推广、部署与使用时，明确以下原则：

• 本系统用于技术研究、系统建设与合规场景实践。
• 不构成收益承诺，不构成投资建议。
• 数字资产交易存在高风险，用户需独立决策并承担风险。
• 应严格遵守所在地法律法规及平台规则。

九、结语（商家承诺）

我们理解，真正做长期业务的客户，最看重的是稳定、可维护、可扩展，而不是短期噱头。
因此，我们以工程标准构建这套系统，以专业服务能力支撑后续迭代。

如果您需要，我们可以进一步提供：

• 面向渠道方的简版商务材料
• 面向终端客户的功能说明手册
• 面向技术团队的部署与二开规范

欢迎以“长期合作、技术共建”的方式推进项目落地。我们愿意用专业和诚意，帮助您把自动化交易系统做深、做稳、做长久。