一、改进动机
Starcoin 在主网启动之时就在引入 Dao 以及链上治理,这一年里进行了十多次系统合约升级以及配置变更的投票治理,链上参与者也越来越多,运行稳定,无安全事故,但也发现了一些当前 Dao 系统的不足之处。
投票系统
当前的投票系统基于 Token 抵押模式,带来几个问题:
投票成本比较高。投票期间 Token 被锁定,尤其随着 DeFi 生态的发展,用户的投票机会成本会越来越高。这样的投票方式也很难并行发起几个投票提案。
没有 Token 的应用无法进行治理。如果尚未发布 Token 的应用或者社群,无法进行投票。
Dao 的标志与身份
当前的 Dao 系统假定一个 Token 代表一个 Dao,所有的 Token 持有者都是 Dao 的成员。Dao 对外没有一个账号地址标志,成员没有独立的身份标志,不利于社群类型的 Dao 发展,也很难适配有准入机制的 Dao。
工具与应用的支持
由于以上不足,当前的 Dao 只提供了一个投票界面,用于发起投票。没能提供一个用户友好的,创建和管理 Dao 的工具。
所以我们计划对当前的 Dao 进行改进升级,以解决以上不足。
二、改进目标
基于以上分析,我们设定以下改进目标:
将投票权重积累到一个具体的数值上,这个数值用一种不可转让的 Token 来表达,可以称为灵魂绑定的 Token(Soulbound Token),简写为 SBT。
设计基于快照的投票系统,用户使用快照时的 SBT 的数值来投票,可以同时给多个提案投票。
每个成员有一个成员 NFT 用于标识该用户的身份,该 NFT 是不可转让的,通过 StarcoinFramework 中的 IdentifierNFT 来实现,上面的 SBT 嵌入到 NFT 中,同时实现不可转让。
Dao 可以适用于不同规模的 Dao,比如 Starcoin Dao,DeFi 项目 Dao,或者一个几人合作的独立工作室 Dao。不同规模的 Dao 之间可以无缝切换。
三、基本概念
GenesisDao
StarcoinFramework 中的 Dao 相关的系统合约。它是一个用来创建 Dao 的框架,提供有扩展能力的插件机制,可以让开发者组合出适合自己项目场景的 Dao。同时它也通过 DApp 方式提供一种简易的组合方式,让普通用户可以通过无代码的方式,利用系统合约内置以及第三方提供的插件来组合出符合自己需求的 Dao。
Dao 框架的名称以及 DApp 的名称待定,正在征集中 Dao 命名征集
Dao 账户(Dao Account)
每个 Dao 对应一个链上账户,该账户拥有代表 Dao 的 Resource。它的 signer 被托管到 Dao 合约中,所有交易都必须通过 Dao 来发起。
创建 Dao 的流程实际上是 Dao 发起者,先创建 Dao 账号,然后部署 Dao 合约,再创建 Dao 实体,并将 Dao 实体写入 Dao 账号,同时将 Dao 账号的 signer 托管给 Dao 的过程。
Dao
每个 Dao 有一个代表该 Dao 的 Resource 保存在 Dao 账号下。 每个 Dao 需要有一个类型标识,相当于该 Dao 的全局 ID,当 Dao 创建并注册的时候,将该类型和 Dao 进行关联。
比如有个叫 XDao 的类型标识类似 0x_dao_address::XDao::XDao
每个 Dao 代表一个合约控制的账户,以及在合约中定义的一组“能力(Capability)”,Dao 的成员可以通过发起提案以及 Dao 插件使用 Dao 的能力。
当前 Dao 定义了以下能力:
Install plugin capability:给 Dao 安装插件的能力
Upgrade module capability:升级 Dao 账户下合约的能力
Modify dao config capability:修改 Dao 配置的能力
Withdraw Token capability:从 Dao 账户下提取 Token 的能力
Withdraw NFT capability:从 Dao 账户下提取 NFT 的能力
Storage capability:给 Dao 账户下保存数据的能力
Member capability:给 Dao 添加成员,以及修改 Dao 成员 SBT 的能力
Proposal capability:给 Dao 发起提案的能力
Dao 注册表(Dao Registry)
每个 Dao 创建的时候,会将自己的类型标识和 Dao 进行关联,记录在 Dao 注册表中,合约中可以通过 Dao 的类型标识来反向查询 Dao 的账户地址。
Dao 成员 NFT(Dao Member NFT)
Dao 创建的时候,会同时发行一个 NFT,复用 Dao 的类型标识,DaoMemberNFT<X>。该 NFT 创建之后就立刻存入 IdentiferNFT 容器中,和用户绑定。成员加入 Dao 的过程就是领取 DaoMemberNFT 的过程,退出 Dao 的过程就是解除绑定并销毁 NFT 的过程。
Dao SBT
Dao 创建的时候,会同时发行一个 Token,复用 Dao 的类型标识,Token<X>。这个 Token 并不自由流通,而是锁在 DaoMemberNFT 的 Body 中,代表用户在 Dao 中治理投票的权重。不同的 Dao 可以根据自己的场景来映射 SBT,用来代表不同的含义。
Dao 提案(Dao Proposal)
Dao 中发起的治理提案,通过治理机制决定提案是否执行,Proposal 是抽象的,具体的 Proposal 如何执行取决于 Dao 的 Action。
Dao Proposal Action
Dao Proposal Action 决定了具体的 Proposal 的行为,可以由第三方作为插件提供,每个 Dao 可以安装不同的插件。
Dao 插件(Dao Plugin)
Dao 插件是给 Dao 提供扩展的主要方式,通过不同插件的组合,可以让 Dao 适用于不同的场景。每个插件安装时需要表明自己需要使用的“能力(Capability)”,插件可以在必要时从 GenesisDao 申请能力的使用权限进行调用。
四、使用场景预演
个人 Dao(Personal Dao)
类比个人独资公司。创始人拥有对 Dao 的直接控制力。比直接使用个人账户的优势:
可以逐渐升级为其他类型的 Dao,适合初创的过渡阶段。
个人 Dao 可以转让所有权。
合伙 Dao (Partnerships Dao)
类比有限责任合伙公司。几个合伙人根据出资比例或者其他条件分配治理权重,决策提案需要通过一定的投票阈值通过(比如 50%)才能执行,包括引入新的成员。
公共 Dao (Public Dao)
类比上市的股份有限责任公司。参与 Dao 的成员无限制,只要符合一定的公开条件,比如持有或者抵押某种 Token 等,即可成为 Dao 的成员,并且治理权重根据公开条件计算。
比如,创始人 Alice 开始有了一个想法,于是创建了一个 ADao,这时候成员只有创始人一人,所以他的 SBT 权重为 100%,所有的提案他一个人就可以通过。后来他招募了两个合伙人,Bob 和 Tom,每人占 1/3 的 SBT 权重,所有的提案至少需要 2 个人同意(Dao 投票阈值为 50%的情况),ADao 变成了合伙 Dao。再后来,ADao 发行了一个 Token,安装了 Stake 插件,抵押该 Token 的自动成为 Dao 成员,成员 SBT 根据抵押时长计算,该 Dao 成为一个公共 Dao。
五、整体设计
space:空间,负责跟踪提案、投票的全局设置,其包含多个提案,空间中有一些Meta data(头像,描述,主站信息等),DaoSpace用以负责描述空间信息,每个项目方均可通过调用DaoSpace::create 来创建一个space。
// DaoSpace.move module DaoSpace { struct Space { voting_delay: u128, // The delay between when a proposal is created, and when the voting starts. A voting_delay of 0 means that as soon as the proposal is created, anyone can vote. A voting_delay of 3600 means that voting will start 3600 seconds after the proposal is created. voting_duration: u128, // The duration of the voting period, i.e. how long people will be able to vote for a proposal. meta_data: vector<u8>, // 空间元数据,编码后存储在链上(可考虑存在链下) } struct NFTMeta { user: address, } struct NFTBody { weight: u128 } struct SpaceCapability { } // 创建 space,一个账号只能创建一个(是否只能一个账户创建一个,待讨论) public fun create(signer: &signer, voting_delay: u128, voting_duration: u128, meta_data: &vector<u8>): SpaceCapability; // 查询 space public fun query(broker: address) : (u128, u128, u128); // 非托管账号 register public fun register(signer: &signer, space_broker: address, cap: &SpaceCapability) : NFT<NFTMeta, NFTBody>; // 非托管账号 unregister public fun unregister(signer: &signer, nft: NFT<NFTMeta, NFTBody>); // NFT 添加权重 public fun add_weight(signer: &signer, nft: &mut NFT<NFTMeta, NFTBody>, weight: u128); // NFT 减少权重 public fun reduce_weight(signer: &signer, nft: &mut NFT<NFTMeta, NFTBody>, weight: u128); }
DaoRegistry
Dao 注册中心,保存在 0x1 账号下的全局注册表,提供 DaoT → Dao address 的反向索引
module DaoRegistry{ /// struct DaoRegistryEntry<phantom DaoT>{ dao_id: u64, dao_address: address, } //这个方法必须由 Dao module 调用 public(friend) fun register<DaoT>(dao_id: u64,dao_address: address){ let genesis_account = //get 0x1 signer move_to(&genesis_account, DaoRegistryEntry{ dao_id, dao_address, } ) } public fun dao_address<DaoT>():address{ *&borrow_global<DaoRegistryEntry<DaoT>>.dao_address } }
DaoAccount
对 Dao Account 的封装,提供通用的 Dao 账号存储能力,是否需要和 Dao 合并在一起
module DaoAccount{ //Dao 账号 signer 托管 struct DaoSignerCapability has key { cap: SignerCapability, } // The capability for write data to dao account struct StorageCapability has drop{ dao_address:address } struct DaoUpgradePlanCapability has key{ cap: PackageTxnManager::UpgradePlanCapability, } struct StorageItem<V has store> has key{ item: V, } public fun create_account(creator: &signer){ let signer_cap = Account::create_delegate_account(creator); let dao_signer = Account::create_signer_with_cap(&siger_cap); move_to(&dao_signer, DaoSignerCapability{ cap: signer_cap, }); PackageTxnManager::update_module_upgrade_strategy(&dao_signer, PackageTxnManager::get_strategy_two_phase(), Some(0)); let upgrade_cap = PackageTxnManager::extract_submit_upgrade_plan_cap(&dao_signer); move_to(&dao_signer, DaoUpgradePlanCapability{ cap: upgrade_cap, }); } public(friend) fun dao_signer(dao_address: address): signer { let signer_cap = borrow_global<DaoSignerDelegate>(dao_address); Account::create_signer_with_cap(&signer_cap) } public(friend) fun apply_storage_capability(dao_address: address): StorageCapability{ StorageCapability{ dao_address } } public fun move_to<V has store>(cap: &StorageCapability, item: V){ move_to(cap.dao_address, StorageEntry{ item, }) } public fun move_from<V has store>(cap: &StorageCapability): V { let StorageItem{ item } = move_from<StorageItem<V>>(cap.dao_address); item } }
Dao:代表治理的相关流程,该合约中处理底层Space与Proposal的拼装,将一些权限托管到该合约中,考虑还可以往上拆分,即将执行策略部分拆分到上层合约中。
// Dao.move module Dao { use DaoSpace; struct DaoSignerDelegate has key { cap: SignerCapability, // 托管的签名(这里一旦放进来,就没法再还回去了,且只有一份,没想好是放在space还是放在这里,暂时放这里) } struct Dao { id: u64, voting_delay: u128, // The delay between when a proposal is created, and when the voting starts. A voting_delay of 0 means that as soon as the proposal is created, anyone can vote. A voting_delay of 3600 means that voting will start 3600 seconds after the proposal is created. voting_duration: u128, // The duration of the voting period, i.e. how long people will be able to vote for a proposal. name: vector<u8>, //人类可识别的名称标识,是否需要? creator: address, meta_data: vector<u8>, // 空间元数据,编码后存储在链上(可考虑存在链下) cap: SpaceCapability } /// Proposal data struct. /// 是否需要通过 DaoT 来区分 Proposal,如果不需要,则需要把 DAO id 记录在 proposal 中 /// 但 Action 的泛型无法消除 struct Proposal<phantom DaoT: store, Action: store> has key { /// id of the proposal id: u64, /// creator of the proposal proposer: address, /// when voting begins. start_time: u64, /// when voting ends. end_time: u64, /// count of voters who agree with the proposal for_votes: u128, /// count of voters who're against the proposal against_votes: u128, /// executable after this time. eta: u64, /// after how long, the agreed proposal can be executed. action_delay: u64, /// how many votes to reach to make the proposal pass. quorum_votes: u128, /// proposal action. action: Option::Option<Action>, //在原来的 Proposal 字段上新增两个字段 block_num: u64, // 快照高度 root_hash: vector<u8> // 快照根hash } //Set 上也需要用泛型来区分 struct DaoProposalSet { proposal_set: HashSet<u64, DaoProposal> } //初始化过程中分配给 creator 的 cap struct RootCapability has key{} struct InstallPluginCapability has key{ } struct ProposalPluginInfo<PluginConfig has store> hash key{ installer: address, //通过 BitSet 的不同位置标识插件的不同权限 capabilities: BitSet, config: Option<PluginConfig, } // DaoWithdrawCapability 是一次性的 capability,不能 store,可以 drop struct DaoWithdrawCapability has drop{ } struct DaoMemberMeta<phontem DaoT> has copy{ user: address, } //这里是否需要 DaoT 来区分不同的 Dao? //如果不区分的话,同一个用户加入多个 Dao 的情况,当前的 IdentifierNFT 无法表达 struct DaoMemberBody<DaoT>{ sbt: Token<DaoT>, } // 执行策略:转账 struct ExecutionTransferStrategy<phontem TokenT> { amount: u128, to: address, } // 直接创建 Dao public fun new_dao( creator: &signer, voting_delay: u64, voting_period: u64, min_action_delay: u64) { //这里 Account 需要提供一个新的方法,允许用一个账号去创建另外一个 Delegate 账号。 let signer_cap = Account::create_delegate_account(&signer); let dao_signer = Account::create_signer_with_cap(&siger_cap); //下面面的操作切换到 dao_signer 身份进行操作 let dao = Dao{..}; move_to(&dao_signer, dao); // 托管 Dao 账号的 SignerCapability 到该合约 move_to(&dao_signer, DaoSignerDelegate{cap: signer_cap}); issue_member_nft(creator,&dao_signer); //初始化 dao 的时候无法一次性完成,需要先把 cap 都存到 creator 账号下 //然后按照 plugin 的方式逐步初始化 } // 将一个账号直接升级为 Dao, sender 会变为 Dao 账号 public fun upgrade_to_dao(sender:signer, ...) { //基本逻辑同上,省去了创建账号的流程 } ///这里好像没办法检测 DaoT 和 dao_address 的关系 public fun register<DaoT>(creator: &signer, dao_address: address){ let dao = borrow_global<Dao>(DaoRegsitry::dao_address<DaoT>()); //check the dao creator and creator args DaoRegistry::register<DaoT>(dao_address, dao.id) } fun dao_signer<DaoT>(): signer { let signer_cap = borrow_global<DaoSignerDelegate>(DaoRegsitry::dao_address<DaoT>()); Account::create_signer_with_cap(&siger_cap) } /// _access_key 确保这个调用来自 PluginT 的 Module public fun install_proposal_plugin<DaoT, PluginT>(cap: &dao::InstallPluginCapability, _access_key: &PluginT, installer:&signer, capabilites: vector<u8>){ let dao_signer = dao_signer<DaoT>(); move_to(&dao_signer, ProposalPluginCapability<PluginT>{ installer: Signer:address_of(installer), capabilites: BiteSet::from_bytes(capabilites), }) } public fun borrow_withdraw_capability<DaoT, PluginT>(plugin: &PluginT): DaoWithdrawCapability { // check capability with ProposalPluginCapability DaoWithdrawCapability } public fun withdraw<DaoT, TokenT>(cap: DaoWithdrawCapability, amount: u64): Token<TokenT>{ let dao_signer = dao_signer<DaoT>(); Account::withdraw<TokenT>(amount) } struct PluginStorageItem<PluginT, V>{ item: V, } public fun move_to<DaoT, PluginT, V>(_access_key: &PluginT, item: V){ let dao_signer = dao_signer<DaoT>(); move_to(&dao_signer, PluginStorageItem<PluginT>{ item }); } // 这里有个难题是 TokenT 从哪里来。 // 一种方法是先生成一个账号,部署合约,然后升级为 dao // 另外一种方法是通过 Dao 的合约升级方式进行部署合约 fun issue_member_nft<DaoT>(creator: &signer, dao_signer: &signer){ Token::register<DaoT>(dao_signer); let basemeta = NFT::new_meta_with_image(); NFT::register_nft_v2<DaoMemberMeta<DaoT>>(dao_signer, basemeta); let creator_address = Signer::address_of(creator); // issue 第一个 NFT 给 creator let meta = DaoMemberMeta<DaoT>{ user: creator; }; //如何初始化 creator 的 sbt? let sbt = Token::zero<DaoT>(); let body = DaoMemberBody<DaoT>{ sbt, } let nft = NFT::mint(basemeta, meta, body); IdentifierNFT::accept<DaoMemberMeta<DaoT>,DaoMemberBody<DaoT>>(creator); IdentifierNFT::grant(dao_signer, creator); } // 参与投票方/创建投票方注册到space public fun register_to_space( signer: &signer, broker: address) { // 创建对应的NFT } // 参与投票方/创建投票方注册到space // 方便再上一层的DAO调用 public fun regiter_to_space_get_nft( signer: &signer, broker: address) : Option::Option<NFT<DaoSpace::NFTMeta, DaoSpace::NFTData>> { } // 根据 space_broker 来创建对应的proposal public fun create_proposal<ExecutionStrategy>( signer: &signer, // 创建者 space_broker: u64, // space 代理人 block_num: u64, // 快照高度 root_hash: vector<u8> // 快照根hash ); // 投票 public fun do_vote( signer: &signer, broker: address, id: u64, amount: u128, choice: u8, proof: &vector<u8>, side_nodes: &vector<u8>) { // 证明... // 取本地NFT // 用NFT投票 do_vote_with_nft(broker, id, choice, ); } // 用NFT来投票 // 方便上层DAO来调用 public fun do_vote_with_nft( broker: address, id: u64, choice: u8, nft: Option::Option<NFT<DaoSpace::NFTMeta, DaoSpace::NFTData>> ) { } }
DaoTemplate
每个 DAO 初始化的时候都会根据这个模版生成一个命名为 XDao 的 module。需要确认下 XDao 这个 module 是否使用统一的名字更容易使用。
/// Dao 生成模版, module {X}Dao{ use StarcoinFramework::Dao; //XDao 的类型标识 struct X {} const DAO_ADDRESS = {dao_address}; public(script) init_dao(sender: signer, capabilities:vector<vector<u8>, plugin_configs: vector<vector<u8>>){ let plugin_install_cap = Dao::create_dao(); PluginX::install_plugin(&plugin_install_cap, &sender, capabilities[0],configs[0]); PluginY::install_plugin(&plugin_install_cap, &sender, capabilities[1],configs[1]); } ///Dao 的入口方法是不是都需要通过 XDao 模块代理一边? }
proposal:提案,即一个提案代表一次投票过程,该部分跟原有的流程类似,但是去掉了TokenType,该合约只处理提案的相关处理过程,不做其他无关的事情。
// DaoProposal.move module DaoProposal { struct ProposalCapability { proposal_id: u64, } struct Proposal<Action> { ... // 现有的一些结构 proposal_id: u64, voting_system: u8, // 投票类型有单选投票、二次投票、排名投票、加权投票等投票类型 voting_start_time: u64, voting_end_time: u64, voting_block_num: u64, // 投票快照高度 voting_block_root: vector<u8>, // 投票快照高度的root hash action: Option::Option<Action>, // 执行策略的结构参数 } struct Vote { /// vote for the proposal under the `proposer`. proposer: address, /// proposal id. id: u64, choie: u8, // 同意,反对,拒绝 weight: u128, // 投票权重 } public fun create_proposal<Action>(..., space_broker: address, space_id: u64, root_hash: &vector<u8>): ProposalCapability; public fun cast_vote( signer: &signer, proposer_broker: address, id: u64, amount: u128, choice: u8, cap: &ProposalCapability ); public fun extract_strategy<Action>(id: u64) : Action; };
Proposal action plugin
//所有的 proposal action 插件都需要提供两个公开的 entry script function,参数保持一致 module XProposalPlugin{ use Dao::{Self, ProposalPluginCapability} // XPlugin 的类型标识 struct XPlugin{ } struct XPluginConfig{ cfg_1: u64, } struct XAction{ } struct ProposalPluginCapabilityHolder{ cap: ProposalPluginCapability<XPlugin> } fun new_action(args:vector<u8>): XAction{ //bcs decode args //construct XAction } //返回 plugin 所需要的 capabilities public fun get_capabilities():vector<u8>{} public fun install_plugin<DaoT>(cap: &Dao::PluginInstallCapability, installer: &signer, capabilities: vector<u8>, config:vector<u8>){ //bcs decode config arg, construct config. let config = XPluginConfig{} let plugin = XPlugin{}; Dao::install_proposal_plugin_capability<DaoT, XPlugin>(cap, &plugin, installer, capabilities); //保存配置 Dao::move_to<DaoT, XPlugin>(&plugin, config); } public fun execute_proposal<DaoT>(sender: &signer, proposal_id: u64){ let dao_address = DaoRegistry::dao_address<DaoT>(); let cap_holder = borrow_global<ProposalPluginCapabilityHolder>(dao_address); let actoin = Dao::extract_proposal_action<DaoT, XAction>(&cap_holder.cap, sender, proposal_id); //execute the action,such as trasnfer token let plugin = XPlugin{}; let withdraw_cap = Dao::borrow_withdraw_capability<DaoT,XPlugin>(&plugin); let token = Dao::withdraw<STC>(&withdraw_cap, 1000); //update the executor } //the entry script function public(script) fun execute_proposal_entry<DaoT>(sender: signer, proposal_id: u64){ execute_proposal<DaoT>(&sender, proposal_id) } public fun propose<DaoT>(sender:&signer, args:vector<u8>, exec_delay: u64){ let action = new_action(args); let dao_address = Dao::get_dao_address<DaoT>(); let cap_holder = borrow_global<ProposalPluginCapabilityHolder>(dao_address); Dao::propose<DaoT, XAction>(&cap_holder.cap, sender, action, exec_delay, exec_delay); } public(script) fun propose_entry<DaoT>(sender:signer, args:vector<u8>, exec_delay: u64){ propose(&sender, args, exec_delay) } }
三、流程
创建流程
用户 A 发起交易,先创建合约账号 X, A 拥有 X 的控制权。
用户填写配置,选择需要安装的插件,生成 XDao module,以及初始化的参数。
编译 module,并且通过两阶段升级的方式,由 A 来发期交易,将 XDao module 部署到 X 账号下,并通 init_script 初始化 XDao 以及插件。
Dao 创建完成。
四、问题
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:锁仓时长、锁仓量),基于余额的权重计算有难度。锁仓有激励。
不同类型项目采用不同机制。Swap自实现weight维护。
扩展点的设计,包括Action等动态调用的扩展,通过interface形式,前端来触发。DAO的平滑升级如何扩展?
Action的扩展性;
DAO类型的扩展性,不同DAO类型如何转换;
投票权重的扩展性;
投票策略类的扩展性;
6.2号讨论:
插件的扩展性,DAO的创建,通过Templete来实现,第一期不开放注册入口
DAO的升级,不同类型的DAO进行抽象,尽可能抽象出同样的类型和权限,否则升级会比较困难;
Member加入的门槛,通过判断某种token的balance,不跟stake耦合;member列表如何存储?
SBT 权重的维护,由项目方合约来更新,无法实现hook机制
一期不提供合约,实现链下DAO+问卷类投票,纯粹API+前端来实现,同步开发合约;二期上线合约版DAO,支持链上DAO和治理,避免合约升级和兼容性问题。
设计通用的Stake流程和Library,锁仓时长、收益、权益的发放等
DAO产品调研和需求完善
论坛/文档
直播
公链升级切换到DAO上
DAO合约分工
DAO合约框架 @jolestar
插件机制,包括插件权限等 @jolestar
DAO Bob
Member及 插件机制 Ellen
SBT/NFT
Proposal ElementX
Action
工具链
bsc序列化,参数传参
merkle proof
权限,bitset
五、参考
https://github.com/snapshot-labs/sx-core/blob/develop/docs/milestones/1.md snapshot x 合约架构图
https://goerli.snapshotx.xyz/#/ 演示界面
https://mp.weixin.qq.com/s/7stRRj6zB2NarDk7VSitaQ
https://www.theblockbeats.info/news/30539
https://www.theblockbeats.info/news/30567
https://www.theblockbeats.info/news/30569