Content Comparison

...

Move实现层面，区分不同的项目方来创建DAO，是通过Template Type 来对其进行异化还是通过 address+id的方式，若按照前者，如何解决合约动态部署的问题？

这个当前有两个方案，这个 issue 中提了两个方案 [Feature Request] Support Issue a Token on webpage · Issue #4 · starcoinorg/dapps (http://github.com ) ，未来可以支持合约中部署合约。
Snapshot中，存在不同的准入策略，即参与/创建投票的人在DAO中创建/参与投票的时候会有一个准入的门槛，这个准入的门槛是一系列判断条件，这个条件有预置的也有用户。在solidity中可以动态调用，故可以通过一个ABI的字符数组来进行表示，实际执行的时候也是动态去调用这个ABI，且这些策略是可以拼接的。而Move中如果也按照这个思路显然无法实现

感觉可以简化一下，小额抵押某种 Token 即可，如果是发垃圾投票就通过投票没收。
类似的，Snapshot也存在不同的Execution Action，在Move中也可以通过预置Execution的模式去实现，是否还有其他的实现思路？

当前 DAO 的 Action 是支持第三方扩展的，并不是只能用预置的 Action。
执行在前端触发。
治理权重的计算（基于长线hodl：锁仓时长、锁仓量），基于余额的权重计算有难度。锁仓有激励。
1. 不同类型项目采用不同机制。Swap自实现weight维护。
扩展点的设计，包括Action等动态调用的扩展，通过interface形式，前端来触发。DAO的平滑升级如何扩展？
1. Action的扩展性；
2. DAO类型的扩展性，不同DAO类型如何转换；
3. 投票权重的扩展性；
4. 投票策略类的扩展性；