A selective archive of Telegram discussion around Community Fund DAO v1.1. It traces the proposal from launch and review through implementation, the announced launch, the later postponement, and the scrutiny that followed.
This archive reconstructs the public record from the two main Telegram rooms where the DAO v1.1 discussion unfolded. It does not include every message.
Included: Messages were chosen through keyword search, reply-chain review, and sliding windows around relevant exchanges. Included material documents the proposal, its review, the voting process, the implementation and launch path, and the later scrutiny of specific design and governance choices.
Excluded: Cross-post duplicates, unrelated tangents, and low-information fragments were removed when they did not materially clarify the discussion. Forwarded and reply context was retained when it clarified the exchange.
Missing messages: Any important omissions are unintentional. Readers are welcome to flag them for inclusion in later revisions.
Dear CKB community, we’ve just posted a proposal for enhancing the Community Fund DAO v1.0 to v1.1
This proposal aims to address current challenges in operational efficiency, project oversight, and user experience by introducing a professional and neutral “Stewards” team and a new Web5 governance platform. Our goal is to empower the existing v1.0 framework, making it more efficient and transparent for everyone.
Appreciate any of your valuable feedback and questions.
Let’s build the future of CKB governance together!
To help the community better understand and discuss the details of the DAO v1.1 Web5 Optimization Proposal, I’ve created a shared space for it in NotebookLM.
You can ask the AI specific questions about any part of the proposal and view an interactive mind map to quickly see the structure and key ideas.
Dear CKB community, we’ve just posted a proposal for enhancing the Community Fund DAO v1.0 to v1.1
…
Hello CKB community, we’ve posted a Q&A Update (As of Sept 5, 2025) in our DAO v1.1 proposal thread on Nervos Talk to address key community questions.
This includes a crucial discussion on whether our proposal should be classified as a “Budget Request” or a “Meta-Rule Change.” This is a fundamental governance topic, and we need your wisdom.
Please take a moment to read and share your perspective. Your input will shape the path forward.
Today’s discussion has been insightful and rigorous, exactly what a healthy DAO needs. To help every member keep up and to focus the conversation, we’d like to post the Ongoing Q&A Update (As of Sept 6) for the core themes that have emerged.
Your perspective is crucial and will directly influence our next steps. We are here to listen.
To help the community better understand and discuss the details of the DAO v1.1 Web5 Optimization Proposal, I’ve created a shared space for it in NotebookLM.
You can ask the AI specific questions about any part of the…
To help the Community better understand the nuances involved with switching from v1 to v1.1, I’d like to encourage the Community to try out this NotebookLM complete with both CommunityDAO v1 & v1.1:
Drawing on the provided sources, critically evaluate the v1.1 proposal’s assertion that it is a ‘Budget Request Proposal,’ not a ‘Meta-Rule Change Proposal,’ especially considering DAO v1.0 defines meta-rule changes to include alterations to ‘conditions for adoption’.
Despite v1.1’s claim that it makes no changes to these core ‘conditions for adoption’:
Does replacing v1.0’s ‘7 days + 30 likes’ Discussion Stage (which had explicit ‘Passing conditions’ for advancement) with a ‘30-day community review period’ that has ‘no threshold’ for passing constitute a change to a ‘condition for adoption’?
Do the new, formalized ‘quick confirmation vote’ and ‘full review vote’ mechanisms for ‘Milestone Oversight,’ complete with specific ‘Minimum Turnout’ and ‘Decision Threshold’ rules, introduce new ‘conditions for adoption’ despite v1.1 framing them as mere ‘execution oversight’ tools?
Should this vote be subject of the more stringent rules of meta-rule change?
Hi @mattQuinn@phroi Thank you both for pushing this critical discussion forward.
Our team has a good-faith interpretation based on the v1.0 text, but what matters most is the community’s shared understanding.
To help everyone clarify this, could you please walk us through your textual analysis? For instance, regarding the 3 points you mentioned, how do you connect the v1.1 changes to the specific definition of a meta-rule in the v1.0 document?
Your perspective would be invaluable for the community to build a clear consensus.
As is laid out in the rules, anything that is not a budget proposal is a meta rule change
Thank you, Matt, for bringing the focus back to the literal text of v1.0. You are right, the document lays out only two categories.
However, the challenge is that the V1.1 proposal is clearly more than a simple budget request like funding a dApp, because its deliverables are services and tools that directly affect the DAO’s operations. Yet, it is also less than a true meta-rule change, because, as we’ve argued, it does not alter the meta rights of voters (weights, eligibility, core adoption conditions, etc.).
I figure when faced with such ambiguity, we could return to the first principles of what DAO governance is. At its core, DAO governance is the formal exercise of voting power by CKB stakers. From this perspective, a procedure like the “7 days + 30 likes” on Nervos Talk, which is open to non-stakers and does not use weighted voting, is just a valuable community signaling tool. Similarly, the post-approval management of already-allocated funds is an operational execution, not a primary governance decision, etc.
Definitely, our pragmatic reason in classifying this as a Budget Request is not to sidestep rules, but to enable the DAO to evolve faster and more effectively.
I believe we share the same goal. Thanks again for sparking this crucial discussion. We are now keen to hear the broader community’s opinion
Thank you, Matt, for bringing the focus back to the literal text of v1.0. You are right, the document lays out only two categories.
However, the challenge is that the V1.1 proposal is clearly more than a simple budge…
Let me put it this way, if it was the Metaforo team proposing these changes, with them proposing to take custody of DAO funds, would you consider it a rule change to the DAO?
Dear CKB community, we’ve just posted a proposal for enhancing the Community Fund DAO v1.0 to v1.1
…
A Quick Housekeeping Note on “Likes”
Hello everyone, a quick housekeeping note to ensure our proposal proceeds correctly under the v1.0 rules.
Due to the length of the proposal, we had to post the Chinese and English versions in two separate replies (the first and second posts in this thread). However, for the “30 likes” count to be correctly recognized, all support needs to be registered on the very first post.
We have a small request for those who have supported us:
If you have already liked the second post (the English version), could you please also give a ‘like’ to the first post (the Chinese version at the top)?
We understand this means some of you will have liked both posts, but this is the only way to ensure all support is correctly consolidated for the official count. We apologize for any inconvenience caused by the forum’s limitations.
Thank you for your understanding and support!
Phroi (No DM) (2025-09-10T06:57:01, Nervos Nation, edited 2025-09-10T11:04:04)
I would like to also point out that the proposal is now recognized by all parties as needing a meta-rule vote
Dear CKB community, we’ve just posted a proposal for enhancing the Community Fund DAO v1.0 to v1.1
…
Hi CKB community,
Following the intense and valuable community debate, our proposal’s advisor, Baiyu, has posted a significant statement on Nervos Talk outlining a clear path forward.
Reclassifying the proposal as a Meta-Rule Change to honor procedural integrity.
Incorporating the option for USD/USDI denominated funding into the proposal, to address a key community pain point.
Pledging to extend the community discussion period by one month before any vote, once the proposal meets the initial “7 days + 30 likes” threshold required by v1.0 rules.
This marks a major evolution for the proposal, and our team is now working to revise the text accordingly.
Encourage everyone to read Baiyu’s full statement.
Phroi (No DM) (2025-09-10T20:22:24, Nervos Nation, edited 2025-09-10T20:25:12)
Following the intense and valuable community debate, our proposal’s advisor, Baiyu, has posted a significant statement on Nervos Talk outlining a clear path forward.
…
This is so cool!! Just one more vote and we’ll reach 30
Dear CKB community, we’ve just posted a proposal for enhancing the Community Fund DAO v1.0 to v1.1
…
Major Update on the DAO v1.1 Proposal
After an intense and constructive community debate, the v1.1 proposal has evolved. Based on key feedback, it is now officially a Meta-Rule Change Proposal and includes a USD/USDI funding option.
We believe this new version represents a unified path forward for CKB governance! If the initial 7-day/30-like threshold is met, the discussion period will be extended for one month to build broad consensus before proceeding to the formal vote
Dear CKB community, we’ve just posted a proposal for enhancing the Community Fund DAO v1.0 to v1.1
…
Thanks to your incredible engagement and 30+ likes, the v1.1 proposal has successfully passed the first stage on Nervos Talk.
As promised, we are now officially kicking off the one-month extended community review period. To start this new phase, we’ve put together a new video that breaks down the core problem and our solution. It’s the perfect starting point for our deep dive.
Please read the full update, watch the video, and continue asking your tough questions in the thread. Let’s use this month to build a strong consensus together!
Thanks to your incredible engagement and 30+ likes, the v1.1 proposal has successfully passed the first stage on Nervos Talk.
As promised, we are now officially kicking off the one-month extended community review pe…
Got questions about the CKB DAO v1.1 proposal? We’ve got answers.
We just cooked an AI Avatar FAQ video to tackle the most critical community questions.
Why v1.1? What about project risks? Is it too complex? Get the key answers in 2 minutes.
After an intense and constructive community debate, the v1.1 proposal has evolved. Based on key feedback, it is now officially a Meta-Rule Change Proposal and includes a USD/U…
pow+utxo+channels is what we envisioned when CKB started, pow+utxo is pretty usable already, and we’re focusing on the channels frontier
…
For the v1.1 proposal, we’ll have the first AMA on Sept 25 (Thu), 09:00 am UTC+8 (Sept 24 (Wed), 18:00 pm PDT)
All team members of the proposal will be there to answer questions (having consecutive interpretation for better conversation)
Looking forward to seeing you all here, and appreciate any suggestions!
Appreciate your participation and any proposal-related questions!
Here’s the basic agenda:
Opening & Status Update (~10 mins): We’ll introduce the team and briefly recap the proposal’s journey so far.
Section-by-Section Deep Dive + Q&A (~100 mins): We’ll walk through the key sections: the Stewards, treasury model, operational rules, and the Web5 platform. Crucially, within each section, we’ll pause for questions.
Wrap-up & Next Steps (~5 mins): We’ll summarize the key takeaways and outline what’s next for the community review month.
I’ll be hosting and leading the presentation. We’ll also have a consecutive interpreter to ensure the conversation is smooth for everyone.
Hello community members, The DAO v1.1 Web5 Optimization Proposal | Community Deliberation Month AMA#1 will commence in 5 minutes. Click the link below to join the event. Meeting link: meet.google.com/rdj-ynpd-mse
Hello community members, The DAO v1.1 Web5 Optimization Proposal | Community Deliberation Month AMA#1 will commence in 5 minutes. Click the link below to join the event. Meeting link: meet.google.com/rdj-ynpd-mse
Thanks for all your participation in the AMA and attention to the DAO 1.1 proposal. We’ll prepare a summary for those who couldn’t join us today. In the middle of October, we’ll have another AMA, and we’ll continue to answer your valuable questions on Talk and TG groups.
Dear all, a friendly reminder, the AMA will be opened a few hours later.
Date: Sept 25 (Thu) 09:00 AM UTC+8 | Sept 24 (Wed) 18:00 PM PDT Platform: Google Meet (Bilingual with interpretation)…
Hey everyone, for those who couldn’t attend our first AMA or for anyone who wants a recap, we’ve just posted a detailed, anonymized summary of the discussion.
We had a great conversation with Matt, Jordan, and nearly 20 community members, covering everything from the role of the DAO Stewards to the practicalities of the Web5 platform.
Please take a moment to read the minutes and continue the discussion in the Talk thread. Your feedback during this Community Review Month is crucial!
Hi everyone, we’ve just posted an update to the proposal based directly on your feedback from AMA #1 and the forum.
This is your feedback in action! Key changes include:
Stalled Project Clause: Added a rule to handle projects that go silent (thanks, Knmo!). Operational Handbook: Stewards are now required to maintain a public handbook for transparency. Simplified Funding: Removed the most complex funding option to streamline operations (Keep the Fixed CKB Amount and Fixed USDI Amount).
Please read the full update on the Talk thread. We’re now in the final weeks of the review period!
Phroi (No DM) (2025-10-14T23:54:05, Nervos Nation, edited 2025-10-15T10:13:37)
The DAO rework that is being carefully carried out as we speak is a move towards establishing a sustainable community governance system. The first community DAO taught lessons, this iteration aims to improve on the previous.
Great question and thank you, Matt! Eager to hear everyone’s thoughts, too.
We’ve been working hard on incorporating the fantastic feedback from the AMAs, and will be posting an update with a new changelog on the Talk thread very soon
Great question and thank you, Matt! Eager to hear everyone’s thoughts, too.
We’ve been working hard on incorporating the fantastic feedback from the AMAs, and will be posting an update with a new changelog on the Tal…
Dear all, as our Community Review Month is coming to a close, we’ve just posted a new update to the proposal, incorporating all the great feedback from the last few weeks:
The Changelog: We’ve shortened the review period to 21 days and made the multi-sig solution more flexible and robust.
A transparency statement: Clarifying our team members’ backgrounds and the project’s independence.
A key Q&A on governance principles: Explaining our stance on a “1-year sunset clause” and why we must uphold the DAO’s core rules.
We believe the proposal is now in its strongest form and ready for a community decision.
A huge thank you to everyone who participated in this process!
Dear all, as our Community Review Month is coming to a close, we’ve just posted a new update to the proposal, incorporating all the great feedback from the last few weeks:
The Changelog: We’ve shortened the review…
Dear all,
After a month of incredible community discussion, refinement, and collaboration, it’s time to make a decision. The formal vote for the DAO v1.1 proposal is now open for the next 7 days.
This proposal aims to: Introduce DAO Stewards for professional operations Build a new Web5 governance platform Optimize the entire governance process
This is a meta-rule change, so it requires a high threshold to pass: 67% YES votes & a 185M CKB quorum. Your participation is more critical than ever.
Thank you to everyone who contributed to this process. Let’s get this done.
After a month of incredible community discussion, refinement, and collaboration, it’s time to make a decision. The formal vote for the DAO v1.1 proposal is now open for the next 7 days.
…
Dear all, a quick but important update on the DAO v1.1 vote:
High Engagement: In just 24 hours, voter turnout has already surpassed any meta-rule vote from the last year.
A Crucial Discussion: A voter has raised a profound challenge about our DAO’s core bottleneck (“builders scarce vs. process failure”). Thanks for the valuable question and we have responded with a data-driven analysis.
The community needs a sustainable governance platform for the future of the network. Is that what the proposal is? Maybe not but IMO it’s a step in the right direction. The community will not learn how to govern overnight. I’ve always viewed the community DAO as a steppingstone to bigger things.
Dear all, a quick but important update on the DAO v1.1 vote:
High Engagement: In just 24 hours, voter turnout has already surpassed any meta-rule vote from the last year.
A Crucial Discussion: A voter has r…
DAO v1.1 Vote Update & Timeline Change
Dear all, quorum achieved, and the vote is tight (~46% YES). Appreciating your engagement and contribution to our community’s governance!
To ensure high-quality delivery, we’re proactively extending our dev timeline by 1 month. We’re building robust infra, not a rushed product. And our CKCon MVP promise remains.
Dear all, thank you for the passionate discussion on the DAO v1.1 proposal, especially to @Winnerwinner111 for the frank and sharp critiques. A healthy governance process needs these voices. I’d like to take this opportunity to address these important concerns head-on.
1. The Core Issue: Are We Building an Office or Sharpening the Axe?
A central critique is that our problem is “scarce builders,” not a “failed process,” so we should attract builders first, not build a system no one will use.
This view seems intuitive, but it overlooks a harsh reality: the machine we use to attract and support builders is broken. Our previous reply on Metaforo detailed this with data:
Community attention has collapsed: Proposal views in 2024 are just one-third of what they were in 2023.
External teams are being discouraged: Of 9 proposals from external teams in 2024, zero made it to a vote.
The voting system is failing: A 100% approved proposal for USD pricing failed due to low participation.
Active projects are being harmed: CKBoost was left waiting for payment after delivering a milestone.
When the axe is dull, the right move isn’t to chop harder; it’s to stop and sharpen the axe. The v1.1 proposal isn’t about building a “luxury office”; it’s about sharpening our one and only axe.
2. On the Team: Are stewards “Managers” or “Servants”?
The proposal clearly defines the DAO Stewards as a “service team” with zero voting or decision-making power. They are elected by the community for a one-year term and can be impeached by a no-confidence vote at any time. This is a clearly defined executive role under strict community oversight, and it has nothing to do with any form of centralized control.
3. On Alternatives: Why Not Just a “Guideline” or a “Free Platform”?
A “guideline” won’t solve the problem: The struggles of v1.0 prove that rules without execution tools and accountable individuals are ineffective.
Web5 is the strategy to combine BTC/CKB, RGB++, Fiber, with good-to-use and distributed Web2 technologies, like nostr and AT protocol. We are building Web5 infrastructure, not an MIS system: No off-the-shelf Web2 platform can meet our core needs: sovereign identity via Web5 did, on-chain governance data, deep integration with CKB assets, and a user-friendly experience. This is a vital piece of ecosystem infrastructure, and its complexity and value are far beyond that of a simple proposal system.
4. On the Budget: Is It a “Cost” or a Reasonable Investment in Professional Work?
The $100k budget is primarily split into two parts: $72k for platform development and $18k for the first year of the Stewards’ operations. As mentioned above, this budget is not for “building an office”; it is to provide reasonable compensation for the professional labor of the skilled developers, designers, and project managers required to build this Web5 infrastructure.
We believe that investing market-rate resources into a strategic infrastructure project critical to the DAO’s future is a responsible use of community funds.
Thanks again for your attention to the DAO governance, and I hope my answer has solved your concern.
Additionally, a thank you to @TheSpaceKook and @Wyltek for your insightful discussion. As Phill pointed out, the Community Fund DAO was created precisely to fund community-led initiatives like v1.1 that build public goods for the ecosystem.
We believe a more professional, efficient, and transparent governance framework is the cornerstone for attracting and retaining all future builders. We welcome all rational critiques and look forward to the community’s final decision in the vote.
Dear all, wanted to share more thoughts on the ongoing DAO v1.1 vote and a key debate.
It really boils down to this core question: Is our problem “scarce builders,” or is a broken process actively discouraging them?
Our take is that the warning signs are already here: collapsing attention, failed key votes, and harmed active projects. We believe the rational choice right now is to take action to address these risks.
So, the community is faced with a clear strategic choice:
Do we wait for more “proof” within the existing framework and accept the risk of the DAO falling into further stagnation?
Or do we make a reasonable strategic investment now to fix the series of failure signals we already see, creating the necessary precondition to attract and retain builders in the future?
Certainly, we would genuinely welcome a proposal from our community that directly tackles builder attraction. The two choices are not mutually exclusive; in fact, they could be complementary.
Also, a friendly reminder: you can only vote with CKB staked in the Neuron Wallet. This friction is one goal the new Web5 platform in the v1.1 proposal is designed to fix.
Firstly, a sincere thank you to every community member who has voted, whether Yes or No. You took the time to study the proposal and navigate the somewhat complex Neuron voting process. That participation alone deserves the utmost respect!
Right now, the engagement has far exceeded expectations, with a total of 250M votes surpassing the 185M quorum.
But the vote is extremely close, with the current approval rate at 55.25%, still a ways to go from the 67%.
Over the past day, I’ve seen two very real and important perspectives emerge in the community:
The first is a feeling of frustration and distrust in the current situation. A sense that the governance experience is too cumbersome, the value of past projects is unclear, and that critical feedback can feel unwelcome.
Our proposal team relates to this feeling deeply. As Baiyu mentioned, he was also discouraged by the Neuron sync process several times. These pain points are the very reason we initiated the v1.1 proposal. We’re not trying to make things more complicated; we simply want to use a new, unified platform and service team to solve the current problems of fragmented tools, poor communication, and high barriers to entry.
The second is: are we focused on the wrong thing? The problem is a lack of projects and builders, so why spend money on an internal system?
This is the main point I responded to yesterday. When teams arrive with ideas but can’t communicate well; when a 100% approved proposal fails due to low turnout; when a project delivers but can’t get paid… These aren’t isolated incidents but are signals of a system in failure. We hope to fix this with v1.1.
The v1.1 proposal isn’t a perfect, one-shot solution, but it is a sincere attempt to solve real problems. As one CN community member, “再见理想”, said, a new attempt is better than doing nothing at all.
Thanks again, everyone!
Neon (if I DM I scam) (2025-10-30T14:11:26, Nervos Nation, edited 2025-10-30T14:12:11)
The second is: are we focused on the wrong thing? The problem is a lack of projects and builders, so why spend money on an internal system?
This is the main point I responded to yesterday. When teams arrive with ideas…
Having observed the discussion I think the merit of DAO v1.1 can be seen from the efficiency and procedural benefits.
It’s clear to me based on the history of v0 that the lack of proposals and overall interest is an entirely separate issue and wouldn’t be solved by procedural improvements.
For that, continued efforts to build relationships and funnel them towards the DAO would be necessary, along the lines of Catalyst, Spark and any other BD or community outreach. Some roles similar to this are mentioned in Jordan’s DAO v2 proposal.
Replying to this message from Neon (if I DM I scam):
Having observed the discussion I think the merit of DAO v1.1 can be seen from the efficiency and procedural benefits.
It’s clear to me based on the history of v0 that the lack of proposals and overall interest is an…
Hi Neon, I completely agree with your core point: v1.1 itself is not designed to directly “create” new proposals, and attracting builders requires continuous, dedicated efforts, much like Catalyst, Spark, BD, outreach, and some roles in Jordan’s V2.
Otherwise, regardless of the final outcome of the vote, seeing so many community members like you investing so much time and energy into discussing the future of the DAO is one of the most valuable outcomes our proposal team could have hoped for.
Honestly, if this vote can inspire any community member to bring more proposals, like one that directly tackles the “builder attraction” problem, then all our efforts will have been worthwhile.
After a month of incredible community discussion, refinement, and collaboration, it’s time to make a decision. The formal vote for the DAO v1.1 proposal is now open for the next 7 days.
…
The v1.1 vote has now surpassed 300M CKB in total votes. The approval rate has climbed to 62.66%, getting closer to the 67% goal.
There are three days left to vote. Thanks to all community members participating in the governance. Have a great weekend!
Hi everyone, a community member has voted NO for the v1.1 proposal, with the core reason being concerns about high estimates in the budget (e.g., domains’ cost).
After careful discussion, we have just posted a formal reply on Metaforo, which includes the public commitments regarding the budget:
Full Transparency Commitment: After each milestone is completed, we will publish a detailed, itemized report of all fund usage alongside our delivery report.
Cost Control Commitment: All non-labor infrastructure budgets (including domains, and others such as servers, contract deployment fees, etc.) will be handled on an “at-cost reimbursement” basis. All receipts will be kept for community audit at any time. Any and all surplus funds will be 100% returned to the DAO treasury.
In our reply, we also detailed our “more work for the same price” situation (a 25% timeline extension with 0% budget increase) and the rationale for the budget.
We believe this demonstrates our utmost sincerity and transparency. The vote has now seen 490M CKB participate, making it the highest-engagement governance proposal in the DAO’s history. The result is still extremely close at 61.29%. We urge everyone to read our full reply, to see our actions and commitments:
Hi everyone, a community member has voted NO for the v1.1 proposal, with the core reason being concerns about high estimates in the budget (e.g., domains’ cost).
After careful discussion, we have just posted a formal…
BTW that community member had one month more to raise those points, it feels just wrong to raise those type of concerns now…
Hi everyone, a community member has voted NO for the v1.1 proposal, with the core reason being concerns about high estimates in the budget (e.g., domains’ cost).
After careful discussion, we have just posted a formal…
I would also like to congratulate you on the participation this proposal reached in this voting phase
Phroi (No DM) (2025-11-02T22:00:31, Nervos Nation, edited 2025-11-02T22:47:32)
Now is almost 604 M CKB, just wow!! I really hope to see this kind of participation in the upcoming Proposals
BTW that community member had one month more to raise those points, it feels just wrong to raise those type of concerns now…
Hi Phroi, thanks for your continuous support. The voter said s/he only saw the proposal in a recent WeChat article. So, it’s an example of the information silos we’re trying to fix with v1.1, ensuring everyone sees the proposal discussion as early as possible.
Hi Phroi, thanks for your continuous support. The voter said s/he only saw the proposal in a recent WeChat article. So, it’s an example of the information silos we’re trying to fix with v1.1, ensuring everyone sees th…
I’ll keep an eye on how you achieve that, it’s an interesting problem. Feel free to drop a link to the repo whenever you feel ready
We are in the FINAL HOUR of the DAO v1.1 vote. Right now, the approval rate is 65.08%, just shy of the 67% needed to pass.
We have just seen a significant “NO” vote cast, which moved the needle, but it was cast without any comment.
We respect every voter’s decision. For the past month, the team has done everything possible to respond to, clarify, and amend the proposal in response to every public concern raised.
If you are one of the members who voted NO, we sincerely ask: Would you be willing to share your reason? Is there a critical flaw we’ve missed?
If there is, even in this last hour, we want to hear it.
If you support this proposal and have not yet voted: This is the final call.
The 7-day vote for the DAO v1.1 proposal has officially concluded.
In the end, 527,873,238 CKB participated and the proposal received 65.08% approval, which did not meet the 67% threshold required for a meta-rule change. According to the rules, the DAO v1.1 proposal has not passed.
We fully accept and respect this democratic decision from the community.
Although the proposal itself did not pass, we want to state that what we experienced together over the past month has been an incredibly successful governance event. In this vote:
The total participating CKB peaked at 603 million, representing 8.4% of the entire Nervos DAO.
This was, without question, the highest-engagement, most in-depth, and most intense public debate in the CKB Community Fund DAO’s history.
We succeeded in refocusing the entire community’s attention on a deep discussion about the future of the DAO. We re-engaged dormant voters and sparked a genuine debate about the DAO’s core bottlenecks. For this alone, all our efforts were worthwhile.
Our Deepest Gratitude
We want to extend our sincere gratitude to every single participant:
To everyone who voted YES, thank you. Your trust and support were the fuel that kept us going until the very last minute.
We must also thank everyone who voted NO and those who offered sharp critiques and rigorous scrutiny. Your challenges (on the budget, the process, and the core premise) are the most valuable check and balance in DAO governance. You forced us to constantly refine our thinking and made this debate truly meaningful.
Thank you to everyone who joined the discussions on Talk, Telegram, and Twitter.
What’s Next
While the v1.1 proposal did not pass, the problems it sought to solve have not disappeared.
The issue of the DAO’s stagnation is still in front of us. The proposal team will take a short break, and we will carefully review all the disagreements and consensus points that emerged during this vote.
Our commitment to the CKB ecosystem is unchanged, and our exploration of DAO governance will not stop. We believe the community will draw strength from this profound discussion, and that a more mature v1.2 or v2.0 proposal that can achieve broader consensus will emerge in the future.
The investigation confirmed a Metaforo vulnerability allowing duplicate voting, involving over 71 million CKB in weight. The final result reflects votes after removing duplicates.
We thank those who raised concerns, the investigation teams, and all voters. This experience proves the community chose to investigate truth over covering problems, to correct results over maintaining surface consensus.
This also validates what our proposal advocated: the community needs our own governance infrastructure.
DAO Transitional Period Policy Announcement
DAO Funds Management Committee releases transitional arrangements (until v1.1 takes effect): Proposals accepted during transition, processed under v1.0 rules Metaforo vulnerability being fixed; manual verification if needed No new meta-rule proposals during transition @zz_tovarishch (Talk account) is responsible for daily coordination
*Terry will personally donate CKB and reach out to other donors to help v1.0-approved projects navigate price volatility.
Recruitment | DAO v1.1 Inaugural Steward Team Members
Seeking community members to provide professional services to the DAO: Proposal process coordination Milestone verification Governance communication $500 USD/month Deadline: Jan 15, 2025
Stewards serve, not decide. We expect and appreciate your enthusiasm, expertise and neutrality.
Apply here招募 Recruitment | DAO v1.1 首届物业团队成员 Inaugural Steward Team Members
DAO v1.1 Milestone 1 Infrastructure Expense Disclosure
Domains: $19.7
Servers: Test environment currently shares with BBS; dedicated test and production servers will be purchased before Milestone 2
Total expenses: $1…
DAO v1.1 Weekly Progress Report (12.24)
Dear community, we are launching regular updates on project progress. Starting this week, we will:
Publish weekly progress reports, including Dev Logs, steward team formation progress, and other important matters Organize bi-weekly AMAs to answer community questions and discuss project directions
These updates will continue until v1.1 mainnet officially launches and the DAO Stewards team formally takes over the platform’s daily operations. Through this approach, we hope to give the community complete visibility into the project’s progress and enable timely feedback.
This week’s dev progress: 15 commits across 4 repos Security fixes, editor optimization Management center, meta-rules docs live
Steward recruitment open
Test env: https://ccfdao.dev
DAO v1.1 AMA
Time: Dec 30, 2025
23:00 UTC+8
07:00 PST…
Reminder: DAO v1.1 AMA starts in 30 minutes
Time: 23:00 UTC+8 / 07:00 PST / 16:00 CET
Meeting link: https://meet.google.com/bgr-cmee-jzu
AI interpretation: 讯飞同传
Agenda includes dev progress update, steward recruitment update, and community Q&A.
Steward recruitment: 11 applications received, thank you community First member confirmed: Haoyang @haoyang94 (full-stack dev, Polkadot DAO experience) Recruitment open until Jan 15
The third week’s progress report for DAO v1.1 is here! We focused on developing core platform functionalities and the improvements of user experiences.
Progress: Proposal status filtering Markdown support optimization Meeting management features Personal governance records Documentation site integration Completion rate: 7/9 (78%) Test: https://ccfdao.dev
Thanks for raising this @C B and @phroi for the explanation.
You’re right that Metaforo only supports Neuron, which excludes JoyID users from participating in this vote. This vote follows v1.0 rules and uses available infrastructure. While not perfect, it’s the legitimate governance process for now. V1.1 platform (MVP, ongoing development) will support broader participation including JoyID users.
AFAIK no, once this vote conclude, this is a closed door. Question asked would be:
What would another proposal improve upon?
Community already expressed its vote, why we need to vote again?
…
For re-proposing, v1.0 rules don’t explicitly address whether proposals can be resubmitted after failing, or under what conditions.
Based on the defined process flow (Discussion Stage, Voting Stage, Execution Stage), a resubmitted proposal would logically need to go through the full process again, but this hasn’t been formally clarified. Moreover, questions like “what constitutes a meaningful revision” or “is re-voting on similar proposals appropriate” aren’t defined in the current rules.
If this scenario comes up, it would be a governance question for the community and DAO Funds Management Committee to address.
Thanks for raising this @C B and @phroi for the explanation.
You’re right that Metaforo only supports Neuron, which excludes JoyID users from participating in this vote. [This vote](https://talk.nervos.org/t/dis-ckb-i…
don’t you think it’s worth pausing proposals will the new version is up people like me can’t vote even if i want to
don’t you think it’s worth pausing proposals will the new version is up people like me can’t vote even if i want to
Hi C B, I understand your frustration. This is also one point of the motivation for the v1.1 proposal team to develop a new platform.
The transitional period policy was set by the DAO Funds Management Committee to bridge v1.0 and v1.1 governance. It allows proposals to continue under v1.0 rules rather than pausing the DAO entirely during development.
The Rosen Bridge proposal team chose to proceed under this policy. That’s their call as proposers, knowing the participation limitations.
Total voting weight cast: 241,208,439 CKB Quorum: 241,208,439 / 82,070,709 (met) Approval: 36.64% (51% required to pass) Time remaining: ~2 days
All community members with Nervos DAO deposits are eligible to participate. Whether you support or oppose, voting is the way to have your preference counted in the final outcome.
To keep the discussion evidence-based, I ran the open-source CKB DAO Watchdog. It cross-checks Metaforo-recorded voting weights against on-chain Nervos DAO deposit weights for each voter and flags discrepancies via need_review.
In the latest run (20260115064547, UTC+8), no discrepancies were flagged on either side (need_review = false). This indicates the Metaforo-recorded weights match the on-chain DAO deposit weights at the time of verification. (This check is about weight consistency, not identity attribution.)
Please feel free to discuss the proposal itself. If you suspect an issue, sharing concrete evidence will be appreciated and help everyone review.
On one hand, I’m happy that people are willing to participate in the voting. On the other hand, I’m worried about the increased threshold for DAOs. I hope this won’t make DAO proposals a thankless task, and perhaps DAO 1.1 will bring some improvements.
On one hand, I’m happy that people are willing to participate in the voting. On the other hand, I’m worried about the increased threshold for DAOs. I hope this won’t make DAO proposals a thankless task, and perhaps DA…
That’s why I really hope that CommunityDAO v1.1 will be nimble enough to be able to adapt to this ever changing voting landscape
This week, the platform pushed forward the integration testing of the core governance flow while improving milestone voting UX (voting details, error handling, and avoiding duplicate requests). The frontend also went through a round of architecture cleanup (unified logger, unified HTTP error handling, removing unused rich-text editor deps, CSS co-location). On the backend, vote tx creation is now integrated into proposal/task workflows. Relayer has completed a standalone demo and fixed sync issues, and will be integrated after the governance flow is fully wired. Docs added an English binding guide and more FAQs.
In today’s AMA, @haoyang94 mentioned that steward recruitment closed on Jan 15, interviews are in progress, and the roster will be announced alongside the DAO v1.1 launch.
Preliminary outcome: PASSED (Approval: 64.11%, Total voting weight: 515,967,370 CKB).
Next, I will run a post-close verification using CKB DAO Watchdog to cross-check Metaforo-recorded voting weights against on-chain Nervos DAO deposit weights, along with a manual check. I will share the verification logs with the committee for final confirmation of whether the result is valid per the process.
—
For visibility, DAO transition updates are also mirrored on X at https://x.com/CkbDaoUpdates (process/status updates only), rather than on my personal account.
The plan is to hand the account over to the DAO v1.1 Stewards team after launch.
On Metaforo we have a user named KevinW, this username was created on 30 October 2025 and (s)he voted vocally in the last two CommunityDAO proposals. Nothing wrong with that, except KevinW is NOT our estimeed Kevin Wang (see the message I’m replying to )
Now, if this user was discreet in voting, (s)he may have slipped under the radar unnoticed, but his/her actions are so flashy, that we can argue that (s)he is intentionally impersonating our esteemed Keving Wang:
On Rosen proposal (s)he voted No with 20 M CKB and (s)he was ostensibly the first user to vote
On DAO v1.1 proposal (s)he voted Yes with 20 M CKB and (s)he left a message:
The fact that we haven’t spent much money in three years is largely due to this terrible voting tool. Hopefully, it can be changed soon. so yes !
And indeed during the last vote, I talked with a lot of Community members, and all of them (except a single one) were convinced this user was our esteemed Kevin Wang and they were arguing on the why Kevin Wang voted against it.
So I was wondering:
What will be done to address this issue in the upcoming DAO v1.0 vote?
What will be done to address this kind of issues in the upcoming DAO v1.1?
On Metaforo we have a user named KevinW, this username was created on 30 October 2025 and (s)he voted vocally in the last two CommunityDAO proposal…
Hi Phroi,
On DAO v1.0 and v1.1, there is no rule that restricts display names or requires identity verification. Voting weight and validity come from on-chain Nervos DAO deposits, not from a display name. A display name resembling a known community member does not trigger any DAO rule or change the voting outcome.
As transitional coordinator, I don’t have the mandate to arbitrate identity disputes. Similarly, under the v1.1, Stewards are expected to facilitate process and information flows and execute what is written and approved, not to verify identities or adjudicate impersonation disputes, unless an explicit rule is introduced and approved by the community. However, I’d strongly caution against attributing votes to specific individuals based on display names, as that quickly becomes speculation and undermines procedural integrity.
If the community believes we need an explicit policy (for example, constraints on confusing display names, or an opt-in identity / reputation layer), the correct path is to submit a meta-rule proposal that defines scope, authority, privacy expectations, and failure modes. Until such a rule exists, it should not be treated as part of DAO governance under v1.0 or v1.1.
Personally, I agree that in the long run, a better system would combine on-chain stake weight with an opt-in reputation / Web5 DID system, but that requires careful design and explicit community consensus.
Is there any rule preventing CommunityDAO v1.1 from verifiably linking other platform profiles into CommunityDAO v1.1 profiles?
…
Correct. There is no DAO v1.0 / v1.1 rule that restricts display names, and there is also no rule preventing the v1.1 platform from supporting opt-in profile linking to other platforms.
This is primarily a product / Web5 DID feature, not a governance rule. Per the v1.1 proposal scope, the initial deliverables prioritize DID login and Nervos DAO address binding. Cross-platform profile linking (e.g., Talk/X/TG…) aligns with the broader profile-center design direction, but whether it lands in the first mainnet-ready release depends on implementation readiness. (Screenshot attached for the UI direction, not a scope guarantee)
Correct. There is no DAO v1.0 / v1.1 rule that restricts display names, and there is also no rule preventing the v1.1 platform from supporting opt-in profile linking to other platforms.
This is primarily a product /…
So long CommunityDAO v1.1 is open to PRs this feature will eventually land
Hey Phroi and @mattQuinn, thanks for the scrutiny! I’m haoyang, one of the DAO steward team member, yeah the name does sound scary , but I can assure you that this is just a naming issue, it works like this:
If you just staked your CKB, the DAO 1.1 platform needs a bit time to pull this information (currently set as once per day, UTC time); the “whitelist” is to speed up this process so testers (like me) can start testing without waiting. We just finished a meeting and agreed that the name is quite misleading, maybe “voter snapshot” would be better.
But rest assured, this does not mean only people in the whitelist can vote, everyone who staked CKB can, you can verify this once the platform is launched on testnet for community testing
Hey Phroi and @mattQuinn, thanks for the scrutiny! I’m haoyang, one of the DAO steward team member, yeah the name does sound scary , but I can assure you that this is just a naming issue, it works like this:
If you j…
Hey @haoyang94, nice to meet you and congratulations on the steward role Name change is welcomed. That said, I would try to explain more the:
Why do we even need a snapshot/whitelist of voters in the first place?
Issue: potential for long-term abuse and centralization is really high, so there must be an even better reason to introduce it in the first place (V1.0 indeed doesn’t have it)
Hypothetical Example:
In 2 years Donald Trump is elected in the yearly election for Community DAO v1.1 Roles as Vote Administrator and the other roles are filled by his evil lackeys
Now Trump is the one controlling both the Voter Snapshot tool and the on-chain cell representation.
Trump decides to ban all voters except for voters he controls.
Trump updates the on-chain representation of whitelist, cause he is the one who has the power to so and there is no rule saying that he cannot do that.
Now Trump fully controls CommunityDAO v1.1 until the next Community DAO v1.1 election
Trump wins all upcoming elections, cause they are gonna be based on Community DAO v1.1 votes he controls (right?)
…
Result: Trump owns Community DAO v1.1 treasury
I’m sure that you have pretty good reason to introduce it, so please explain to the Community your reasoning and the rules that underpins its usage. Also, what happens if these rules are violated?
Love & Peace, Phroi
haoyang li (2026-01-28T08:56:01, Nervos Network, edited 2026-01-28T13:57:38)
Hey @haoyang94, nice to meet you and congratulations on the steward role Name change is welcomed. That said, I would try to explain more the:
Why do we even need a snapshot/whitelist of voters in the first place?
…
Hi Phroi, totally valid scenario, and I just asked the dev team, they said this feature is only there for testing purpose, and it will be removed after the mainnet launch.
Although one thing I think worth clarifying is that the current whitelist mechanism doesn’t ban anyone from voting, it’s not like only the whitelisted addresses can vote, anyone with staked CKB can, the whitelist only accelerate the speed for the current system to find the information about who has staked CKB, it doesn’t prevent any addresses from voting.
Phroi (No DM) (2026-01-28T18:46:31, Nervos Network, edited 2026-01-28T18:55:28)
Hi Phroi, totally valid scenario, and I just asked the dev team, they said this feature is only there for testing purpose, and it will be removed after the mainnet launch.
Although one thing I think worth clarifying i…
Hey @haoyang94 That’s very reassuring, thank you!! So glad to see this cleared up! Just to make sure that we are all on the same page, could your team update the Docs to reflect this change?
May I additionally suggest that if something exists only for testing purpose and it will not be in production, clearly label it as non-production / testing-only in Docs. This way by reading the Docs all the Community can clearly understand how CommunityDAO v1.1 is gonna work.
Also please, remember to tag me on the progress made to clear up this misunderstanding, I’d like to keep an eye on this.
Hey community, this is our weekly DAO v1.1 progress update. In addition to the dev log, we are announcing two key items this week, aligned with the proposal timeline:
DAO v1.1 will enter the official public community beta starting this week. The beta is expected to run for about one month, so we can collect feedback and converge before final delivery.
The inaugural Steward Team roster is finalized and published in this post, so the community has clear coordination points during the beta.
Hey! Thanks for those who attended our DAO v1.1 Bi-Weekly AMA today, for those who can’t attend it we have also prepared the following resources so you can know what has been done, and the future plans.
**
To summarize**:
We announced the steward team for the first year: Shawn (a.k.a NightLantern), Hongzhou (@zz_tovarishch), and Haoyang (@haoyang94)
We the steward team is preparing a steward operation manual that will be published after the mainnet launch to detail the responsibilities of the steward team
DAO v1.1 is about to publish to the community for testing
For the Web5 part: the first batch of basic services are completed and would be deployed soon for everyone to experience; the Relayer has been completed for BBS, after the DAO mainnet launch, the team will bridge BBS and DAO.
DAO 1.1 Mainnet Countdown — Live by End of February!
Thanks to everyone who joined the AMA today. Here‘s what you need to know
—
Dev Update: Testing Wraps Up + Relayer Live
• Full voting flow tested (edge cases, UI/UX, exceptions)
• Relayer integrated: BBS ⇄ DAO accounts connected
• PW Lock voting weight now supported
• Final testing in progress
—
Confirmed Timeline: Mainnet Ready End of Feb
• Feb 14 – Quasi-production deployment (mainnet simulation)
• Mid‑Late Feb – Mainnet environment testing
• End of Feb – Public launch & proposals open
—
Steward Team: Docs & Assets on Track
• Four core docs drafted:
– Steward Operation Manual
– Community Guidance Doc
– Bug Report Template
– Milestone Tracking Doc (for community to inspect on proposal team’s progress)
• Onboarding video + Poster — due Feb 24
• All materials launch together with the platform
What’s up, everyone? We’re super pumped to drop the news: the CKB Community Fund DAO V1.1 is officially going live on March 16! It’s a solid upgrade that’s all about transparency and Dao oversight, operations, and execution.
To kick things off without going overboard, we’ve got a chill launch event lined up. It’s the perfect spot to hang out, chat about what’s new, and get everyone on the same page for this next phase.
Oh, and as part of the fun, we’re rolling out some handy docs to help you dive right in:
DAO V1.1 Steward Operational Manual: Your go-to guide for stewards on handling the day-to-day, keeping everything fair and fun. Community Guidance Doc: Easy tips for jumping in, throwing out proposals, and making the most of the DAO tools. Community Bug Report Doc: Simple steps to spot glitches, report 'em, and help us squash 'em quick. Milestone Tracking Doc: A straightforward way to keep tabs on wins, progress, and what’s coming up next.
Come join the party—your thoughts and energy are what make this community rock
Replying to this message from Neon (if I DM I scam):
When will it be suitable for use by projects? I know @phroi was testing it
Thank you for the question @Neonckb!! This is my latest comment on the thing: as you can see I was not able to test it properly (my did still display zero voting power)
ahh okay okay, from what i understand the platform has been rigorously tested now, and all known errors have been amended. Prob a response to your question was a slight overlook. they have been working quite late getting everything together for the launch and its about the middle of the night for the other stewards— I kindly ask you remain patient a little for them to wake up in the morning
ahh okay okay, from what i understand the platform has been rigorously tested now, and all known errors have been amended. Prob a response to your question was a slight overlook. they have been working quite late get…
Hi Phroi, totally valid scenario, and I just asked the dev team, they said this feature is only there for testing purpose, and it will be removed after the mainnet launch.
Although one thing I think worth clarifying is that the current whitelist mechanism doesn’t ban anyone from voting, it’s not like only the whitelisted addresses can vote, anyone with staked CKB can, the whitelist only accelerate the speed for the current system to find the information about who has staked CKB, it doesn’t prevent any addresses from voting.
Hi Phroi, totally valid scenario, and I just asked the dev team, they said this feature is only there for testing purpose, and it will be removed after the mainnet launch.
Although one thing I think worth clarifying i…
I appreciate you expending your time to test and making sure everything is where it needs to be phroi
In the post it shows the docs to be released with the launch, so maybe those aren’t the updated ones. Let’s be patient and wait for the other stewards to wake up— is there anything else i can try to answer for you?
In the post it shows the docs to be released with the launch, so maybe those aren’t the updated ones. Let’s be patient and wait for the other stewards to wake up— is there anything else i can try to answer for you?
Hey Phroi and @mattQuinn, thanks for the scrutiny! I’m haoyang, one of the DAO steward team member, yeah the name does sound scary , but I can assure you that this is just a naming issue, it works like this:
If you just staked your CKB, the DAO 1.1 platform needs a bit time to pull this information (currently set as once per day, UTC time); the “whitelist” is to speed up this process so testers (like me) can start testing without waiting. We just finished a meeting and agreed that the name is quite misleading, maybe “voter snapshot” would be better.
But rest assured, this does not mean only people in the whitelist can vote, everyone who staked CKB can, you can verify this once the platform is launched on testnet for community testing
Hey Phroi and @mattQuinn, thanks for the scrutiny! I’m haoyang, one of the DAO steward team member, yeah the name does sound scary , but I can assure you that this is just a naming issue, it works like this:
If you j…
Forwarded from Phroi (No DM).
Hey @haoyang94, nice to meet you and congratulations on the steward role Name change is welcomed. That said, I would try to explain more the:
Why do we even need a snapshot/whitelist of voters in the first place?
Issue: potential for long-term abuse and centralization is really high, so there must be an even better reason to introduce it in the first place (V1.0 indeed doesn’t have it)
Hypothetical Example:
In 2 years Donald Trump is elected in the yearly election for Community DAO v1.1 Roles as Vote Administrator and the other roles are filled by his evil lackeys
Now Trump is the one controlling both the Voter Snapshot tool and the on-chain cell representation.
Trump decides to ban all voters except for voters he controls.
Trump updates the on-chain representation of whitelist, cause he is the one who has the power to so and there is no rule saying that he cannot do that.
Now Trump fully controls CommunityDAO v1.1 until the next Community DAO v1.1 election
Trump wins all upcoming elections, cause they are gonna be based on Community DAO v1.1 votes he controls (right?)
…
Result: Trump owns Community DAO v1.1 treasury
I’m sure that you have pretty good reason to introduce it, so please explain to the Community your reasoning and the rules that underpins its usage. Also, what happens if these rules are violated?
Hey @haoyang94, nice to meet you and congratulations on the steward role Name change is welcomed. That said, I would try to explain more the:
Why do we even need a snapshot/whitelist of voters in the first place?
…
Forwarded from haoyang li.
Hi Phroi, totally valid scenario, and I just asked the dev team, they said this feature is only there for testing purpose, and it will be removed after the mainnet launch.
Although one thing I think worth clarifying is that the current whitelist mechanism doesn’t ban anyone from voting, it’s not like only the whitelisted addresses can vote, anyone with staked CKB can, the whitelist only accelerate the speed for the current system to find the information about who has staked CKB, it doesn’t prevent any addresses from voting.
Phroi (No DM) (2026-03-15T21:06:27, Nervos Nation, edited 2026-03-16T12:00:30)
Hi Phroi, totally valid scenario, and I just asked the dev team, they said this feature is only there for testing purpose, and it will be removed after the mainnet launch.
Although one thing I think worth clarifying i…
Forwarded from Phroi (No DM).
Hey @haoyang94 That’s very reassuring, thank you!! So glad to see this cleared up! Just to make sure that we are all on the same page, could your team update the Docs to reflect this change?
May I additionally suggest that if something exists only for testing purpose and it will not be in production, clearly label it as non-production / testing-only in Docs. This way by reading the Docs all the Community can clearly understand how CommunityDAO v1.1 is gonna work.
Also please, remember to tag me on the progress made to clear up this misunderstanding, I’d like to keep an eye on this.
no but there is some what of an accusatory tone here.. I’m not saying this isn’t important but @phroi was told this would be amended— so why would we think otherwise? why not just wait for the other stewards who have the information before jumping to any conclusions
no but there is some what of an accusatory tone here.. I’m not saying this isn’t important but @phroi was told this would be amended— so why would we think otherwise? why not just wait for the other stewards who have…
The emdash… Issue is that this issue was raised 2 months ago, then in the last review too 8 days ago and still no response on factual actions take to address the issue
The reason why I say the importance was misjudged is that it hasn’t been addressed in comms prior to launch stuff
well I think lets wait to hear from haoyang li and tovarishch before we go on a tangent with potential false premises wouldn’t you agree? haoyang did directly tell phroi the whitelist wouldn’t be on main net. So I don’t see why we wouldn’t believe him? But hey if thats not the case, i totally agree we want a fair transparent dao— Nothing less!!!
well I think lets wait to hear from haoyang li and tovarishch before we go on a tangent with potential false premises wouldn’t you agree? haoyang did directly tell phroi the whitelist wouldn’t be on main net. So I don…
well I think lets wait to hear from haoyang li and tovarishch before we go on a tangent with potential false premises wouldn’t you agree? haoyang did directly tell phroi the whitelist wouldn’t be on main net. So I don…
I think both sides are valid things to say right now
Night Lantern (2026-03-15T21:35:46, Nervos Nation, edited 2026-03-16T01:01:48)
look i think we all want the same thing… having the public docs fully update in hindsight would have been best but lets wait to get the facts instead of running on any false premises
look i think we all want the same thing… having the public docs fully update in hindsight would have been best but lets wait to get the facts instead of running on any false premises
People are just operating on the premise they have
look i think we all want the same thing… having the public docs fully update in hindsight would have been best but lets wait to get the facts instead of running on any false premises
Glad we agree, then just tell us: I look up this tomorrow with the team, if still not fixed, we will need to delay.
The whitelist issue seems more like a mechanism design problem to me, not a technical issue, as it seems not to be an incorrect implementation, but designed to so. I’m curious how was the dao v1.1 mechanism design decisions formed?
The whitelist issue seems more like a mechanism design problem to me, not a technical issue, as it seems not to be an incorrect implementation, but designed to so. I’m curious how was the dao v1.1 mechanism design dec…
Another one that I documented: Governance identity (private signing key of Web5 DID) are stored unencrypted in browser localStorage.
All this with no mandatory backup and no browser native way to store it in a password manager. A passkey could have been a nice touch. Instead we get the following:
You clear cache? Lost access to Web5 account
You lost device? Lost access to Web5 account
Bad script read your local storage? Compromised Web5 account
Phroi (No DM) (2026-03-16T13:47:33, Nervos Nation, edited 2026-03-16T20:13:41)
Bind UTXO Global address to another address and then vote with that
For example:
If Alice (100,000 CKB in DAO, DID 1) binds to Bob (50,000 CKB, DID 2) and both vote: Alice’s weight is 100,000 and Bob’s weight is 150,000 (own 50,000 + bound 100,000). Total counted: 250,000 from 150,000 real CKB
Phroi (No DM) (2026-03-16T16:06:15, Nervos Nation, edited 2026-03-16T16:16:22)
For anyone following this DAO v1.1 journey, @rink1969 has replied:
Phroi (No DM) (2026-03-16T16:12:49, Nervos Nation, edited 2026-03-16T17:01:16)
@rink1969 I’ll start preparing the next round of audit
Phroi (No DM) (2026-03-16T21:35:58, Nervos Nation, edited 2026-03-17T01:48:27)
Hey @rink1969, worked all day for this audit, so here you go! Additionally to the previous unsolved issues I also found by chance a SQL Injection attack:
Anyone can read the entire PostgreSQL database, freeze the service, or identify admin accounts (to later steal funds), all without logging in.
DAO V1.1 Platform Launch Sync
Following today’s community discussion on the V1.1 platform, here is a summary of developments:
1 Phroi published a code review of the V1.1 platform, covering the voter whitelist mechanism and additional findings across the codebase
2 David responded to the whitelist questions, clarifying the technical rationale and the earlier miscommunication involving two separate whitelist mechanisms
3 The Proposal & Steward team published a statement:
March 16 launch is postponed; M2 delivery standard not yet met
4-week public testing period begins this week
Independent chain-reading audit tool to be developed
The AMA will proceed as scheduled with an adjusted agenda focused on the audit findings.
The dev team has addressed the bugs from Phroi’s code review, and will publish a detailed post on the design decisions behind the whitelist mechanism for community discussion
Weekly text-based AMAs will replace live sessions during the testing period
All details, feedback, and issue tracking will be centralized in this Nervos Talk thread going forward:
Phroi (No DM) (2026-03-18T23:16:59, Nervos Nation, edited 2026-03-19T05:39:41)
Hey @rink1969, worked all day for this audit, so here you go! Additionally to the previous unsolved issues I also found by chance a SQL Injection attack:
*Anyone can read the entire PostgreSQL database, freeze th…
Hey @rink1969!! Let me give you some informal feedback: I’m pleased to see that little by little you are fixing the issues I pointed out over time, more days more fixes, nice!! (with one catch)
Hey @rink1969, worked all day for this audit, so here you go! Additionally to the previous unsolved issues I also found by chance a SQL Injection attack:
*Anyone can read the entire PostgreSQL database, freeze th…
SQL injection (N1) is fixed. All 5 Expr::cust(format!(...)) sites replaced with parameterized Expr::cust_with_values(...), and the error handler no longer leaks raw PostgreSQL messages.
There was an attempted fix to double vote Mod-alike exploit, but the fix itself seems broken.
The retain filter at check_vote_finished.rs:596-598 was meant to prevent the same deposit from counting twice across voters, but the condition voter_ckb_addr != weight_addr unconditionally removes every voter’s own weight. Any standalone voter (the common case) contributes zero to the tally. The UI still shows correct voting power, and the on-chain TX succeeds, so voters have no signal their vote counts for nothing.
The whitelist issue seems more like a mechanism design problem to me, not a technical issue, as it seems not to be an incorrect implementation, but designed to so. I’m curious how was the dao v1.1 mechanism design dec…
About voter whitelist (SMT-based, requiring Web5 DID registration + daily snapshot inclusion), it was not described in the governance rules voted on by the community. The proposal’s voting section states:
Voting power is based entirely on the user’s CKB deposits in the Nervos DAO, continuing the direct weighted voting model of v1.0.
The only mention of “whitelist” is a sub-item in the development cost table:
No description of what the whitelist is or how it restricts eligibility. This line was present unchanged since the original post on Sep 4, 2025 (verified across all 21 proposal revisions).
Under the DAO rules ( CKB Community Fund DAO Rules and Process ), changes to voting eligibility are meta-rule changes requiring 67% approval and 185M CKB quorum.
No such vote was held for this mechanism
Phroi (No DM) (2026-03-20T15:43:49, Nervos Nation, edited 2026-03-20T17:47:23)
@rink1969 All in all good progress on the fixes, appreciate the dialogue.
I have a report ready, will share once that regression is sorted.
Keep it up
Phroi
Night Lantern (2026-03-21T01:06:29, Nervos Network, edited 2026-03-21T01:06:35)
Hello everyone!
Join us in the CKB DAO V1.1 platform community testing period!
Your crucial insights and discussions on these pivotal design choices will help strengthen the DAO’s longevity—your feedback and participation are truly priceless.
Moving forward, we’d love to streamline most of the conversation right here:
@phroi I noticed you mentioned about alternative designs to whitelist for dao v1.1, I would like to make a proper post but in case you beat me to it, here are my ideas:
-take a DAO deposit cell as a reference cell
-verify exclusion proof for deposit cell in a SMT
-verify inclusion proof for deposit cell in SMT, update SMT root
-generate the vote UDTs
(Some logic is needed around deposit lock script verifying and binding)
In this way, vote UDT’s are optional. We never need to remove spent deposit cells from the SMT, however the proof size will grow as the number of deposits tracked by the SMT grows.
Maybe we could have a new SMT for every 100,000 blocks or something like that?
For instance, if we have a MMR of SMT’s, every 100,000 blocks a new SMT would be added to the MMR and users would do their proofs against the proper leaf of the MMR.
the MMR will add overhead to the proof, the right tradeoff between # of blocks per MMR leaf and additional overhead from MMR would have to be determined
(Vote sUDTs would be non-transferable and anyone can claim the underlying CKB with proof the referenced dao deposit was spent)
@phroi I noticed you mentioned about alternative designs to whitelist for dao v1.1, I would like to make a proper post but in case you beat me to it, here are my ideas:
-take a DAO deposit cell as a reference cell
-ve…
Just a question: what’s difference with using iCKB UDT directly?
Well the user keeps control of the ckb, not a contract
About this, iCKB main contract is rock solid AFAIK (maybe I’ll also audit those contracts once again with these new powerful tools, few days that I’m thinking about it), so using iCKB should be as safe as the underlying Nervos DAO deposits
If I was to launch the DIS for DAO v1.2, I would personally go for iCKB only, locking up iCKB to vote.
This would be fully on-chain, skip all the problems currently affecting v1.1, including those stemming from th…
just from a vanilla users perspective its seems simpler to just deposit CKB. That’s what was nice about the joyid paradigm— cipher had in mind regular every day users, even though it didn’t fully pan out his vision had accounted for the masses. I think for these reasons we should be doing our best to keep things as simple as possible. And at least not require users to have to switch there CKB to iCKB. but as you say seems there’s some technical benefits, not sure if i think that tips the scales for me though
just from a vanilla users perspective its seems simpler to just deposit CKB. That’s what was nice about the joyid paradigm— cipher had in mind regular every day users, even though it didn’t fully pan out his vision ha…
User doesn’t even need to know they are using iCKB, you go from CKB to vote in a single tx
yeah i think if it comes off like your just using your regular CKB i have not particular qualms about it
Biggest issue with what v1.1 is doing is that v1.1 is not controlling the lock of the users deposits, so users can withdraw / rebind … midvote, it’s very messy
This coupled with the fact that Nervos L1 doesn’t have a state root on-chain (we have something, but just for headers) means you have to rely on bulky off-chain operations.
These bulky off-chain operations are not made easy by CKB Node, cause the node doesn’t even support archive mode. In short you cannot query how was the cell set at a particular block, say for example when the vote ended, crucially.
It means implementing bulky off-chain operations from scratch, but then you also need to have auditors, which ideally use a separate stack… it gets messy.
Biggest issue with what v1.1 is doing is that v1.1 is not controlling the lock of the users deposits, so users can withdraw / rebind … midvote, it’s very messy
This coupled with the fact that Nervos L1 doesn’t have…
from what i understood your right they can withdraw and rebind midvote.. but its redundant because only the last vote cast is accounted for. although I’m not certain of what and any ramifications this would cause?
Phroi (No DM) (2026-03-21T22:39:41, Nervos Nation, edited 2026-03-21T22:40:17)
from what i understood your right they can withdraw and rebind midvote.. but its redundant because only the last vote cast is accounted for. although I’m not certain of what and any ramifications this would cause?
Say you want to account for this on-chain, attacker can make enough of these actions that you run out of block space
Phroi (No DM) (2026-03-21T22:40:03, Nervos Nation, edited 2026-03-22T13:56:52)
I’m still shocked that normal user actually hacked MetaForo out of spite over this proposal!! I had my reservations, but at least I’m trying to contribute in a concise & positive way. Wild times
@zz_tovarishch if you want to reduce the chance of future hacks on Community Fund DAO v1.1, would you like me to do a step-by-step review? Anyone else from the community want to review?
Also, since you showed proof your proposal won, can you start by open-sourcing the work being done?
Biggest issue with what v1.1 is doing is that v1.1 is not controlling the lock of the users deposits, so users can withdraw / rebind … midvote, it’s very messy
This coupled with the fact that Nervos L1 doesn’t have…
I am not sure if this will be related , but I wish, this DAO thing could also be used as the organization of the first testers and Users of the applications being built on Nervos CKB Ecosystem. This will enable developers to get initial users and testers who are committed to providing feedback on their usage of applications. We dont expect the apps to be adopted from outside inside, but better inside outside.
I am not sure if this will be related , but I wish, this DAO thing could also be used as the organization of the first testers and Users of the applications being built on Nervos CKB Ecosystem. This will enable develo…
@BaClaire Your message got me thinking, so I reviewed the V1.1 identity layer to see how close did:ckb is to serving the broader ecosystem.
Short answer: the foundation is there. did:ckb is chain-native, the source code is open, and anyone can run the DID indexer. A second app on CKB could resolve your identity today. CCC even has an unmerged branch (feat/did-ckb) with SDK functions for creating, updating, and destroying DID cells.
What’s not wired up yet: DID document updates (so one identity registers with multiple apps), account portability (so users are not locked to one server), and key management beyond browser localStorage.
Phroi (No DM) (2026-03-26T10:33:46, Nervos Nation, edited 2026-03-26T10:48:55)
Hey @NightLantern100, let me reply here: I don’t use voice or video channels, also I’m not on social media. I’m much more at ease writing, so I’ll keep responding on Nervos Talk and here as usual
@phroi hey phroi, I’m trying to organize a informal live public discord Ama for you to discuss design choices with the Daov1.1 team. when are you available ?
Hey @NightLantern100, let me reply here: I don’t use voice or video channels, also I’m not on social media. I’m much more at ease writing, so I’ll keep responding on Nervos Talk and here as usual
ohh i see, yea the discord channel is text not voice so your good to go (:
Neon (if I DM I scam) (2026-03-26T15:23:09, Nervos Nation, edited 2026-03-26T15:31:53)
If it’s quite a technical discussion it’s best done asynchronously right? So people have time to construct their responses
Night Lantern (2026-03-26T16:30:45, Nervos Nation, edited 2026-03-26T16:38:53)
okay so is the community consensus we just stick to talks then?
The whitelist issue seems more like a mechanism design problem to me, not a technical issue, as it seems not to be an incorrect implementation, but designed to so. I’m curious how was the dao v1.1 mechanism design dec…
Sigh, I came to same realization about the DAO v1.1 DID implementation
Using AT Protocol will only lead to centralization, see all the issues. NOSTR is the real decentralized alternative:
AT Protocol compatibility was never a consideration: their paths diverge. Bluesky explicitly stated they won’t partner with any specific blockchain project.
to be clear, what I was trying to point out is the communication gap - it seemed like that one was challenging the mechanism and the other was explaining code.
I’m fine with trade-offs especially when we know it’s not the eventual DAO. Like dao v1.0 it stated clear the goal was to kickoff and simplicity-focused and had to accept some trade-offs.
I support building stuffs gradually, however the trade-offs should be explained clearly, why these trade-offs are made. The communication should try to eliminate any discrepancies between what’s perceived and what it actually is. Notice: all these are the responsibility for the role of the project lead, not the dev lead. Dev leads can debate vim vs emacs forever and those are all good opinions. The project lead need to make decisions and trade-offs based on the goal, timeline and resource constraints, make sure intentions and reasonings are well communicated.
To me v1.1 is better than v1.0, its voting is much better than metaforo. However this could turn into another ‘which tech is the most decentralized debate’ and lock the ckb community on metaforo for another year, if the v1.1 team leadership can’t handle it well
Phroi (No DM) (2026-03-30T01:22:57, Nervos Nation, edited 2026-03-30T01:56:55)
to be clear, what I was trying to point out is the communication gap - it seemed like that one was challenging the mechanism and the other was explaining code.
I’m fine with trade-offs especially when we know it’s not…
As independent DAO v1.1 observer, did you review the process & code?
I need to say code, cause the documentation timeline is a bit strange:
Documentation only functions as a retrospective documentation of an already coded system, not a design plan released in time for any meaningful public feedback.
Before starting the code review, I had your same opinion. Now I’m not so sure:
Voter eligibility is still decided off-chain by operator-run services, so the most important governance boundary is not trustless (This will need a meta vote in itself, cause it changes eligibility rules)
Casting a vote still depends on operator-issued proof data, so participation is not permission-less once the system is live (System literally needs to reply “I have you on my list, here is the proof”. System forgets to reply? You can not even prove your were excluded from the vote)
Vote counting and weight resolution is so complex that I found a double counting vulnerability. Add to that there still is no audit tool, so currently corrupted database = corrupted vote (We have that document from 10 days ago tho)
I believe we’re not talking about the same thing. For example, it appears to me you were challenging the mechanism (through code review) but v1.1 team was explaining the code, because it was always v1.1 dev lead answering questions. I’m not sure if I misunderstood but dev lead is usually not the owner of a project.
I fully support your code review and challenges to dao v1.1. I just don’t see how it can be solved on the code review and developer vs developer level.
Phroi (No DM) (2026-03-30T15:01:49, Nervos Nation, edited 2026-03-31T16:49:42)
I believe we’re not talking about the same thing. For example, it appears to me you were challenging the mechanism (through code review) but v1.1 team was explaining the code, because it was always v1.1 dev lead answe…
So glad you enjoyed them, happy to review code of public interest and educate the Community! Whoever wants to thoughtfully reply to my posts is more than welcomed
So glad you enjoyed them, happy to review code of public interest and educate the Community! Whoever wants to thoughtfully reply to my posts is more than welcomed
Taking a step back, we have a 3 person DAO v1.0…
Thanks for raising this, Phroi.
On your first question: the proposal & steward team’s Mar 17 statement acknowledged that the platform has not yet met the delivery standard for Milestone 2. A 4-week public testing period is underway and still ongoing. At the end of the testing period, the steward team will submit a Milestone 2 verification report.
On the second: under the v1.0 staged payment amendment, proposals exceeding $10,000 are paid in stages, with evaluations and confirmations at the end of each stage. The proposer is required to submit progress reports covering milestones, deliverables, and fund utilization. Once the 4-week testing period concludes and the report is published, this process will proceed accordingly. I’ll be coordinating with the committee on the specifics.
Thank you for the reply! I was wondering, as transitional period coordinator, could you clarify how are these verification reports reviewed?
For example, yesterday I noticed that [Milestone 0 included this very…
Under v1.0, the staged payment amendment requires proposers to submit progress reports at each milestone, and for evaluations and confirmations to be conducted at the end of each stage. The amendment does not specify a formal review body or verification procedure.
In practice, milestone reports of projects under 1.0 are published on Nervos Talk for community feedback, with the committee handling disbursement.
Under v1.0, the staged payment amendment requires proposers to submit progress reports at each milestone, and for evaluations and confirmations to be conducted at the end of each stage. The amendment does not specify…
May I ask for your team to the deliver the complete technical architecture design document that was due for M0?
Idea: not only how/why things works in DAO v1.1, but especially why such controversial design choices were made and why alternatives were deemed worse than the current design.
On how the M2 verification report will be conducted specifically, @haoyang94 can speak to that as the steward team’s ops lead.
BTW there is a clear conflict of interest: the team responsible for reviewing the project and establishing acceptance criteria is the same team that developed it
I would be surprised if the Transitional Period Coordinator role was deliberately assigned by the DAO v1.0 committee to permit this arrangement.
Accordingly, I respectfully request that the three-member DAO v1.0 committee (@busyforking, @terrytai, & @cipherw), in consultation with the Transitional Period Coordinator (@zz_tovarishch & his delegate @haoyang94), to carefully consider and clarify the procedures for the forthcoming review, given the problems already encountered during the DAO v1.1 M0–M1 review.
I’m considering a Nervos Talk post to make this request formally public
BTW there is a clear conflict of interest: the team responsible for reviewing the project and establishing acceptance criteria is the same team that developed it
I would be surprised if the [Transitional Period…
That’s a fair concern to raise formally. A Talk post would make sure the committee sees it and can respond properly.
One small correction: Haoyang is the steward team’s ops lead, not my delegate.
BTW there is a clear conflict of interest: the team responsible for reviewing the project and establishing acceptance criteria is the same team that developed it
I would be surprised if the [Transitional Period…
There might be a few misunderstandings, but the logic here is as follows. Let me first introduce myself. I am Baiyu, the person in charge of this proposal. Because I am also the head of the eco fund, I was worried that my position as the person in charge might affect the proposal, so I haven’t discussed it much before.
Fisrt, DAO1.1The initial goal was to replace the existing voting tool without making any rule changes. If there was any change, it would be only one: bringing in a property steward team to assist in implementation according to the meta-rules. Before to this proposal,this is how DAO works: there is a three-person committee, and then Jacky handles daily tasks.But Jacky role is not very clear. And how he get paid for those work, who is he responsible for?
Then, my team put forward this proposal. As everyone knows, during the proposal process, a problem occurred with the voting statistics, which is precisely a technical issue with the existing platform.
Why is there a transition member? What are his responsibilities? As I understand it, because this proposal 1.1 has not yet taken effect, we cannot judge ourselves, so the old 1.0 needs to continue, hence the need for a transition merber appointed by the three-person committee
Furthermore, in my vision, even if this proposal passes, our team’s three-person property management team will not replace the existing three-person committee. Instead, The three of them, including myself, are more like handling the work that Jackie used to do, and the work that the transition committee is doing now. We don’t want to, and have no reason to, do what the three-person committee does.
Therefore, from beginning to end, in my mind, this proposal wasn’t about completely changing the existing system. I believe our team’s boundaries are defined by the proposal itself. Our idea was to switch to a different technology platform and improve the work of the person responsible for daily execution under the three-person committee.
Through recent discussions, I’ve noticed a lot of misunderstanding within the community regarding the boundaries of the work between the proposal team and our established steward team, leading to numerous assumptions. For example, our team initially wanted to know that, as the proposal team developing the new platform, after completion, we intended to deliver the code and have someone else deploy and maintain the platform. However, after discussions, I found no one could answer my questions. I told the team, “Okay, it’s certainly not easy for others to maintain it. We’ll continue investing and maintain it for a year first.” But in reality, we believe that after completion, we should deliver the code, and The community needs domain administrators, people to deploy and maintain the platform, and a mechanism to incentivize and monitor them. But we don’t have that now. Because we wrote the proposal and developed the code, we need to continue maintaining it. Since we both develop and control the servers, but we’re not a true three-person committee, it’s difficult to gain trust.
What I’m trying to say is that this proposal is just an attempt to make the community voting platform and the process for monitoring proposal milestones a little bit better, a small step forward, not a one-step solution. That’s why we’ve retained the three-person committee and haven’t pursued full automation of voting funding.
The initiative proposed by Phroi to check proposal team milestone deliverables highlights the shortcomings of the old system, which is what our proposal aims to address.
Developing such a complex system is no easy task, but we are willing to accept the challenges from the community. If there are any areas that don’t meet the delivery requirements, we will correct them. Therefore, after Phori raised the issue last time, the team immediately made changes. In fact, because of our passion and eagerness, we started researching even before the proposal was even submitted The team members have already invested a lot of effort and time; in fact, the development costs have long exceeded the budget. Of course, this is because we underestimated the difficulty when we wrote the proposal; it’s my fault, and I will take responsibility.I hope everyone can be more understanding as we work together to improve the community, little by little. For example, I had to use translation software to write this, so the English meaning might not be entirely accurate; I hope you can understand.
Fisrt, DAO1.1The initial goal was to replace the existing voting tool without making any rule changes. If there was any change, it would be only one: bringing in a property steward team to assist in implementation acc…
Of course, this was just my initial wish. However, during community discussions, we realized community thought that our proposal involved changes to meta-rules, so I decided to vote on it by metarule. Since it involved meta-rules changes, we also incorporated community feedback, such as adding stablecoin payments. I remember this was suggested by Phroi. Finally, I want to emphasize that although the vote is based on meta-rules, we only want to replace the technology platform and add a steward team. We don’t want to replace the three-person committee, operate the servers, manage the treasury, etc. We are simply a proposal team.
Fisrt, DAO1.1The initial goal was to replace the existing voting tool without making any rule changes. If there was any change, it would be only one: bringing in a property steward team to assist in implementation acc…
An additional clarification on what Baiyu mentioned about rule changes: the V1.1 proposal was classified as a meta-rule change during the community discussion stage, and voted on under the meta-rule threshold (67% approval + 185,000,000 CKB quorum).
The proposal’s own framing is “an upgrade to the DAO’s operational rules and supporting infrastructure.”(paragraph 4, Section 1) So it does involve rule changes within the V1.0 framework, which is why it went through the meta-rule process.
Phroi (No DM) (2026-04-01T13:13:50, Nervos Nation, edited 2026-04-01T13:56:19)
Hey @baiyu2049 and @zz_tovarishch Thank you for adding an historical framing and for the effort your team invested in addressing the problem. I acknowledge the work done; That said, I must reiterate that the following concerns from the prior discussion remain unresolved:
The V1.1 proposal was introduced without prior consultation with the Community. A little thing like creating a post on Nervos Talk would have make things much smoother: a Nervos Talk pointing out the current issue, saying that your team had started to work on a proposal to address them and potentially indicating design choices being evaluated.
The V1.1 design contains several controversial design choices that were not adequately highlighted to the Community, including the voters whitelist, the prohibition on joining a vote with a newly created account after a vote has commenced, DID failing shorter of promised total decentralization.
The M0 technical documentation was / is insufficient; this was the primary material available to the Community for evaluating the design as it progressed.
The review process was conducted by the same team that developed the project, creating a conflict of interest; this is evident in the M0-M1 review.
There were miscommunications from the team representative indicating that the whitelist would be removed.
Of course, this was just my initial wish. However, during community discussions, we realized community thought that our proposal involved changes to meta-rules, so I decided to vote on it by metarule. Since it involve…
PS: thank you for clarifying this detail, still the issue is that an actual Operator will have to run this system and this comes with issues in itself:
Who will agree to become the Operator for such a complex system?
Whoever Operator agrees, he will have arbitrary power to control who votes and who doesn’t due to whitelists inclusion into its design
Let’s assume Operator is not malicious, what happens if this infra get corrupted by a cyberattack and a malicious actor silently takes control of it?
Attack example: deny proof of inclusion in whitelist during vote, undetectable even by an hypothetical auditor tool. This can easily lead to malicious takeover of Community DAO funds.
That’s why centralized systems are so dangerous, especially when applied to voting
Hey @baiyu2049 and @zz_tovarishch Thank you for adding an historical framing and for the effort your team invested in addressing the problem. I acknowledge the work done; That said, I must reiterate that the followi…
Regarding problem 1: The proposal completed a full discussion process + multiple AMAs with the community, the proposal team also voluntarily extended a month so the community have time to discuss in more details, the feedback from the community has also been included. Actually, Phroi had contributed a lot to the feedback to the v1.1 proposal during that time.
PS: thank you for clarifying this detail, still the issue is that an actual Operator will have to run this system and this comes with issues in itself:
Who will agree to become the Operator for such a complex s…
Regarding problem 2: The problem with the so-called “whitelist” has been discussed extensively on Talk, the team has also prepared a detailed documentation of the voting system design, we’ll not reiterate everything here, we welcome the community to examine the trade-offs and participate in public discussions on Nervos Talk. The first explanation happened at Jan.29.
In fact, if we look at the existing platform’s technical solutions, that’s true decentralization, and it’s largely unverifiable. For example, the last proposal vote had problems; the voting platform couldn’t provide verifiable voting data, and ultimately, data exported from server logs was used as evidence. However, the credibility of the server data relied on the endorsement of a three-person committee. If the person who cheated hadn’t admitted it, the matter would have been difficult to resolve. As I’ve said before, the new system won’t achieve fully decentralized voting on the blockchain right away. Our design principle prioritizes ensuring data availability on the blockchain and independent verification by the community. In my view, this trade-off is necessary for gradual iteration。This version isn’t the most ideal, but it’s at least much better than the old system and is readily available for us.
Hey @baiyu2049 and @zz_tovarishch Thank you for adding an historical framing and for the effort your team invested in addressing the problem. I acknowledge the work done; That said, I must reiterate that the followi…
Regarding problem 3: The payout condition for M0 of this project is “Milestone 0 (Project Kick-off) (10% of total budget) Payment Trigger: Upon the approval of this proposal by the community.” It follows the rules of DAO1.0.
Hey @baiyu2049 and @zz_tovarishch Thank you for adding an historical framing and for the effort your team invested in addressing the problem. I acknowledge the work done; That said, I must reiterate that the followi…
Regarding problem 4: The report of M1 was published on Talk to gather community feedback, after there are no objections the Committee executed the payout, this IS the process of DAO v1.0, there are no such thing as “the same team evaluated the results themselves”. Our proposal is currently proceeding according to the existing rules. The steward team established by our proposal team is only a pre-planned entity and currently has no authority. Their current task is to communicate the content of this proposal with the community. In the future, each of them will receive a monthly subsidy of $500 USD for one year; this was done through open recruitment.
Hey @baiyu2049 and @zz_tovarishch Thank you for adding an historical framing and for the effort your team invested in addressing the problem. I acknowledge the work done; That said, I must reiterate that the followi…
Regarding problem 5: We acknowledge the fact that we had some miscommunications at the beginning of this situation, but we also want to point out that after that, all of the core team have been trying to reply to each and every message scattered around social channels and Nervos Talk. Again, the whitelist discussion has already happened on Nervos Talk, we’d like every community member to present their concerns and suggestions there to minimize the miscommunication issue.
We will publish a detailed report this week related to all of the arguments we have seen on Talk and other channels, so every community member has a complete view of what have been discussed and what are left to decide.
PS: thank you for clarifying this detail, still the issue is that an actual Operator will have to run this system and this comes with issues in itself:
Who will agree to become the Operator for such a complex s…
I think these three questions are basically repetitions of the questions above and previous concerns, and my two previous answers have already been very clear. I want to reiterate my considerations as the project leader. First, this platform prioritizes independent verification by the community, as there is indeed a possibility of cheating by the server operators. Second, my initial plan was for the server to be maintained by a three-person committee or a trusted party in the community, with our team simply delivering the code. Third, even if the voting is manipulated, aside from being independently verifiable afterward, the funding process is currently manual, requiring the property management team to notify the three-person committee to make the payment. This system is only an iterative version, not a one-step solution system from the start.
Phroi (No DM) (2026-04-02T07:14:10, Nervos Nation, edited 2026-04-02T07:45:29)
Regarding problem 5: We acknowledge the fact that we had some miscommunications at the beginning of this situation, but we also want to point out that after that, all of the core team have been trying to reply to each…
For example, how about my review confirming about the removal status of Whitelist on Nervos Talk on 7 March?
Before 7 March, the last word I got from your representative was that whitelists would be removed.
Not only this 7 March review went unanswered, the team also rushed an announcement on Nervos Talk for a launch on March 16 without first replying to my Nervos Talk review.
The situation only changed after I published a full Code Review fully analyzing codebase and documenting its issues.
For example, how about my review confirming about the removal status of Whitelist on Nervos Talk on 7 March?
Before 7 March, the last word I got from your representative was that whitelists would be removed.
…
Yeah, this is indeed a communication failure on our part. Haoyang and David both responded to you on the forum, explaining the situation and apologizing. I want to clarify that the main reason we didn’t respond to your suggestion was due to internal team reasons such as the Chinese New Year holiday; it wasn’t because we didn’t want to communicate with the community, nor was it to hastily announce the launch. We also announced a one-month extension of the public testing period starting from the 16th.Thank you again for the audit on the 16th, which made our proposal team’s work even more complete. Love and Peace
Pretty good assessment of the state of affairs. I agree with Terry here. The improvements are a step in the right direction but you do want these early steps to be taken together. Difference of opinion and conflicting ideas are a good thing and should lead to a more complete system long term.
wow… This is a stress test for the translation plugin.
This exposed a major problem: when an article is too long, the output may exceed the model’s output limit (we’re using gpt-4.1-mini, which already has 32K output tokens)…
My current thinking is that the solution is either to limit post length, or to split long articles into segments and send them to the LLM for translation at backend.
I’m leaning toward the latter. Give me some time to look into it.