Telos Works 3.0 Proposal — EOS DETROIT

7 min readJan 15, 2022

A Telos Works proposal to create an RFP based alternative for the Telos Foundation.

The Problem

The current version of Telos Works is ineffective at producing outcomes beneficial to the Telos community and token holders at large. A small number of token holders can determine which projects are funded and have the ability to kill projects mid-flight if they list multiple deliverables. Many of the projects that have been funded in the past have been for-profit or private enterprise and have not delivered substantial value and/or utility back to the Telos community.

The concept for Telos Works 3.0 was originally designed by Richard Downing, who has agreed to occupy a leadership role in the building of this Telos Works 3.0 system and defining of the Build Director role through the launch of the new system. Richard, through the Telos Foundation, recently put out a call to action for qualified teams to develop mockups for the new RFP-based Telos Works web application. The EOS DETROIT team developed mockups incorporating elements outlined in the Telos Foundation’s original blog post and made additional modifications to optimize the user experience and reduce complexity.

Proposal

Since this is a system that involves many roles and conditions, the solution should hide all complexity and empower the community to focus on what will bring real value to the chain. The goal is to build a platform that ensures transparency and accountability for projects that will enrich the Telos ecosystem.

The team identified the need of an Administrator role to manage Build Directors in the system. Not only that, but the Administrator will be also responsible for setting the rewards percentage. This role can be transferred to another account.

Administrator manages Build Directors

The Build Directors are the key actors in this system. They are responsible for creating and specifying a project and making sure the execution by the chosen team, through a lead contact called a Project Manager, is according to the standards. They also invite Project Managers to the system, which are accounts that represent entities or people that are proven to be capable of designing and developing systems for the Telos ecosystem.

Build Director creates a new project

Whenever creating a project, the Build Directors need the tools to specify the project as much as they see fit. Inputs such as name and description are included and the Build Directors may add a PDF file for further specification. The submission period for each project can be set individually. The value rewarded for the initial proposals (in this case, the $1000 liquid TLOS in USD or $2,000 USD worth of vesting TLOS) put in the proposal and the amount of proposals that will be rewarded can be defined per project as well.

Project Manager submits a proposal

Any Project Manager in the system can submit proposals to published projects. A proposal is required to have a timeline, documentation (in PDF) and a link to a kanban board where the project progress can be seen when it is being developed. Mockups can be sent as a link, so the community can visualize the prototypes whenever applicable.

The timeline is created by the Project Manager containing all the milestones that will be needed to complete the project. Each milestone will have a name, a description and a price (pegged to USD and paid in TLOS). Each milestone is broken into 2-week increments, which are displayed on the gant chart.

They will be the touchpoints for the Build Director to review the progress and the Project Manager to receive and distribute the rewards.

Build Director starts the project’s voting period

Once the receiving proposal period is over, the Build Director can start the voting period for the project. At this moment, the community will vote on the best proposals for the project for the period of time the Build Director has defined. Each account has the power of one vote for each project.

Community votes the best proposals

Once the voting period finishes, the Build Director will choose amongst the top vote receivers that will be awarded a TLOS bonus for their proposal. The number of awarded bonuses is configurable on the project level. The selected team will develop the project. Once the choice is made, the project is officially started and the countdown for each milestone starts.

Project Manager submits a biweekly report

Every two weeks the Project Managers meet with their assigned Build Director and submit their report. The report always refers to a specific milestone and they add a description and PDFs that show the progress the team has made. The Project Manager needs to report before the two weeks period ends to be eligible for the rewards.

The Build Director comes in and evaluates the report. They can either approve or reject it. If rejected, the Build Director needs to add some feedback and the Project Manager is expected to send a new report with the requested changes. If approved, the Build Director can decide if they’ll award the additional vesting TLOS bonus to the Project Manager, thus the total rewards vary in 5% to 10% of the total value requested for that milestone.

Once the Build Director has approved the report, the Project Manager can distribute the TLOS to their team. They have total responsibility on how they will distribute it, being able to keep any amount of that on their own account as well.

System flowchart and use cases

Considerations and Future Improvements

The proposed solution is an MVP with primary goals of switching the Telos Works grant funding model to an RFP based process, increasing long-term project engagement by rewarding teams with vesting Telos bonuses, improving accountability, and increasing transparency of the outcomes of the funded projects.

Governance

To help eliminate subjectivity, Telos Core Governance Documents should be updated with language to specifically define what projects qualify as having community benefit, and define the scope of what constitutes “community benefit.” For example, if a submitted project is for the benefit of a for-profit project, a substantial portion of the project must be made available open source. A working group should be created to draft governance changes.

Feature / Project Request

To save on initial development costs, the feature/project request request board functionality will be initially hosted on a 3rd-party off chain solution. This functionality should be brought on-chain leveraging the same Decide platform in a round of future improvements.

To negate the potential for power to be consolidated within the hands of the build directors, Telos Works 3.0 should be upgraded to tie the feature request and RFP voting phases together through the Decide platform. “Feature requests” that meet the preliminary threshold should automatically be converted into RFPs managed by the Build Directors (or be placed in the queue if the build directors do not have the bandwidth). This ensures that the Telos token holders at large still retain the power that was intended to be granted to the through being a Member of the network, but also providing accountability that has been desperately needed on the backend of the Telos Works funding process.

Accounts

At this point, our proposal considers that all actors in the system already have their own Telos account. To streamline new team registration, future phases of developments include the ability for project managers and team members to create Telos accounts directly from the interface. To combat this in the beginning, we can provide detailed instructions on the process of creating an account.

Dispute Resolution / Arbitration

The introduction of Build Directors who determine whether or not bi-weekly payment is dispersed or if the conditions of vesting Telos bonuses are met and should be awarded opens up the possibility of disagreements that are subject to dispute resolution. Disagreements should be resolved by a neutral third party, rather than internally by the Telos Foundation in the spirit of the Telos Core Governance Documents. It is in the community’s best interest to have a functioning arbitration portal to resolve these issues and have the network fulfill one its original feature promises.

Timeline

Creating a project — 2 weeks

Listing all projects and Accepting proposals — 2 weeks

Voting on proposals — 2 weeks

Starting a project — 2 weeks

Administrative transfer, off-chain feature request, bug fixing and improvements — 2 weeks

Total: 1 epic / 5 sprints / 10 weeks

Vote for the proposal on the Decide portal or mobile app: https://app.telos.net/trails/ballots/tlos.works.3/1642526839111

Meetup

EOS DETROIT plans to host a Telos focused meetup in its office March 30th, 2022 to showcase the new Telos Works 3.0 system. This meetup presentation will be livestreamed on youtube for the greater Telos community to view and participate.

The goal of the meetup is to raise awareness about the Telos Works RFP platform and to attract new companies and organizations to submit RFPs.

In-person Meetup RSVP: https://www.meetup.com/Detroit-Blockchainers/events/283180424

Livestream: https://www.youtube.com/watch?v=mdUl7Brerek

In the event the proposal is met with clear resistance, EOS DETROIT will change the topic of the meetup but have it remain Telos focused.

Support the Proposal & EOS DETROIT

EOS DETROIT is requesting your support to develop the Telos Works 3.0 system. The team is confident that it can deliver a quality platform to the Telos community based off of our success creating other governance applications such as the Wax Labs grant funding portal and Wax Office of Inspector General (OIG) election platforms.

Estimated cost: 450 development hours, 92,000 TLOS (~$95 / hour)