但是，按照上面分析的逻辑，用户的本金是不会产生那么大的收益的，问题肯定是出在了 adapter 获取的 totalValue。也就是说 adapter 不止只有 AlchemistEth 充值代币，还存在其他的收益渠道。为了验证我们的想法，慢雾安全团队分析了 adapter 的所有代币收入，果然发现了一笔异常的转入行为，并且金额也能刚好对上多出的 4300 ETH 的收益。也就是说，问题就在这里了。

通过查看交易数据，发现这是一笔调用 harvest 操作的交易，调用的合约是 transmuter 合约：

也就是说，是这个 harvest 函数出问题了，harvest 函数的逻辑如下：

同样是调用了 vault 的 harvest 函数，熟悉的配方，熟悉的味道。我们再次进行 debug，发现一个惊人的事实 ——在进行收益的时候，vault 的 totalDeposit 竟然为 0，导致 4300 ETH 的收益直接分发给了 adapter，导致了 adapter 获取的 totalValue 错误了，多了 4300 个 ETH，原因就是在这里。

到了这里，我们已经很接近真相了，剩下要解决的就是为什么 totalDeposit 会为 0？我们查询了 transmuter 合约中能改变 totalDeposit 的地方，发现只有 _plantOrRecallExcessFunds 函数可以改变这个值，而这个函数上层调用的又是 distribute 函数。而 transmuter 合约的 distribute 函数是 AlchemistEth 合约在收益的时候进行调用的。也就是说本身的流程应该是：

1. AlchemistEth 合约调用 harvest 进行收益
2. AlchemistEth 合约调用 transmuter 合约的 distribute 函数记录收益情况，并把收益部分给 adapter
3. adapter 收到了 transmuter 的收益，根据收益偿还用户的 alETH 的贷款

但是问题就出在了 _plantOrRecallExcessFunds 函数中。由于在记录充值信息的时候，用的是 _vaults.last() 来获取最新的 vault，所以其实充值信息叠加在了最后一个元素上。但是项目方调用了三次 setActiveVault 函数，所以其实充值信息是叠加到了 _vaults 数组的 3 号元素，也就是 index 为 2 的 vault 元素上。但是在 transmuter 合约在 harvest 的时候传入的 _vaultId 却是 0，0 号元素是没有任何充值记录的，所以 transmuter 合约就误将所有的收益都给了 adapter 了。导致了悲剧的发生。 (责任编辑：admin)