Consensus Networks

Greetings and thank you for campaigning.

Is there an additional document somewhere I'm missing? For example, I only see first names used in the posted doc and would like to research your team.

Thank you.
 
Greetings and thank you for campaigning.

Is there an additional document somewhere I'm missing? For example, I only see first names used in the posted doc and would like to research your team.

Thank you.
Thanks for letting us know - I'm attaching our executive summary and team bios - this will have what you need. The public application encouraged not using last names, but I have no problem sharing them. Let me know if you need anything else!
 

Attachments

Welcome and thank you for applying. Questions will be asked next few days. Please check back often and reply as promptly as possible.
The public answers to the questions in the form are attached
Thank you Niels, one point of clarification I would like to make with respect to the test net - we are not yet onboard, but hopefully will be by the end of the week. Thanks!
 
Hi Consensus,
Thanks for applying! Could you break out:
1. What pledges you are making to grow the protocol via grants (if any)?
2. What pledges you are making to grow the protocol in general (via ANO payouts or simply by time/resource dedication)?

Thanks,
Matt
Hi Matt,

In terms of grants, we are pledging to operate at 50% efficiency, ensuring that 50% of the total awarded FCT goes towards the grant pool. Specifically, we would love to see continued grant funding for continued growth and securing of the network as well as provide funding for continued innovation on the platform whether it be Factom products or on-chain protocols.

To grow the network, we will be showcasing the use cases Factom has for our clients as well as working to bring additional customers to the Factom platform. We also want to do proof of concepts with existing Factom products (Harmony and dLoc) and bring them to possible users. Our overall goal being to help expand the use of Factom, bringing in new users trying new products. One of our foundational goals at Consensus is not just providing infrastructure but helping to bring blockchain technology mainstream - we need to find early adopters to prove blockchain's viability at an enterprise level.

Hope that helps and let us know if you'd like more amplifying information!
 
Thank you for applying. A few questions I am asking all applicants,
  1. How many person-hours per week do you expect your team to devote to this ecosystem?
  2. How will these hours be distributed among your members?
  3. How will this be distributed among your ANO activities (open source project dev, proprietary project dev, protocol level technical involvement, governance involvement, marketing/promotion … )?
  4. Can you give a list of demonstrable metrics that the community could use say 6 months or a year from now if you are selected in this application to evaluate your ANO?
 
Thank you for applying. A few questions I am asking all applicants,
  1. How many person-hours per week do you expect your team to devote to this ecosystem?
  2. How will these hours be distributed among your members?
  3. How will this be distributed among your ANO activities (open source project dev, proprietary project dev, protocol level technical involvement, governance involvement, marketing/promotion … )?
  4. Can you give a list of demonstrable metrics that the community could use say 6 months or a year from now if you are selected in this application to evaluate your ANO?
Hi Julian, thanks for your question:

1. How many person-hours per week do you expect your team to devote to this ecosystem?

We expect to devote appx 40 manhours/wk (average) towards Factom. Naturally, this will likely be significantly more early on as we onboard and build the Factom environment and spike during updates and restarts. Although we're using a specific number of hours, we will devote as much time as necessary to ensure our node(s) are running Factom correctly.

2. How will these hours be distributed among your members?

We’ll distribute hours in two ways, first being general effort: 25% of our time will be towards the Factom environment build/onboarding/updates, 50% of our time towards operations, and 25% towards Factom community initiatives. In terms of distribution of work among our team, Nick will lead our server deployment and environment onboarding as well as server maintenance/monitoring. Shane will lead operations while continuing to train Nate and Connor to lead the day to day LedgerOps. Nate will lead community initiatives.

3. How will this be distributed among your ANO activities (open source project dev, proprietary project dev, protocol level technical involvement, governance involvement, marketing/promotion … )?

We went into it a little bit in the previous answer but I believe the best things we’ll be suited for will be technical development and product/market development. Nick and his people are pros at server deployment and maintenance so we’d love to be able to help build a standard operating procedure for node operators – everything from security baselines to recovery procedures. Additionally, Connor and his team will be able to help with further technical developments like tools for operators and core code development as needed. We’d also like to support the community in general by helping in any way we can to scale out infrastructure and nodes through either technical support or whatever is needed.

4. Can you give a list of demonstrable metrics that the community could use say 6 months or a year from now if you are selected in this application to evaluate your ANO?

Great question – there are several things that we’d like to be known for in the Factom ecosystem

  • Uptime: Our standard is 99.99% uptime with a stated goal of 5 nines. At the sixth month point, we’d like to be able to show 99.999% uptime.
  • LedgerOps: We aren’t only maintaining our servers, we’re maintaining the ledger as well; meaning, updates done correctly and immediately, contributions to base code as needed, feedback provided to core developers to help continue code growth, and standardization of operations to help ensure consistent and satisfactory performance. Specific metrics would be demonstrated performance during updates and delivered feedback to the guides and developers as requested.
  • Product/Market growth: We’d like to show the potential of Factom by introducing its products and use cases to our growing customer base. In six months, we’d like to be able to show the Factom ledger/product (Harmony/dLoc) in the hands of no less than 3 enterprise level customers.
  • FedRAMP compliance: We are working on a roadmap to achieve FedRAMP compliance on our infrastructure within six months, once completed we’ll be able to better showcase Factom’s use cases to government clients.
 
Hi Consensus - thanks for the application!

1. What experience do you have with factomd?
2. What stopped you from joining testnet?
3. What's your Discord user names?

Cheers
Hi Bobby,

To answer your first two questions, we're new to Factom so haven't had a chance to fully explore factomd and get on the testnet, though we expect to later today/early this weekend. We're working to get our team up to speed on the ecosystem and code ASAP.

Our Discord users right now are Nate and Shane: nmiller#2564 and smfimbel#2549

Let me know if you have anything additional, looking forward to spinning up on the testnet!
 
Thank you for the application.

Another secondary benefit from this is that insurers will be able to decrease premiums due to the increased security and lack of accessibility to
malicious actors that blockchain and distributed ledger technology brings to the storage and transfer of this information. Due to the incredibly strict FDA regulations surrounding the transmission of personal health information, Factom’s smart contract technology provides an attractive avenue through which this data could be transferred.


Will you please elaborate on what this smart contract on Factom would look like and how you would use it to transfer data?

Seeing as entries are stored in chains, the FDA rules and guidelines surrounding patient data transfer, access, and storage could essentially be defined as the set of rules in the first entry of the chain, and any attempt to access, manipulate, or transfer this data in a manner not in compliance with these rules would be rejected, but still recorded as having been attempted. This would allow for improved transparency into such transactions, as well as the ease with which such data could be audited by an external third-party. Such a secure and transparent system would be beneficial to healthcare systems from an administrative and regulatory standpoint for these reasons, and something uniquely suited to Factom’s platform.

Do you anticipate storing the data on Factom itself or on some abstraction above Factom that is anchored to Factom? If you can elaborate a little more on the specifics of your ideas here I would appreciate it, thanks!
 
Thank you for the application.

Another secondary benefit from this is that insurers will be able to decrease premiums due to the increased security and lack of accessibility to
malicious actors that blockchain and distributed ledger technology brings to the storage and transfer of this information. Due to the incredibly strict FDA regulations surrounding the transmission of personal health information, Factom’s smart contract technology provides an attractive avenue through which this data could be transferred.


Will you please elaborate on what this smart contract on Factom would look like and how you would use it to transfer data?

Seeing as entries are stored in chains, the FDA rules and guidelines surrounding patient data transfer, access, and storage could essentially be defined as the set of rules in the first entry of the chain, and any attempt to access, manipulate, or transfer this data in a manner not in compliance with these rules would be rejected, but still recorded as having been attempted. This would allow for improved transparency into such transactions, as well as the ease with which such data could be audited by an external third-party. Such a secure and transparent system would be beneficial to healthcare systems from an administrative and regulatory standpoint for these reasons, and something uniquely suited to Factom’s platform.

Do you anticipate storing the data on Factom itself or on some abstraction above Factom that is anchored to Factom? If you can elaborate a little more on the specifics of your ideas here I would appreciate it, thanks!
Hi Samuel,

To answer your questions:

1. Factom’s ability to allow publication of immutable data and the accountability it provides since one can conduct full audits on this published data coupled with smart contracts provides a unique means to record medical record transfer. A smart contract could be set up in such a way that if an entity meets the criteria set by us and HIPAA to access data, then we could facilitate the transfer of the patient data from a HIPAA compliant server to that entity. The recording of that transaction could then be written into the Factom Blockchain directly, and therefore, there would be an auditable and immutable record of what patient data transfers have occurred, when they occurred, and which entities participated without jeopardizing the integrity of the patient data. For its initial work with the blockchain, Consensus Networks is using de-identified patient data that is in compliance with the de-identification standard as laid out in Section 164.514(a) of the HIPAA Privacy Rule as well as real data from patients with chronic diseases (diabetes) de-identified under the oversight of an Institutional Review Board (IRB) to ensure privacy rules are met. Smart contracts would be tethered to Factom to allow for time stamping, verification of who has had accessed patient health data, and hashlocking such information. Since the data has been deidentified, patient authorization is not needed in each transaction, therefore, smart contracts would only have to be proctored between ourselves and parties exchanging data (i.e healthcare providers or insurers). The obvious point here is that this is only de-identified data, which is limited in its use. I think our response in the next question begins to address what healthcare on the blockchain starts to look like.

2. Agreed that a secure and transparent blockchain system would be hugely beneficial to healthcare systems! There are a few regulatory aspects that would need to be dealt with, however. First, for the near future, personal health information will likely only be able to be stored on HIPAA compliant servers (in the U.S.), not publicly auditable blockchains. We would store the actual patient data in such servers, but the data pertaining to who has accessed the data, and what transfers of the data have occurred will be recorded on Factom. We would set certain permissions/requirements on what entities could access or transfer the data, but Factom would serve as the data repository for what transactions have occurred, not the repository for patient data.

Another interesting problem that will need to be tackled is immutability itself – for instance, GDPR (in Europe) specifies that people have the right to revoke access to their data. If their data is stored on an immutable ledger, that becomes a problem. We see the beginning of the solution begin with what we described in the previous paragraph, the data itself is stored ‘off-chain’ while the blockchain records movement of data, governs contracts, etc… The next step, we believe, will be working on an abstraction layer above Factom that transports the data, this will likely be a permissioned layer, private nodes connected to each other only as needed for data transport, or possibly some sort of zero-knowledge algorithm to ensure only those with need to know can access patient data. We don’t foresee a blockchain layer permanently holding a significant amount of patient data due to the size the datasets would become.
 
Our team is well funded through various means, including backing from institutions as well as financing
through grants.
NK01)
Just to be clear. In the above sentence you mean existing non-Factom grants right?

NK02)
Since you will be hosting your own infrastructure with it's costs. Do you have a projection for us at what price FCT has to be to break even?

NK03)
How would you make sure you keep operating even with the above quote?

NK04)
To be clear. With de-identified above you mean anonymization or pseudonymization?
 
NK01)
Just to be clear. In the above sentence you mean existing non-Factom grants right?

NK02)
Since you will be hosting your own infrastructure with it's costs. Do you have a projection for us at what price FCT has to be to break even?

NK03)
How would you make sure you keep operating even with the above quote?

NK04)
To be clear. With de-identified above you mean anonymization or pseudonymization?
Hi Niels,

NK01) Correct, we are referring to non-Factom grants.
NK02) We do - our baseline infrastructure, the specs of which are included in the grant, will incur roughly $2500/mo in operational costs total for both servers (this is our high end estimate to ensure we can cover costs). The FCT node reward at 50% efficiency for both nodes should cover those costs as long as the price of FCT remains above $2.50
NK03) First, within the community we will work towards helping to advance the Factom protocol and use cases to help bolster the price of FCT. I'm sure I speak for everyone when I say we hope the price goes up and less FCT would need to be converted to Fiat to pay for expenses. Secondly, we don't necessarily intend to exclusively be a host for Factom (the servers are always dedicated, of course) - we also provide LedgerOps as a service and are in the processing of identifying other high potential blockchains that need advanced infrastructure services. It is our hope that by maintaining a portfolio of blockchains, we will not only be able to survive price fluctuations but also develop standardized operating procedures to ensure maximum uptime and support for those blockchains we support. This will not take away from the time we have committed to the community but is part of our business model.
NK04) Yes, to be specific, most data initially used for testing will be anonymized however as needed and as permitted by the IRB, pseudonymized data (something like using a unique numerical identifier only known to the doctor and patient) would be phased in at a later point.

Hope that answers your questions, thank you!
 
1. I am surprised by you not having any plans for forming any type of corporate or real world organization. have you thought through tax implications, continuity of business, ownership of domains, etc that not forming an organization would entail?

2. I am impressed by bringing 3 tech people to the group.

3. How did you hear about the factom project and that new ANOs are being recruited?

4. To be clear, does your team have any connection to the Ethereum omnibus holding company Consensys?

5. How is LedgerOps different than normal operations, where software needs to be upgraded correctly? That is not a term I have heard before. Is this a hyperledger term I missed?

6. How will you handle brainswaps? you are only listing 2 servers on your application and don't mention alternative systems.

7. Since you aren't using cloud servers, what plans do you have for guard servers when those become recommended?

8. How has your experience with hyperledger prepared you for being part of the Factom Authority set?
 
1. I am surprised by you not having any plans for forming any type of corporate or real world organization. have you thought through tax implications, continuity of business, ownership of domains, etc that not forming an organization would entail?

2. I am impressed by bringing 3 tech people to the group.

3. How did you hear about the factom project and that new ANOs are being recruited?

4. To be clear, does your team have any connection to the Ethereum omnibus holding company Consensys?

5. How is LedgerOps different than normal operations, where software needs to be upgraded correctly? That is not a term I have heard before. Is this a hyperledger term I missed?

6. How will you handle brainswaps? you are only listing 2 servers on your application and don't mention alternative systems.

7. Since you aren't using cloud servers, what plans do you have for guard servers when those become recommended?

8. How has your experience with hyperledger prepared you for being part of the Factom Authority set?

1. To clarify that point, we are Consensus Networks, LLC. A limited liability company that is taxed as a corporation (though not technically incorporated).

2. Thank you!

3. We heard about the project and ANOs through a partner of ours who does cloud computing and were immediately interested – we just missed the first ANO deadline and were wrapping up another project when the second round was announced so jumped on the opportunity.

4. None at all – we just happened to get the domain registered early enough!

5. LedgerOps refers to the 24*7 monitoring and management of our network. Our LedgerOps team is responsible for maintaining uptime, route optimization for low latency, and ultimately the integrity of the underlying infrastructure supporting any of the Blockchain protocols supported by Consensus Networks.

6. Great point! We absolutely need to utilize a backup server to ensure brainswaps went smoothly. Our final vision would be a blade server with at a 3rd capacity reserved for a brainswap, although starting out, we would utilize cloud servers for the swap – ensuring we cue everything correctly and are monitoring the timing.

7. The guard servers/nodes are a project we find fascinating – from what we’ve read it seems as though they’re not on the main-net yet but will be soon. What we would like to do is create a cloud formation template using the best practices from those who are developing guard nodes on the test net right now, once that template is complete, we can provide it to all main-net nodes to allow one-click deployments of guard nodes which would allow for a standardized approach to the guard nodes to ensure everyone is operating them mostly the same. A hardware guard node would likely be slightly more complex/expensive however we are looking at some options there, although this would be further down the road. However, we think we could develop a main-net ready cloud based guard node template in a few months.

8. It has and it hasn’t – our work on Hyperledger is mostly through private networks, which doesn’t require the mass coordination of dozens of independent organizations – kudos to the Factom community! However, there are of course similarities to running any sort of network, be it Hyperledger or any other protocol, that will apply to Factom.

Some interesting aspects of Hyperledger (Fabric specifically), that we want to investigate further with Factom include the multi-channel properties – i.e. to what extent can organizations operating on Factom privatize and individualize their experience. Interoperability is another area we see as vital – let’s make sure Factom can be utilized via an API, or other means, with existing business processes to ensure the ease of transitions as companies move to the blockchain.
 
Top