“平台能不能升级代码？能不能转走押金？谁能决定退款？还有没有后门？”

盛丰在线2.0｜三方权限核查与公开源码审计说明

本页面向普通用户与代码审查者，基于当前公开的 EscrowFactory + BaseEscrow Solidity 源码做静态核查。请自行在 TRONSCAN 核对合约地址与源码验证状态。

审计范围

基于当前公开的 EscrowFactory + BaseEscrow Solidity 源码，对 角色权限、资金流、升级路径、退款路径、后门特征 做静态核查。

必须明确

•这不是持牌 / 签章第三方审计机构报告。
•“源码层面未发现”不等于绝对不存在风险。
•用户仍应在 TRONSCAN 核对合约地址、源码验证匹配状态和部署代码。

三方权限核查

A. Owner / Admin

可以：

•owner 转移 owner
•owner 设置 admin
•owner pause / unpause
•owner 设置 minDepositAmount
•owner 设置 ignoreFee
•owner / admin 创建订单并设置 feePerDay / feePercent / fixFee
•owner 的 transferAsset 可转 Factory 自己持有的资产

不能直接：

—当前源码没有 setImplementation / upgradeTo / upgradeToAndCall
—未看到 owner 可直接把单笔 Vault 中已记账押金 e.balance 提到任意地址

提醒：owner / admin 创建订单时可决定初始手续费；创建后未看到单笔订单手续费 setter。

B. Service

可以：

•作为订单成员参与退款
•Service 自己 proposeRefund 时会立即 executeServiceRefund，无需 A/B 二次确认
•Service 可 settlePendingRefund：取消 Pending 提案，重新提出新方案并立即执行
•Service 可 recoverSurplus，但只能取 Vault 中超出 e.balance 的 surplus

Service 是当前退款机制中权限最强的角色。

·对 USDT，surplus = actual balance − e.balance
·recoverSurplus 不能用这个函数直接拿走已记账押金

C. A / B

可以：

•A 或 B 都可以 proposeRefund
•A 发起后 B 可 approveRefund；B 发起后 A 可 approveRefund
•一方发起不能自己 approve
•A / B / service 任一订单成员都能 cancelRefund

不能：

—单方自己完成普通 A/B 双签退款
—不能修改 implementation
—不能调用 owner 管理函数

核心问题 1

平台能不能升级代码？

按当前公开源码：未发现可以修改现有 Factory implementation 或升级现有合约逻辑的业务入口。

依据：

•implementation 是 public immutable
•constructor 中一次性 new BaseEscrow(usdt_) 写入 implementation
•createEscrow 使用 Clones.clone(implementation)
•未发现 setImplementation / upgradeTo / upgradeToAndCall

边界

平台可以另部署新合约地址，但不等于升级当前地址。用户必须核对自己交互的 Factory 地址。

核心问题 2

平台能不能直接转走押金？

按当前源码：未发现 owner 直接把单笔 Vault 中已经记账的押金 e.balance 转到任意地址的接口。

解释：

•deposit() 的 USDT 直接进入订单 Vault，不是 Factory
•owner 的 transferAsset() 操作 Factory 自己地址上的资产
•Vault 正常退款出口：fee → Factory，amountA → A，amountB → B
•recoverSurplus 只允许 Service 提取 surplus；USDT accounted = e.balance

提醒：Service 的退款决定权会影响押金最终如何分配，这与 owner 直接从 Vault 提款是两个问题。

核心问题 3

谁能决定退款？

A/B 可以双向协商退款；但 Service 拥有单方立即执行退款，以及覆盖 Pending 提案的特殊权限。

细化：

•A / B / service 都可 proposeRefund
•A/B 发起时进入 Pending，需要另一名成员 approve，提案人不能自己 approve
•Service 自己 proposeRefund 时直接 executeServiceRefund
•Service 可 settlePendingRefund：取消旧提案后，按新 mode / amount 立即执行
•approveRefund 调用者只要是 A/B/service 成员且不是 proposer 即可

不能把当前机制描述成“所有退款都必须 A+B 双签”。更准确的是：A/B 可互相双签解除，但 Service 保留单方退款处置权限。

核心问题 4

还有没有后门？

在公开源码的 EscrowFactory / BaseEscrow 业务代码中，未发现 owner 可配置的任意 delegatecall、selfdestruct、setImplementation、upgradeTo 或任意地址提款 Vault 已记账押金的隐藏入口。

公开高权限，不应叫隐藏后门

•owner：transferOwnership / setAdmin / setPause / setIgnoreFee / setMinDepositAmount / transferAsset
•owner / admin：创建订单并设置初始手续费
•service：单方退款、覆盖 Pending
•service：recoverSurplus

说明：Address 库出现 functionDelegateCall、Clones 使用 delegatecall，不等于 owner 有任意 delegatecall 后门；当前业务函数里未发现 owner 可指定任意 delegatecall target 的入口。

手续费权限专题

•订单创建时 owner / admin 传入 feePerDay、feePercent、fixFee
•退款时 _quoteRefund 计算费用
•feePercent >= 10000 时 percentageFee 可等于 balance，最终 fee 最多可能达到全部 balance
•单笔订单创建后未看到手续费 setter
•用户入金前应通过 getFeeTerms(id) 核对

平台不能在订单创建后随手改这笔订单的费率，但创建订单时的费率本身必须先看清。

资金流图

正常存入与退款执行

A/B 钱包 ──deposit──▶ 订单 Vault

退款执行：
   订单 Vault ──feeAmount──▶ Factory
             ──amountA────▶ A
             ──amountB────▶ B

Surplus 回收流程

Vault actual balance − e.balance = surplus
        │
        └── 仅 Service 可 recoverSurplus ──▶ Service

surplus ≠ 已记账押金

用户自己如何复核

1TRONSCAN 核对 Factory 地址
2Code 页确认源码验证匹配提示
3Read Contract 查看 implementation
4getEscrow(id) 查看 vault / A / B / service / balance / status
5getFeeTerms(id) 看费率
6getRefund(id) 看退款提案
7Event 查看 Deposited / RefundProposed / RefundExecuted / SurplusRecovered / FactoryAssetTransferred / OwnershipTransferred / AdminSet / IgnoreFeeSet
8重点关注 OwnershipTransferred、AdminSet、IgnoreFeeSet 等管理事件

打开 TRONSCAN 公开源码

最终摘要

代码升级

当前源码未发现现有地址升级入口；平台可另部署新地址。

直接提押金

未发现 owner 任意提取 Vault 已记账押金入口。

退款决定

A/B 可双签；Service 有单方执行和覆盖 Pending 的特殊权限。

后门

未发现上述典型隐藏后门特征，但存在明确公开高权限，尤其 Service 退款权与订单创建手续费设置。