解决DeFi 生态存在的安全问题，减少黑客攻击损失。
只有白皮书文档，产品没有上线。
项目本身不负责寻找可疑攻击交易，是期望搭建一个平台，让社区用户（白帽子）为了激励制造出高效的检测工具。
具体代码层面，计划通过给Token增加如下公开方法支持任意用户冻结任意地址：
function allegeHack(address allegedHacker, uint256 freezeDuration) external returns (bool);
如何吸引项目方在Token合约中嵌入该平台的代码？
为了能冻结任意地址的余额，token合约需要集成lossless的代码。这种方案是侵入式的，需要修改项目的Token合约代码，这不仅给项目方带来了额外技术成本，也给普通用户的每一次转账交易都增加了Gas Fee成本。
另外lossless并不能保证嵌入项目合约中的代码是100%安全的。
DeFi项目众多，如果项目方自己的项目发展很好，但LSS项目因为种种原因无法继续运营，而项目Token的合约集成lossless的代码，将给项目方带来持续的影响。
如何确定hack finder 应该质押多少LSS 代币？
漏报率和误报率是传统互联网安全产品的两个常见评估指标。
分析该项目的经济模型，我们可以预见，如果finder质押的金额过少，将带来大量误报（允许判断错误，不放过任何一个可疑交易）。相反，如果质押的金额过多，将产生大量漏报，finder必须100%保证发现的交易一定是恶意的攻击（否则会被罚没质押金）。
而这个数字，在官方文档中并没有提及（只提到奖励金额是挽回损失的2%）。
如何保证finder提交疑似攻击的及时性？
该项目的解决方案是监测攻击的发生，期望攻击事件发生后第一时间冻结相关地址的资产。
官方文档中以PAID Network的攻击事件举例，攻击发生到黑客卖出Token中间有4分10秒的时间差，这个时间差足以finder提交冻结信息。
但事实上，黑客的攻击都是精心准备的，如果黑客事先知道该项目的Token有被中心化冻结的可能，一定不会给别人留下操作的时间。例如通过MEV等方式将攻击交易、卖出交易甚至洗币交易组合执行。
观察目前发生过的攻击事件，黑客都会第一时间将获取的USDT兑换为DAI等去中心化稳定币。
黑客攻击确实给参与DeFi的用户造成了大量损失，合约的安全性也是各个项目方应当着重考虑的问题。但lossless的解决方案是一种理想状态下的经济学安全方案而非数学安全方案，且存在较多的技术问题，个人推测其非常难得到项目方的支持。