Syncroblock LLC

David Chapman

Factomize
Thank you for your application. To start:

A. I was a little unclear. Can you elaborate on what, if anything, you plan to do to, "Further the Protocol" besides run the Authority Nodes?
 
Sure, I'm happy to elaborate.

We believe that the key to making Factom emerge as a de-facto protocol is increasing awareness and education amongst blockchain developers (or potential developers). For example, Ethereum has done an outstanding job with awareness, education, and making it very easy for developers to get started implementing their protocol into applications.

Our team's primary expertise is in creating compelling websites, and driving traffic to those sites with smart marketing strategies. We have a two stage plan for increasing awareness and eduction for developers:

1) [Eduction] Develop a Global Factom Developer Information Portal (localized in major languages)

The Portal will be an (unofficial) information portal with news, educational modules, samples / code downloads, an app / project directory (similar to State of ÐApps), and a troubleshooting forum (a Factom-focused Stack Overflow), all intended to help create and cultivate a community around the Factom protocol for developers. We have extensive experience creating localized websites of scale, and creating a Portal on this level would not be much different from our previous experience.

2) [Awareness] Promote the Information Portal around the Web

Although it's relatively easy to build a web property, the real engine of a website lies in the marketing strategy. This marketing strategy would consist of a four prong approach (in order of priority and importance):
  • SEO Program
    • Drive traffic to the site by ranking for terms that relevant to blockchain development (directly and indirectly). Because the branded term "Factom" doesn't have a lot of awareness, it's key to rank for phrases that are more generic in nature.
    • Create compelling guest posts for relevant blogs and industry information sites that link back to our Portal.
    • Contact the relevant parties at major universities, developer education programs, and other related avenues to link to our education resources. Blockchain is a hot topic right now, so educators will be eager to plug into resources to help their students learn the technologies of the next decade (and beyond).
    • Implement other relevant (proprietary) strategies to help rank the website.
  • Social Media
    • Create Portal-branded pages on all of the major social media portals, and post relevant information articles and case studies on how the Factom protocol is solving business identity problems with blockchain.
    • Post community-engaging content around issues concerning the blockchain, and other interesting topics that create buzz and engagement.
    • Showcase developer interviews that show how they are implementing the Factom protocol into their applications, and the benefit of the Factom protocol over other solutions.
  • Media Contacts
    • Create a strategy for press releases around important Factom milestones, and contact relevant news outlets for promotion.
    • Reach out to industry (developer) influencers and establish a relationship with them to get Factom on the roadmap and increasing buzz around the protocol and Portal.
    • Contact existing relationships with digital media outlets (eg. CNet, Slashdot, etc.) to get articles written about Factom, or discuss paid placement opportunities.
    • Other relevant mass media / tech media outreach strategies to increase buzz and awareness around Factom.
  • Other Ancillary Strategies
    • Although social, SEO, and "organic" media contacts can drive the most results, some PPC (pay per click) and other paid traffic sources could be implemented on a limited basis, depending on the CPCs (cost per click) of the relevant terms.
    • Old school, pick-up-the-phone and call influencers, college professors, and other important contacts. We have employed this strategy very successfully in the past in other markets.
    • Create a online competition for the "best Factom-integration idea" and offer a prize / scholarship to the winning developer's idea. This would help to create organic conversation, and get young developers excited about the protocol.
The Portal would operate as a non-profit (assuming we monetize it in some way, which we have ideas around), and all proceeds above our operation costs would be donated as grant contributions.

This is just a general, strategic overview of how we would create and promote our Information Portal and further awareness of the Factom protocol. We will dive deeper into the specific tactical details of this strategy if we have the opportunity move forward, but I hope this gives you a general idea of the direction we want to go.

In summary, we strongly believe the success of the protocol hinges upon developers choosing Factom over competing solutions in the marketplace. Thus, we believe that creating awareness and education is critical to achieving the goal of making Factom the de-facto standard in blockchain development and smart contracts.
 

Tor Paulsen

The Factoid Authority
TH #1:
If you don't get selected to run authority servers in the first batch of entities; will you then still pursue furthering the protocol as well as leveraging Factom in your other startup in the logistics/transportation sector?
 

Tor Paulsen

The Factoid Authority
TH #2 you mention that "at least one member of our team will be available 24/7"... Does that include the "group of sysadmins" you say you will hire, or would that be one of you three? What would the "group of sysadmins" actually bring to the table? How does the "external server monitoring company" fit into this setup?
 

Tor Paulsen

The Factoid Authority
TH #3
What has your team done to ensure a proactive approach to managing the financial aspects of your business?
You mention that you "use a professional accounting firm to handle this aspect".

Have you hired this company already? If not; what kind of financial planning have you executed at this stage?
 
RE: TH #1

Yes, absolutely. We are committed to the Factom protocol for the long term, so if we are not selected in this round, this would be a non-issue in our actions for moving forward. In fact, we've already secured several possible domain names for our Portal, and will begin wireframing the website in the next couple of weeks.

On that topic, one thing that we would recommend is implementing some kind of oversight / accountability committee to ensure that all groups that are selected for the M3 are held accountable for making measurable progress in whatever activities they propose for furthering the protocol. It's very easy to propose grandiose and overly ambitious ideas that never materialize, so we believe this essential to holding groups accountable.

Each group should be required to create some sort structure of time-defined goals / benchmarks to be achieved. If these realistic performance benchmarks are not achieved, or there is obviously no progress being made, there should be some kinds of rules / actions around demoting them and promoting another group to the role. We believe it's only fair to every group who has the drive and initiative beyond simply operating the servers themselves.


RE: TH #2

Will follow-up with this answer later today (CST).


RE: TH #3

You mention that you "use a professional accounting firm to handle this aspect". Have you hired this company already?
As far as the cash flow / accounting aspect of a business, we plan to outsource the actual accounting around (eg. cash inflows and cash outflows using based on the accrual / GAAP accounting method). We plan on using the same accounting firm that we have used (and currently use) for other e-commerce / online ventures. This includes getting a weekly and monthly cash flow reports that show exactly where the business stands. Keeping constant tabs on the financials is essential to operating any business successfully.

If not; what kind of financial planning have you executed at this stage?
If by this question you mean ensuring that we have the adequate cash flow to operate the servers:

We have funded the company with $150,000 USD, which we foresee funding the company (assuming one or two operational nodes) for a long time, regardless of FCT pricing. We've created some simple cash flow models for revenue / expenses / taxes / grant contributions, and expect to breakeven (or operate at a slight loss), assuming a reasonable variance of current market pricing (FCT @ ~$15 to -$30). In other words, we are not planning to operate on a shoestring budget with the reliance on current market FCT price to keep the business liquid. Even if the price of FCT was priced at $0 (highly unlikely), we still have the capacity to operate the servers for a long period of time. We've run 20+ servers on AWS (for several years) for our other businesses, so we feel confident in our assumptions for bandwidth consumption, etc.

Hopefully that answers your question, and if not, please clarify further.


(Apologies for not addressing #2 at the moment - I am personally traveling over the road, but will answer when stationary. Thanks for your patience.)
 
Thank you for your patience.

RE: TH #2

you mention that "at least one member of our team will be available 24/7"... Does that include the "group of sysadmins" you say you will hire, or would that be one of you three? What would the "group of sysadmins" actually bring to the table? How does the "external server monitoring company" fit into this setup?
The structure that we have setup for this company to have three members who all bring unique, yet overlapping skillsets to the table. Jason's role is to drive the organizational / business / financial aspects of the business, Mike's role is to discover opportunities and create ideas for furthering the Factom protocol, implementing it into our personal Factom projects, and providing insight and recommendations from a senior developer's standpoint. Finally, Ali's role is to be the primary system administrator, who will oversee a small group of other directly-employed system administrators and provide strategic direction (eg. find ways to improve the structure, operability, and efficiency of the servers).

Ali will be personally available in his timezone / working hours (GMT +7), while Mike and Jason will be available during our working hours (GMT -8 and GMT -5). In full disclosure, although Jason is quite savvy with web technologies and can operate a server, he doesn't have the technical knowledge to manage a server on the level of his two other team members (and is not his key role in the organization). Mike and Ali have dealt extensively with servers of all types - IIS, Apache, Java, etc. - across multiple industries and server setups, with each having a unique set of experiences and specializations. That's by design, as having multiple team members in an organization with identical skillsets we believe is a hinderance, rather than an asset.

That being said, our intention is to have at least one systems administrator (possibly two, which we've budgeted for) to be available for 24/7/365 coverage. In other words, there will be at least one live, internally-employed system administrator watching over the servers 24/7/365. The value that they bring to the table is not only making sure the servers are functioning correctly, but also looking for opportunities for how to make the servers run more efficiently. Internal tools developed, optimizations, and any other positive insights that are gleaned from our own server set would be passed on to the community to help others groups similar problems. This "learn and share" mantra will be an overriding cultural thesis of our organization.

As far as the external monitoring organization goes, we plan to implement this as a redundancy strategy. The reality is no one, or organization, is perfect 100% of the time. An external server monitoring company provides this redundancy in the case that for whatever reason, our internal system fails, in a worst-case scenario where none of our internal team members are available to respond in a timely fashion. Thus, at any given time, there will be an additional, external staff on standby to provide lifeline support for items that can occur unexpectedly. We will implement a communication channel to coordinate and ensure there will be no more than one person touching a server.
 

David Chapman

Factomize
B. Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you also discuss additional development work which is important despite your single node Efficiency being at 50%. The Standing Parties will likely want to see what progress you're making since it was part of your campaign. My questions are:

1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.
2. What would you communicate and how often?
3. What metrics should be used to gauge your development progress and success?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
Thank you for your application

NK01)
Finally, in additional to internal personnel, we will hire an external
server monitoring company to have redundancy in responding to
alerts and downtime
Will this company administer the nodes? How will you make sure these sysadmins know what to do?
 
Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you also discuss additional development work which is important despite your single node Efficiency being at 50%. The Standing Parties will likely want to see what progress you're making since it was part of your campaign. My questions are:

1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.
We believe it's important to consider the type of content that is being conveyed. Twitter and other short-forms are great for information that is time-sensitive, short, and don't require much direct engagement, but rather cumbersome for something like discussing campaign / target / goal progress. Also, voting / popularity-based communications such as Reddit could be useful, but we think that they are more subject to manipulation in the form of malicious voting, and clique forming. In our opinion, it's highly subject to fostering more "negative" interactions through the nature of the platform (not good for this use case).

Thus, we think that when you are documenting progress of a project, more traditional, "long-form" content mediums (eg. blog, forum) makes more sense than short-form communications. Long-form mediums provide ample space to discuss the topic at hand, yet give the opportunity for engagement from the readers and Standing Parties. These forms are perfect for "question / answer" format to foster engagement, whilst providing a long enough medium for writing on the topic at hand. We also believe that long-forms make it much easier to find and filter through relevant information much easier than other media. Personally, we use Basecamp for project management initiatives, so a "hybrid" solution - a meld between social and project management - could be the ultimate solution.

(Sidebar: We believe there should be a consensus on what communication platforms make the most sense to the Parties involved, but also very importantly, information security. Because FCT is a financially-traded asset class (whether or not you agree with that assessment), forms and venues of communication should be under much more scrutiny. Extreme care must be taken to avoid exposing too much information that could be used to manipulate the underlying security. We could expand greatly upon this, but this answer is a whole different topic, in and of itself.)


2. What would you communicate and how often?
In our specific situation, first, we would share a timeline of goals. Goals would be created based on segments of the overall project, and set realistic benchmarks for meeting them. Based on those goals, we would provide bi-weekly updates on the tactical elements that we are completing to work toward each of those goals. We believe that when you are talking about a (very) long project of this nature, constant communication is not necessary. While providing updates is essential, too much communication can be distracting and a hindrance to the tasks at hand.


3. What metrics should be used to gauge your development progress and success?
We believe the answer to this question is very specific to each group's campaign, but also what stage they are at in their project. That being said, in our case, we have a two stage campaign: building the infrastructure and marketing the site.

The first stage of our campaign is quite measurable. We will set individual goals for each step of the web development process, breaking down the site into individual sections (eg. forum, news section, download portal). Within those sections, we will have tactical goals (eg. page designs, backend functionality) to meet. In the stage, it's purely a matter of "did we complete the task by the deadline we set?", and if not, what can we do to adjust internal processes and make sure we are meeting those benchmarks?

Our development efforts would be broken up into two-week sprints. We would track individual development tasks as tickets corresponding to user stories or other work items. These tickets would be associated with a the level of effort involved for each item, such as "story points," "t-shirt sizes," or a similar metric. The number of tickets completed and the sum of their effort (total story points, etc.) would be reported at the end of each sprint. Therefore, standing parties should expect results and regular communication on a bi-weekly basis. We would also provide a real-time view and "kanban" board of the active sprint to allow standing parties to track our progress on the current sprint in development.

Based on the metrics provided by each sprint, standing parties would easily be able to track our progress by measuring our velocity to see whether we are on track to meet our defined goals. We would also invite standing parties to participate in sprint feedback sessions held at the end of each sprint to ensure the quality and content of our work and is aligned with the Factom community.

The second stage, marketing of the site, is far more objectively measurable. The ultimate measurement metric of performance of a website - across all areas of our site - will be the amount of traffic that is visiting. That is easily measured with Google Analytics. On the SEO side, we can use various tools (eg. Ahrefs, Site Explorer, etc.) to measure we are ranking for certain terms in each country / language. More granular metrics will be used for certain sections such as forum posts per day / week / month, downloads from the Portal, engagement in our social media channels (eg. followers, comments), and other forms of objective, measurable metrics. Tracking brand mentions for our Portal across the web would be another way to keep a tab on our brand awareness and progress.

Quite honestly, this particular list is quite long ;). We'd be happy to go into further details if you would like; just let us know.
 
Last edited:
Will this company administer the nodes?
In an ideal situation, nodes will only be administered by the internal team. But human factors like getting sick, urgent situations, family issues, etc. cannot guarantee 24/7/365 availability. The idea to have this company is to act as as an emergency backup, in the worst case, that all personnel of the internal team are not available.

We will of course teach them how to work with the nodes (some basics like monitoring with control panel, update, stop and start, etc.). It shouldn't be difficult for sysadmins (especially with experience) to learn how to work and monitor the nodes. And if any broader issues, they will let the internal team know.


How will you make sure these sysadmins know what to do?
As far as metric / issue tracking for the external monitoring group, the most basic and important tasks would be:
  • Check if this control panel working. If its not running that means the node itself is down, could be either the factomd daemon is not running or the server is down.
  • Inform how to monitor block height that will help to identify network stall if the block height is not moving.
  • Checking block minute.
  • Checking node sync status, especially after start/restart.
  • Checking node status like Wait or Ignore, especially after start/restart.
Finally, informing them how to read other information on control panel would be ideal, but the above is enough in our opinion. If you have other thoughts, recommendations, or comments, of course these are quite welcomed.

On the communication topic, we will have a website dedicated to showing how well our servers are performing in real-time. This would be similar to Ethstats.net for the Ethereum network, showing all relevant auditing statistics to any party interested. To communicate directly with Standing Parties on server performance issues, we will use Discord primarily for community interaction. We would use Discord and Twitter for announcements and other push-based broadcasts. We would also provide our own forums or, if Standing Parties prefer, communicate with them directly through a special forum area in the Factomize forums.


Final thoughts - Thank you for taking time to ask questions and read our responses. We understand the immense task at hand, and appreciate the time and commitment you've shown to the Protocol. If any last-minute questions, we will be happy to answer.
 
Top