This document describes a revised approach to tracking blockchain systems through different stages of their life cycle, applied by cyber·Fund Radar. More specifically, it describes a reviewed procedure of listing new systems on Radar and following up their further development there. The document contains a methodology note and a step-by-step guide to be used by cyber·Fund in their work. The final purpose of the document is to optimize the way cyber·Fund processes the incoming flow of new blockchain systems.
In order to be listed on Radar, each new blockchain system will first be located in one of the two following groups.
Description. Systems that initially demonstrate a clear or at least some potential to deliver an interesting and valuable product worth investing into.
Selection criteria. The indicator used to define the system’s initial potential will be the quality of a whitepaper or of a Proof of Concept code. A system should also comply with the following minimal requirements: a published whitepaper or a Proof of Concept code, open source code policy, autonomous decentralized system on blockchain with economic incentives introduced via a token.
Work approach. By the end of the Radar tracking cycle, a system should be very well verified. As to systems that raise some concerns initially, cyber·Fund will follow up their development and can re-evaluate their potential later. As part of the verification process, an ICO report will be prepared on each system planning to raise funds via ICO. The report will be published on cyber·Blog. Depending on the incoming flow of projects, either a project-sepcific ICO report will be prepared or a project will be invluded into an overview of multiple upcoming ICOs. The projects from this Group should be handled on a first priority basis.
Description. All other projects that do not comply with the Group 1 selection criteria belong her. Those are systems that raise significant concerns, or their potential is not clear.
Selection criteria. A system should meet the formal selection criteria only: it should have a project name, headline, logo, website, whitepaper/ Proof of Concept code, and plan to issue a token.
Work approach. Group 2 systems will be listed in a separate section on Radar and will be open to a verification by the community by voting them up or down. Group 2 systems will be processed by cyber·Fund on a second priority basis.
A Radar tracking cycle consists of five stages divided by a type of a triggering event:
- PoC code or WP is released
- ICO date is announced
- ICO starts
- ICO ends
- Token is listed on exchanges
The stages can easily be renamed later keeping the underlying logic intact.
The work flow per each stage is laid out below. For each stage a source of updates (how do we know that a triggering event happened) and required actions (what should cyber·Fund undertake given a triggering event happened) are described.
- Project’s request on cyber•Fund or cybernator
- Ad hoc updates from web (blogs, Twitter, online news media, other ICO tracking resources, etc.)
- Ad hoc external input, e.g. from Satoshi•Fund team
Group 1
- Subscribe to the project’s RSS to track ICO related announcements; if not available - alert the team and subscribe to e-mail announcements
- Add to chaingear which automatically places a system under “Anticipated” ICOs
Group 2
- Subscribe to the project’s RSS to track ICO related announcements; if not available - alert the team and subscribe to Twitter and e-mail announcements
- Add to chaingear under the section “Purgatory” (not yet available)
- Project’s updates via RSS/e-mail/Twitter
Group 1
- Tweet about the ICO announcement
- Update chaingear with new data (a system is then removed to “Upcoming” ICOs)
- Prepare a report for cyber•Blog
- Distribute the report ASAP via all communication channels
- Follow-up comments to the publication on cyber•Blog
Group 2
Re-evaluate a system and choose one of the three options:
- Remove to Group 1 and follow the actions for Group 1 systems described above
- Leave in Group 2 (Purgatory) and update chaingear with new data
- If a scam - Leave in Group 2 (Purgatory), update chaingear with new data, add a scam alert to chaingear (not yet available), and tweet a scam alert
- Project’s updates via RSS/e-mail/Twitter
Group 1
- Tweet ASAP about the start of ICO
- Update chaingear (a system is then removed to "Ongoing" ICOs)
Group 2
- Update chaingear with new data (automatically removes the system to "Ongoing" ICOs)
- Project’s updates via RSS/e-mail/Twitter
Group 1
- Tweet ASAP about the end of ICO
- Update ASAP the ICO end date on chaingear (a system is then removed to "Successful" ICOs)
- Update other post-ICO data on chaingear
Group 2
- Update the ICO end date on chaingear (automatically removes the system to "Successful" ICOs)
- Update other post-ICO data on chaingear
- Project’s updates via RSS/e-mail/Twitter
Group 1
- Tweet about the start of listing
- Follow-up in weekly overview on cyber•Blog
Group 2
- R.I.P. unless at some point the community upvotes a system which will replace it post factum from "Purgatory" to "Successful" ICOs (the exact migration criteria and mechanism need to be defined yet)