跨链兑换安全模型 — 非托管 / 零授权架构
非托管 + 零授权 + 链上不可逆 = 没有可被攻击的资金面
核心原则
UpSwap 在任何时间均不持有用户资产 (non-custodial)。我们不是托管方,不是清算方,也不是结算方 — 我们只是帮用户找最优报价的路由层。
传统中心化交易所 (CEX) 的安全模型建立在 "信任运营方" 之上 — 黑客攻破热钱包 (hot wallet) = 用户资产全部损失。UpSwap 的安全模型反过来:我们的服务器根本不存在可被攻击的资金面 (attack surface for funds)。
即使 UpSwap 的服务器、域名、Cloudflare Worker 被完全攻陷 (fully compromised),攻击者也拿不到任何一笔用户资金 — 因为我们的代码路径里根本不经手资产。
| 维度 | CEX 集中托管 | 传统 DEX swap | UpSwap |
|---|---|---|---|
| 资产托管 | 平台热钱包 | 用户钱包 | 用户钱包 |
| token approval | 不适用 | 需要无限授权 (infinite approval) | 不需要 approval |
| 黑客攻破服务器 | 资金全损 | 影响有限 | 资金零损失 |
| 可被钓鱼利用 | 假登录页 | 假 approval 弹窗 | 仅可骗用户填错地址 |
资金流向
下面是一笔典型跨链兑换中,资金、地址、签名分别流经哪些环节 — 注意 UpSwap 出现的位置和不出现的位置。
- Step 1 · 报价 (Quote) — 用户在 widget 输入金额/币种/收款地址,UpSwap 向上游路由网络 (liquidity vendors) 请求报价,返回 "您将收到 X" 一口价。此时资金尚未离开用户钱包,UpSwap 只是中间的查询层。
- Step 2 · 用户在自己的钱包发起 send → 一次性 deposit address (由上游供应商根据本笔订单生成)。资金从用户钱包直接上链到 deposit address — 不经过 UpSwap 任何服务器、不经过任何中间账户。
- Step 3 · 上游供应商监听到入账 → 执行跨链 swap (源链卖出 / 目的链买入,或通过原子互换)。整个过程在链上 + 上游网络内完成,UpSwap 不参与签名、不参与撮合。
- Step 4 · 输出代币由上游供应商直接 send 到用户填写的收款地址。用户钱包收到资产,订单结束。UpSwap 在这一步只是从 vendor 的状态接口拿到 "已完成" 然后更新 widget UI。
总结:UpSwap 出现在 Step 1 之前(报价查询),之后所有真金白银的流转都在 "用户钱包 ↔ 链 ↔ 上游路由网络" 之间,我们既无私钥、也无中转账户、也无 approval 权限。
防重放设计
UpSwap 对每一个报价 (quote) 都签发一个 HMAC-SHA256 签名的 quoteId,确保用户拿到的报价无法被篡改、无法被重复消费、也无法被反推出上游供应商身份。
- payload 极简:quoteId 内部只编码
{nonce, issuedAt}两个字段 — 没有价格、没有路由信息、没有 vendor 标识。客户端即使解码 quoteId 也看不出我们这一笔走的是哪家上游。 - HMAC 签名:服务端用 Worker 环境变量中的 secret 对 payload 做 HMAC-SHA256,任何篡改 nonce 都会导致签名校验失败 (401)。
- nonce 单次消费:nonce 在 Cloudflare KV 中以 TTL 短期存储,确认订单时执行
KV.delete(nonce),删除后同一个 quoteId 无法再被使用 — 杜绝重放攻击 (replay attack)。 - 有效期 ≤ 30 秒:
issuedAt超时的 quoteId 直接拒绝,即使签名合法也不放行,缩小被滥用窗口。
隐私即安全
我们认为 "不收集" 是最强的数据保护 — 没有数据库,就没有可被拖库的内容 (no DB to dump)。
- 零账户体系:无注册、无邮箱 (email)、无电话、无密码、无 KYC 文件 — 我们不知道你是谁。
- 零私钥接触:UpSwap 任何代码路径都不读取、不传输、不存储用户私钥或助记词 (seed phrase)。
- 最小化日志:IP 地址用于反滥用 (anti-abuse),14 天后自动删除;订单元数据 (订单 ID / 金额 / 时间) 6 个月后删除。
- 无第三方追踪:无 Google Analytics、无 Meta Pixel、无任何用于广告归因的脚本。
副作用:即使监管机构、执法部门发函要求 "提供用户 A 的交易历史",我们也确实没有可交付的数据 — 不是不配合,是真的不存在。
传输与存储
- HTTPS-only:全站强制 TLS 1.3,HSTS
max-age=31536000; includeSubDomains; preload(1 年),已提交至 Chrome HSTS preload list。 - HTTP/3 ready:Cloudflare 边缘节点默认启用 QUIC + HTTP/3,降低首字节时延 (TTFB)。
- Worker secrets:所有上游 API key、HMAC secret 通过
wrangler secret put加密存储,代码里不出现明文,git 仓库里也不存在.env。 - KV 跨 PoP 复制:nonce 数据由 Cloudflare KV 在全球边缘节点复制,故障域分散 — 但敏感字段从不下发到客户端。
- 客户端零敏感数据:浏览器 localStorage 仅缓存 UI 偏好 (主题/语言),无 token、无 session、无 PII。
CORS 与中间件
UpSwap widget 设计为可被第三方网站嵌入 (embeddable),因此 API 必须开放 CORS。我们用一组中间件策略防止 "开放 CORS" 退化为 "开放滥用"。
- 通配 CORS + noindex:
/api/*返回Access-Control-Allow-Origin: *同时挂X-Robots-Tag: noindex,允许跨域调用但禁止搜索引擎索引接口。 - 大小写防护:中间件对 path 做
toLowerCase后再路由,防止/API/Quote这类绕过尝试。 - 异常时仍带 CORS header:即使后端 catch 到异常返回 5xx,中间件也会保证 CORS header 存在,避免嵌入站点拿不到错误信息只能盲猜。
- 速率限制 (rate limit):基于 IP + endpoint 的滑动窗口限流,防止脚本爆破 nonce。
第三方依赖与审计
UpSwap 的代码本身没有自有智能合约 (no proprietary smart contract) — 我们是一个 Astro + React 前端 + Cloudflare Worker 边缘代理。因此不存在 "合约审计" 这一项需求。真正承担资金流转的,是上游路由网络与跨链桥。
- 上游供应商均有独立第三方审计:我们接入的每一家上游流动性供应商都已通过头部安全机构的独立审计 (independent audit)。出于商业机密,我们不在公开页面点名具体供应商;同样地,为避免误导用户,我们不在此处具名列出审计机构,以免被理解为"UpSwap 自身被这些机构审计过"——UpSwap 没有自有智能合约,不存在 UpSwap 自身的审计需求。
- npm 依赖监控:使用 Renovate 自动跟踪依赖升级,Socket.dev 实时扫描供应链投毒 (supply chain attack),CVE 高危补丁通常在 24 小时内合并。
- 最小依赖原则:widget 包体压缩后 < 80 KB,我们对每一个 npm 包都审视过 "它是否必要"。
我们诚实的边界
安全文档最忌讳 "承诺一切"。下面是 UpSwap 客观上无法防御的场景 — 写在这里,让你提前心里有数。
用户填错收款地址:链上交易不可逆。若用户复制粘贴时少了一位、填了已废弃的旧地址、或填了不支持目标币种的地址,资产将永久丢失 (irreversibly lost) — 我们和上游供应商均无法找回。请务必核对收款地址再点确认。
上游供应商被攻击:虽然他们各自有独立审计,但任何代码都不是绝对安全。若上游路由网络发生事故,可能影响 "已发出但尚未到账" 的订单。我们承诺第一时间公告并协助追溯,但无法用 UpSwap 自有资金兜底。
钓鱼站冒充 UpSwap:这类社工攻击 (social engineering) 无法用技术手段根除。请每次都核对地址栏 = https://upswap.io,警惕 upswap-io.com / 99bio.com / 99b.app 等仿冒域名。UpSwap 永远不会主动私聊你、不会向你索要私钥、不会要求你 "转账验证账户"。
失败原路退回的 retransfer gas:极少数情况下订单无法完成需原路退回,该笔链上退款交易的 gas 由上游供应商从退款金额中扣除 — 这是链的物理规则,不是 UpSwap 收的费。
漏洞披露
若你发现 UpSwap 存在安全漏洞,我们感谢你的负责任披露 (responsible disclosure)。请通过下列方式联系我们,请勿在公开渠道直接发布 PoC。
- 邮件至 [email protected],主题以
[SECURITY]开头 - 如涉及高敏内容,可使用我们的 PGP 公钥加密 (公钥指纹见 /security/disclosure)
- 我们承诺 72 小时内首次响应,重大漏洞 7 天内修复或缓解
- 确认有效的漏洞披露将进入致谢名单 (Hall of Fame),并视严重程度发放赏金 (bug bounty)
完整流程、赏金等级、范围 (scope) 与排除项 (out of scope) 详见 /security/disclosure。