[Grant proposal] Eco Community Consensus Bot

Summary

The proposal for a grant of 529693 ECO ($10525, rate $0.01987 12 March 2023) to fund the development of Eco Community Consensus bot. The production version of the bot (referred as V1+ in the roadmap) is available to use on Eco Discord by Layer 3 and Eco team.

Project URL: Eco Discord Lazy Consensus Bot on GitHub

Mission

Layer 3 is a decentralized group of trusted members within Eco Discord, which is currently aimed to support cultural development of the Eco community. The main challenge of the Layer 3 group is finding consensus in group decision making. 59 people have a lot of different opinions, how to find agreement and distribute funds from the pool?

The mission of the Consensus bot is to facilitate the proposal and approval process for grants and changes within Layer 3. The first version of the bot operates using a “lazy consensus” mechanism, where proposals are automatically approved after a set period of time unless enough members of the community vote to cancel them. This allows for efficient decentralized decision-making, and helps to cut down on the amount of unnecessary discussions and arguing.

Goals

The main goal of the Consensus bot is to bring a simpler and more transparent decision making, which means - to maximize the creative process within Layer 3, and to minimize the organizational efforts needed to make things happen (to get approval of the community and the required funding).

The bot seeks to optimize consensus by ensuring that all decisions are consistent with the community’s values and principles, as outlined in the ECOnstitution:

  1. Evangelize: By streamlining the decision-making process within Layer 3 and making it more transparent, the Consensus Bot helps to attract new contributors to the Eco ecosystem by demonstrating the community’s commitment to efficiency and collaboration.

  2. Create: The Consensus Bot supports the creation of new projects by simplifying the approval process and freeing up time and resources for members to focus on their creative endeavors.

  3. Onboard: The Consensus Bot supports onboarding new Layer 3 members by providing a clear understanding of the proposal and approval process, making it easier for them to get started and participate in the decision making process.

  4. Govern: By facilitating the proposal and voting process for improvements, the bot plays an important role in the community governance, and may also expand more to the protocol governance, depending on the future development of Layer 3 and the bot itself.

  5. Monetize: By simplifying the process of $ECO distribution (as a direct consequence of points distribution), the Consensus Bot helps to increase the value and monetization of $ECO, supporting the growth and stability of the Ecosystem.

With two years of existence, the Eco Community has demonstrated its ability to support various types of activities and challenges in parallel, and the Consensus Bot is designed to foster this ability, enhancing independence of the creators and ensuring adherence to the community’s values.

Solution

The Consensus Bot leverages the concept of lazy consensus to streamline decision-making in a decentralized community. The lazy consensus approach operates on the principle that it’s easier for individuals to agree by default rather than actively objecting and proposing alternative solutions.

Lazy consensus integrates do-ocracy and a consensus process. Do-ocracy is a methodology by which those who take initiative to do work in a group are empowered to make decisions about what they do. It tends to appear most often in informal organizations characterized by high levels of mutual trust and a dependence on contributions by highly motivated volunteers, which is basically how Eco Community always used to operate.

Advantages of this approach include:

  1. Faster Decision Making: With the default set to agreement, decisions can be made more swiftly, eliminating the need for extensive discussions.

  2. Minimized Conflict: By reducing the possibility of objections and arguments, lazy consensus fosters a more collaborative and productive environment for community members.

  3. Improved Efficiency: Streamlining the decision-making process through lazy consensus increases overall efficiency and reduces the time and energy spent on disagreements.

However, it’s essential to note that lazy consensus may not always be the best fit in every situation, particularly in cases of:

  1. Complex Decisions: For decisions with significant impact, a more in-depth examination of all options may be necessary, and lazy consensus may not provide adequate information or clarity.

  2. Diverse Opinions: In scenarios with a wide range of opinions and perspectives, lazy consensus may not fully consider all views and may not result in an inclusive solution for all members.

To address these limitations, additional features can be added in the future (as outlined in the “Further Development” section).

Roadmap

Below is the roadmap with the delivery timelines (subject to change based on the feature development of Layer 3):

Package Stage Timeline
MVP Beta 30 Jan
V1 Release 20 Feb
V1+ Release (current stage) Feb-March
V2 Beta Approx. March/April
V2 Release Approx. April

MVP features:

  • Lazy consensus with voting.
  • Automatic grants and basic validation.
  • Zero-downtime runtime restarts.

V1 features included MVP plus:

  • Lazy consensus with grantless proposals (to approve specific actions that don’t require a grant).
  • Advanced validation (wider coverage of cases, NLP, bug fixes).
  • Analytics (new “!export” command).
  • Multiple tech improvements (e.g. automated DB backups, recovery and versioning).

V1+ features: hot fixes and improvements based on the feedback received in production. The improvements are being added continuously so there’s no fixed date on the timeline.

  • !tips - automated accounting of “personal” points.
  • Various usability and tech improvements.

V2 features: a version to be used in season 2, new mechanisms and/or improvements based on the ongoing Layer 3 development and the backlog.

Stages:

  • Beta: available in Eco Community Tools Beta Test Server (ask for invite).
  • Release: available in Eco Community Discord.

The roadmap will continue based on the development of Layer 3 (see “Further Development”). The project is open source under the MIT license.

Team & Contributors

Team

Name Discord Role
Arseniy Nisnevich yulston#0081 Developer, PM

Individual contributors

Name Discord Contribution
Valeriy Shevchuk facts parade#4191 User Guide and User Flow Descriptions (Figma)
Francis James Tolentino - Pull request

A round of applause is in order for everyone who took part in the beta testing on the Eco Community Tools Beta Test Server. As part of the “Funds Usage” section, a proposal is being made to offer a reward to all beta testers who have made significant contributions and had a positive impact on the project.

Seeking additional team members! If you possess expertise in Python and are passionate about the project, feel free to reach out. A huge plus would be:

  • Skills in DevOps and/or QA automation (automated pipelines with integration tests are needed).

  • Adaptability and autonomy; the capacity to make decisions that effectively reconcile the needs of the users with the objectives of the project.

  • Active engagement in the Eco Community governance.

If you have skills or knowledge that can contribute to the project but are not related to development, don’t hesitate to reach out and let’s discuss how you can be involved.

Funds Usage

Detailed breakdown of the project development up to the current stage of the project (V1+): Consensus Bot: Funds Usage Breakdown - Google Sheets

Development funding summary:

Name Worked days Active hours Hours rate, $ Total, $
Arseniy 44 195.5 50 9775

A reward of 100$ is requested for open-source contributor Francis James Tolentino who has made a pull request. I contacted Francis and he agreed to receive a token of appreciation.

Additionally, a reward of 250$ to Valeriy (@facts parade#4191) is requested for building a User Guide and User Flow Description on Figma (see “Features Overview”).

Furthermore, an award is requested for 8 beta testers who provided valuable input during the beta testing phase, resulting in new features or bug fixes, with a grant of $50 each, totaling $400:

Docdim#1444
olgatelb#9342
ihar#7824
MikeWeb#6752
Irina2610#2451
Saulo#9999
Valirini#1374
Ranil#4566

The combined allocation amount is $10525:

Contributor(s) Amount, $
Development (Arseniy) 9775
Open-source contributors (Francis) 100
Documentation (Valeriy) 250
Beta test contributors (8 members) 400
Total 10525

Features Overview

To quickly learn about the bot, look through the User Guide by @facts parade#4191: User Guide on Figma

Additionally, a description of a User Flow in each usage scenario is available: User Flow Descriptions on Figma

The bot currently has four implemented commands, which are:

  1. !propose - the main command that can be used in two ways: with a grant, which will apply the grant automatically after two days if it wasn’t cancelled, or grantless, which only approves certain actions without applying a grant.
  2. !tips - automated accounting of “tips” (or “personal” points), limited by 3000 per season according to the latest Layer 3 agreement.
  3. !help-lazy - this command sends detailed usage instructions to the user via direct message.
  4. !export - this command returns a spreadsheet containing all accepted proposals, tips balances and the history of tips transactions. Additional analytical commands can be added upon request.

The bot is designed to streamline the onboarding process and offers clear and concise guidance for any user commands. It also includes automated responses to address potential user errors, such as voting on the wrong message, using incorrect command syntax, submitting proposals with non-english text etc.

The bot is designed as a critical infrastructure component, ensuring reliability through several measures, including:

  • Utilizing two databases that are separated based on their usage, with one for active proposals and the other for the history of proposals used for analytics. This enables better optimization and user responsiveness, with ORM used to simplify development.
  • Conducting automated DB backups to Google Cloud, with the active proposals DB backed up every hour and the history DB backed up every 12 hours. Backups are securely stored for 10 days.
  • Providing automated recovery in case of a downtime, which synchronizes the DB with the current state of all active proposals in Discord, including adding and removing voters and applying decisions for which the timer has exceeded during downtime. Further information on recovery can be found in this comment.
  • Ensuring runtime sustainability through proper error handling and the use of PM2, a zero-downtime process manager that automatically restarts the application if it crashes. The bot is always run as a PM2 daemon and will never go down as long as the server machine is up and running. Updates to the bot can be easily delivered, taking only a few seconds to apply any changes in code without downtime.
  • Utilizing advanced concurrent logic to handle voting and recovery, which underwent proper testing and was proven to be reliable. Adding new proposals can be paused at any moment without shutting down the bot.
  • Controlling the entire setup with a startup script, which installs all dependencies, enables backups, sets up the firewall, runs tests, and starts the bot. This allows for simple migrations to other host machines if it will be needed.
  • Monitoring the runtime with Netdata and PM2. Additionally, the bot has a robust logging in place, which allows to troubleshoot any issues quickly.
  • Ensuring data accuracy and security, the bot validates all user data input through a comprehensive 3-step checking process.
  • Accessing the server with SSH using a 2048-bit RSA key owned only by @yulston. The server is secured with a firewall enabled in the startup script. Each stage (beta and prod) is run under a separate user with restricted read/write permissions only to the files under their home directory. The OS used is Ubuntu 20.04 LTS, with all stable security patches automatically installed by the “unattended-upgrades” tool.
  • Hosting on AWS to ensure stability.

Availability

The Consensus bot is accessible for use by Layer 3 members and the Eco team on the primary Eco Discord server. Additionally, it is available for testing to everyone on the Eco Community Tools Beta Test Server. To request an invite, you can reach out to me or any other member. All the latest updates and features will be tested there before being introduced to the main production server.

Further Development

The direction of the bot’s future development will be shaped by the input from Layer 3. Depending on whether Layer 3 decides to replace the current system with the bot, integrate them, or request new features, the roadmap will be determined. Below are some of the ideas that are being considered, but none of them have been put on the roadmap yet.

A solution to the Warlock Dilemma (when it’s unclear why a post didn’t receive any reactions, whether it’s due to its quality or lack thereof) could be to include a few required “accepted” reactions (2-4) for a proposal to be considered successful. It was suggested by multiple people in Discord. This approach is exactly what is done in the Fedora Project (see “References” section below for more information).

One issue yet to be resolved in Layer 3 is the accounting of points that remain on the balance after they are distributed. The Consensus bot can implement a feature that addresses this problem, described here.

Another idea, integrating the bot with “Table B” into a single automated workflow could combine their strengths and reduce the potential for human error. More details can be found in the Discord discussion.

A survey can be conducted to gain insight into how justice is perceived in Layer 3. The survey would involve members voting on hypothetical grant request scenarios to determine the most appropriate voting methods. Additionally, the survey would collect data on how various factors, such as community experience, influence voting decisions. The results of this survey would help us better understand the Layer 3 community’s view of justice and aid in the selection of appropriate voting methods and parameters. For example, the threshold to cancel a proposal could be determined based on the requested point amount, or the proposal duration could be based on the number of disagreeing votes or previous proposer history.

Some more of the possible features that can be added:

  • A mechanism for distributing and tracking “personal” points in L3 (1000/month or other limit). Details can be found here.
  • Integration of “Table B” functionality into the bot, allowing for delegation of points directly within Discord and analytics requested by a command. More information on GitHub.

For situations that require a majority vote, some more mechanisms can be added (again, these are just ideas not included in the plan):

  • Bucklin Method: A way to compare each option with every other option to find the preferred choice. If no option gets over 50% of the votes, the option with the least votes is eliminated and voting starts again. This can be used for complex decisions where there are multiple options and different levels of support for each.
  • Approval Voting: A method where each person votes for as many options as they want and the option with the most votes wins. This can be used for situations with a large number of options or when a person supports multiple options.
  • Range Voting: A method where each person assigns a score to each option and the option with the highest average score wins. This can be used for activities or challenges where participants need to rank their preferences.

Other directions may include:

  • Adoption of the bot to make protocol-related changes.
  • Adoption of the bot for other communities and platforms.

The development of the bot has many possibilities. The funding request in this proposal covers the V1+ version that is currently available in production. The bots development will continue. There are no plans yet for additional funding requests until a clearer understanding of the desired features and development plan is established.

References

Read more about lazy consensus and how successful companies, communities and technologies operate using it. In many of them you can find lazy consensus as a default mechanism for decision making, while a majority vote is used for critical decisions.

Usage in Web3

In short, contrary to the popular narrative about the importance of voting, Colony encourages DAO builders to avoid voting wherever possible.

Sometimes called ‘lazy’ consensus, Optimistic Governance assumes that all actions are legitimate unless proven otherwise.

Usage in various IT projects

Lazy consensus lets us avoid having to wait for a community-based decision before proceeding. However, it does require everyone who cares about the health of the project to watch what is happening, as it is happening. Objecting too far down the road will cause upset, while objecting (or asking for clarification of intent) early is likely to be greeted with relief that someone is watching and cares.

More significant decisions are made through a process of full consensus. In order to pass, these decisions need three positive votes (+3) and no negative votes (-1) within a specific period of time i.e. 14 days.
For example, proposing new event guidelines for events, changing the decision-making process, and voting on Outreachy budget allocation requires full consensus.

The default decision making mechanism for the Prometheus project is lazy consensus. This means that any decision on technical issues is considered supported by the team as long as nobody objects.

  • Sanic (287 GitHub contributors)

In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote. For any major decision (as defined below), there is a separate Request for Comment (RFC) process.

Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.

For efficient agreement two factors are important:

  • do it asynchronously.
  • be lazy.

Most decisions start by seeking Lazy Consensus. If an objection is raised through the Lazy Consensus process, Deciders work together to seek an agreeable solution.

Individuals sharings

Bethany Nowviskie (Chief Academic Technology Officer at James Madison University, US)

You can no more effectively deny the power of lazy consensus than you can deny gravity or thermodynamics. It will act on you whether you acknowledge it or not.

Daniela Mayrshofer (CEO at consulting agency "Consensa Projektberatung GmbH & Co. KG)

To work in the mode of lazy consensus, it`s mandatory to create a culture of trust, appreciation, mindfulness, listening to each other and openness.
The advantage of the concept of lazy consensus is that a group is always able to move forward: very quick, when there are no objections - and a little slower with a learning curve when there is a valid concern to be discussed. That usually saves a lot of time und prevents endless discussions - even if not everybody is able to express her specific opinion.

Isabel Drost-Fromm (Apache Foundation)

With that lazy consensus model it is possible to unblock situations where pull requests are fairly uncontroversial. It gives people a chance to read them and move on if there’s no significant objection. It also helps putting a deadline on issues to make transparent if they are time sensitive or not.

More about various methods of self-governance (not limited by lazy consensus): Democratic Mediums

5 Likes

I fully support this proposal. I note that we can constantly improve and adjust it to suit ourselves, this is a huge plus for us, thanks to the developer. There is still a lot of work to be done during the next seasons.

1 Like

I am a huge fan of the concept of lazy consensus and fully endorse the proposal to fund a lazy consensus bot. The bot is already being used by members of Layer3 and is set to become one of the most crucial tools for consensus building. Yulston has provided an excellent explanation of his proposal, along with a compelling rationale and a comprehensive roadmap. I sincerely hope that the community will also support this proposal.

1 Like

I fully support this proposal. I imagine the bot will help L3 who managing season activity and make work more efficient. Lets go !

1 Like

Full support, this bot is something that is already working and bringing value to L3 and the Eco Discord. Unlike some other proposals that only suggest the idea.

1 Like

I support this proposal. The bot will make the work of Layer 3 participants much easier and speed up the decision-making process.

I think my words of affirmation will be superfluous here. I am ready to sing odes to the bot and Arseniy’s diligence. The bot requires constant training, it will periodically require new changes in the process, sometimes it is possible to change the functionality, so full support. I would add another award for Arseniy for periodic maintenance of the bot, which is very sensitive.

I would also introduce an additional fixed percentage of remuneration for builders for servicing all ecosystem technological developments. The work of developers requires great perseverance, attentiveness, without them there would be no progress in the technical part. They are constantly in the working movement, they need to quickly prevent all errors, this is painstaking work.

@Dave_Eco What would it take to get this proposal, which many people voted for, passed unquestioningly on the governance vote…or this EGP#009 Builders Ecollective Second Round of Funding @Saulo sentence includes funding the development of the consensus bot and its maintenance.

@olgatelb Hello! This proposal was already rewarded by the Builders Ecollective, you can see the details on our Snapshot and Safe. Let me know if this answers your questions.

1 Like

Thanks for the answer. I will not go into your budget. The main thing is that everything worked out)

It “worked out” because of my own willingness to complete the project, the budget has nothing to do with the bot featured up and bringing value to you. There’s a problem that such work normally deserves appropriate compensation, but expecting a fair payout from Eco is like waiting for a cat to bark.

Saulo’s hypocrisy goes beyond boundaries. As someone who initially supported tracking work hours, and suggested to split the funding request before and after the project has been finished and gets actively used, when it all comes to actions he’s doing the entire opposite. Such a shame.

Others expecting me to maintain the project is frustrating. As the saying goes, “At the end we will not remember the words of our enemies, but rather the silence of our friends”.

Hi Yulston.
Have you addressed this question to Dave?
Perhaps he can help resolve this issue.

This issue should be addressed publicly

3 Likes

Hey all!

I’ve been monitoring this discussion for a while and purposely held off on responding to give the community time to weigh in and for Yulston to express himself. Some of you won’t like this response, but you can get an “ugly truth” from me or a “beautiful lie” somewhere else. While I considered several different ways to express it, I ultimately chose transparency because I’m guilt-free, clean, and proud of everything I’ve done and continue to do for the network.

This will be a lengthy response, it could be even longer. I’m also available for a lengthy community call with everyone to go over everything that happened or try to solve this situation in the best way possible. Take your time to examine what I have to say, and as you read it, keep these two things in mind:

  1. Yulston began building the bot before the builders even existed.
  2. What would deceiving him gain me, or any of us?

Please understand that I made Yulston absolutely no promises. Since I’m not in control, I was unable to make him any promises. I’m only one of the signers; I have the right to my own, fallible opinions, just like everyone else. Since they lack context and may be misinterpreted, I usually avoid publishing these kinds of things, but when Yulston contacted me to request funding, this is what I replied to him:


Over the next few days, we interacted about the best way for him to make a proposal, that is part of my responsibility as a community member and I would do it for any of you, there was various possibilities but I’ll say it again: I made ZERO promises! I’ve never done this, but I hereby offer myself up for the release of all of my direct messages with and only with direct Yulston’s consent.

I would prefer not to but if the community feels it is necessary I have nothing to conceal, none of my reputation or trust is even at risk here. Any of you can ping me at any moment, and I will respond and try to explain everything as best I can. I’m also glad to discuss this with any of you in DMs, or in an L3 call if required, just let me know.

As of right now, I consider the situation to be closed, and I won’t speak out about it again until Yulston decides to return and collaborate with the community. I’m not mad at him and I don’t want to hurt anyone since I understand that we’re all human and will make mistakes. I’ll give him another chance, but he must genuinely want it. I had hoped it wouldn’t come to this, but it appears I have no choice but to deal with this drama in this way.

The bot was initially created by Yulston as an L3 for the L3, as builders weren’t even thing yet. He most likely anticipated receiving payment from L3, but he did not create the consensus bot with the sole intention of submitting an application for a grant on the Builders. After he began working on the bot, I invited the user to join the Builders group. This was a mistake, I thought he was interested in being a builder. I’m sorry! The correct method would be to ask the opinions of other Builders and undertake personality-based assessments to determine whether his person fits a working group. Because I respect Yulston’s standing in the community and because I was in charge of seeding the Builders, I made the call. It wasn’t because I didn’t care; rather, in certain cases, the process of finding people to seed a group requires beginning to communicate privately until those people show signs of wanting to be a part of something, so I handled it and did it for all the Builders.

What I infer from this situation most strongly is that Yulston misinterpreted Builders from the moment it was founded, and that from the moment he joined Builders, he changed his expectations and future intentions related to his intentions and responsibilities in the community. Builders are not employed and do not receive a “salary”; rather, our goal is to promote growth and build on the network. The Builders Ecollective is a working group whose sole goal is to help the community by providing and supporting infrastructure.

Personally, I find what Yulston is doing to the Builders group and the rest of the community to be heartbreaking. I can only see this whole situation as a misunderstanding by greediness and blindness, mixed with misaligned and emotional damage. I never support “hourly rates” or “tracking hours”. Everyone that knows me, knows I have spent hours discussing with them not using hourly rates. And I often use this video as a way to better explain why:

Yulston had been trying to call me for about three weeks, but I was extremely busy and was unable to. He wanted to talk to me about the funding of the consensus bot. I informed him that if he wanted my vote, he should establish a lesser goal of around $5k as it was ALL that we had in our Safe and I felt that $10k was too high for a number of reasons I can detail with you later. A retroactive award could be considered by everyone if the bot was used and proved to be valuable over the course of the following 6 months.

During our two-hour call, he lost control, insulted the other builders, denigrated other network tools, and bullied me to a considerable amount by yelling, shouting, and using foul language. It was one of the oddest online calls I’ve ever had online and for a series of days it was very hard for me to understand it. He also said that he didn’t understand why I wasn’t supporting his bot because it was not funded by my money and we could all benefit from it. If he get my vote he would win, I would win, and the community would win—I do know what you tried Yulston. Let this be clear to ALL of you, under no circumstances, no matter how much how I like you or who you are, no one will run me down and compromise my ideals. No one!

While trying to defend his case he also made false statements, such as The Eco Accountant is a bot constructed of garbage templates that doesn’t even require a database, which is absurd. I do have some knowledge of programming. I did offer to deploy and submit an EGP for him so he could ask for the $10k directly to the Community Treasury, even though I wouldn’t give him a vote on the Builders Ecollective snapshot because it’s my duty to defend this community and its value. I was interested in being impartial and supporting him, in the middle of that topic I went even further and asked what he would do if the proposal didn’t pass, and to my utter shock, his response was, quoting, “I leave the community.”

I only stayed on our call for that long being bullied and shamefully abused because I was truly concerned with his emotional state. In fact, I begged him to behave himself as he was terrorizing all his image before me and it wasn’t helping anyone. I was nothing but welcoming, friendly, and super understanding towards Yulston despite all the crazy behavior and nonsense. At the end of the conversation, as soon as I suggested using retroactive rewards once the bot had demonstrated its worth, he started calling me a genius and declaring that he completely agreed with me. His personality changed from 8 to 80, but I do believe he misread what I had said. I didn’t ask him to ignore Layer 3, the Eco team, the builders, or me until he had additional financing.

I find it heartbroken what Yulston did and is doing to this community. He did ghost us all who were trying to work with him to solve the situation, ignore my DMs, ignore other people’s DMs, ignored L3 pings, missed every single responsibility as part of Builders, and don’t sync with most of the things. After two months away he appeared out of nowhere and not even a hello or a justification for missing all his responsibilities, all he asked was if there was any chance of getting more funding for it after ghosting everyone for more than 2 months without working actively on it or supporting the community.

Is this the kind of behavior we should encourage in our community? I only see love coming from all of you in his direction and he has been ghosting you all for two months in addition to acting irresponsibly toward the eco-system. Additionally, updating two integers on lines 67 and 147 of this file resolves both of the issues that the community is yelling about in a matter of seconds: eco-discord-consensus-bot/const.py at prod · nisnevich/eco-discord-consensus-bot · GitHub


Regardless of how the Builders grant application has gone, I do think holding the bot hostage, refusing to answer to Layer 3, and helping you all is irresponsible and Yulston has proven to not be the right person to be in charge of such a critical piece of infrastructure for our community. In order to have a responsible Eco engineer or another responsible person in charge of hosting the bot for you, I will make a motion to remove his bot from the community. Naturally, he is still encouraged to work on it and maintain it by pushing to GitHub, it’s an amazing piece of infrastructure that I truly believe should be worked upon over time. However, it’s important to make a distinction between hosting the bot and coding the project, he coded the project and no one will ever take that from him, we’re and will always be grateful for his contribution and I hope it makes great use to the community.

A governance proposal to remove Yulston from the Builders will also be made by me. This is unrelated to the grant of the consensus bot and is being made due to Yulston’s near-constant failure to carry out his duties as a member of the group, including but not limited to, participating in discussions, weekly calls, helping community members, signing on Safe, and voting on Snapshot. This proposal will reduce our Quorum from 5/5 to 4/4 and hopefully new Builders and people interested in the well-being of the community will join to work in a mature and responsible way.

Thanks for your understanding and I hope this long reply makes things clear. If any of you want to discuss any of these comments you can send me a DM.

PS - Although I won’t vote for the consensus bot to get more funds from the Builders as per our guidelines and responsibilities, I’d be willing to help if Yulston wishes to submit an EGP to get access to the Community Treasury and get extra funding directly with a community vote. As I’ve already shown, both platforms are distinct, represent, and are governed by different entities. I will assist with the smart contract’s on-chain submission and deployment as per my community’s obligation so that you can all vote in a decentralized way to provide the consensus bot extra funding. Also, Layer 3 is the community’s governance body and since it is not necessary to obtain permission to allocate points, assuming Layer 3 has the knowledge and understanding of how to evaluate grants to make people responsible for their actions and roadmap, another option is for Layer 3 to fund the consensus bot directly with points, which will enable him to make an ECO claim at the conclusion of the season.

3 Likes

The Community Treasury how much is left?