Akutar项目的智能合约包含2个漏洞：

漏洞一：

1.第一个合约漏洞在processRefunds中，设计者根据refundProgress计数器进行循环退款。

2.而这里使用了call函数进行退款操作，且把退款的结果作为require的判定条件。

3.因此如果此时有攻击者在队列中进行退款操作，调用call退款给攻击者时，攻击者在fallback中进行进行恶意的revert则会导致退款队列卡在攻击者这里，从而导致队列后面的所有人都无法进行退款。

4.这个漏洞被人在链上证明有效，但随后攻击合约便进行了解锁，并没有进行攻击利用，且公开进行了申明。

漏洞二：

该漏洞也是导致价值约3400万美元的ETH资产被锁死在合约中的元凶。

1.在claimProjectFunds函数中，该函数主要用于项目方提款。为了避免项目方权限过大，在用户完成提款之前就将合约中的资产全部转走导致用户无法退款，所有的退款操作应全部完成之后项目方才能够提款。业务逻辑设计上来说，是没有问题的。然而，在具体的代码实现中，当前的代码容易受到漏洞一的影响，导致项目方无法提款，不过这只是潜在的风险，本次资金锁死的元凶不是这个原因。

2.注意函数中第620行代码：require （refundProgress > = totalBids）此处refundProgress表示已经处理了多少个用户的退款，totalBids表示所有用户总投标了多少个NFT。注意由于一个用户可以投标多个NFT，导致单从数值上比较，refundProgress可能小于totalBids。

而再来看看退款函数processRefunds中：require(_refundProgress < _bidIndex); bidIndex表示所有参与竞标的用户，refundProgress永远不会高于bidIndex。

此时来看看bidIndex的值，为3669：

totalBids的值为5495：

3.所以refundProgress>=5495且refundProgress<3669这个判断条件永远不会成立，最终导致项目方团队将永远无法执行后续的提款操作。此处应将refundProgress与bidIndex做对比，开发者犯了一个很低级的错误。最终，导致项目方11539ETH(价值约3400万美元)被锁定无法提取。

#3总结

针对本次事件，成都链安技术团队建议：

1.开发者应具备基本的安全开发意识，熟悉智能合约开发应注意的安全问题；

2.在合约设计和实现时，注意代码实现的正确性，项目上线前，可选择专业的安全审计公司进行全面的安全审计，规避安全风险。