This entry might be using an old signature, or it was signed by a key that does not exist on the server.
Thanks for all the insightful questions. We have provided answers to all questions in the below post. Thanks for your consideration and for the hard work getting M3 up and running.
Q1: I see one engineer on staff but then your application says more than one team member will administer the nodes. Who are these team members?
Our on-staff engineer will be the primary lead and he will be supported by our data science team who have significant dev ops experience, as well as some team members who have engineering and software backgrounds (e.g. Kyle). We also have the ability to leverage our network of developers within the crypto space to assist with any potential issues, as well as the option to hire new team members or external consultants, if need be. Additionally, that added expense is something we can finance ourselves from our own balance sheet and not something that we would need to sell FCT to achieve.
Q2: How did you determine the 30 / 30 Efficiency rates? For example, were those based on certain calculations you can share?
We understand the importance of community in the success of the protocol so pledging 0% was never a consideration. As such, we tried to take a balanced approach and consider a variety of factors in our proposal including, but not limited to:
[*]Multicoin’s value-add component and the effect it can have on FCT price
[*]Potential value from holding FCT under various utilization rates in the protocol
[*]Ability to partake in governance aspects of the protocol
[*]Sensitivity analysis (stress test) of FCT price under various scenarios
[*]Operational costs to administer the nodes in a safe and reliable manner
While the grant pool is an interesting concept, there are other methods in which a group can add significant value to the protocol. Much of the value that Multicoin plans to add will be outside the scope of the grant program. As such, we want to be able to retain as much FCT as possible to align our incentives with the long-term success of the protocol. We expect that a significant portion of our return will be generated through appreciation in FCT price, which is uniquely correlated to utilization of the protocol.
Q3: From Multicoin's perspective, what does Factom (the protocol, not Factom Inc) need to accomplish in order to become a standard component of a cryptofund's portfolio?
To become a main staple of a cryptofund’s portfolio Factom needs to improve transparency, utilization and liquidity.
Due to the elegant design of the token model and its underlying economics, the value of the token will be a function of the utilization of the protocol. As such, the investor community would greatly appreciate details and metrics around the usage of the protocol. We understand that many of the enterprise clients want some sense of privacy, but major KPIs and metrics such as total records committed each month, total unique clients committing records (additions, deletions, net), average and median records submitted by client, concentration of usage by top 5 or 10 clients, etc. Furthermore, to the extent that major enterprise clients are leveraging the protocol, enhancing the PR around their involvement (with their permission of course) will be critical to driving awareness to the protocol, the use case and how Factom is solving a major problem.
Factom is a protocol about data integrity, which is not a particularly sexy subject. However, one application of data integrity is kind of sexy: provenance. Provenance is understandable by investors, and is a massive opportunity globally across asset classes. Presenting a vision to enable others to build provenance solutions per vertical on Factom would go a long way to driving awareness from institutional investors.
Liquidity is also a requirement for inclusion in a fund’s portfolio. Funds that are managing significant capital need to be able to deploy that capital in an efficient way. If there is limited liquidity for an asset, it’s unreasonable for funds to spend multiple days or weeks trying to build a position in an asset without driving the price of the asset meaningfully higher. Furthermore, that strategy is challenging from a risk management perspective. As fiduciaries to investors, fund managers cannot risk getting stuck in a position because there is minimal liquidity. Many funds have risk management protocols in place that set thresholds around position sizing relative to liquidity to allow for a timely exit in certain market conditions. Limited liquidity results in a fund having to take smaller positions and at some point, the position becomes too small to have a meaningful impact on portfolio construction so the asset never gets included.
It would also be helpful to have more transparency around the organizational structure/chart, the members involved in the protocol, the authority nodes, etc.
Multicoin is well positioned to assist the Factom protocol to achieve these objectives.
Q4: Each authority node stays hidden behind its own self-healing “guard node” network. Can you elaborate on this?
Each authority node will utilize aws’s firewalling and factoms special peers to ensure only guard nodes will be able to connect to it. The guard node network will use aws’s auto scaling ec2 instances to ensure a full set of guard nodes (and hence the authority node) stays online. The process will be fully automated such that accidental DOS attacks should cause no loss of liveness, and only large scale, directed DOS attacks could potentially cause an outage.
Q5: “We will use monitoring tools to notify each member of the on-call support team across email, text, and phone.” Monitoring is a broad subject. Could you inform us about what you would be monitoring and how you would do that?
We would be monitoring server throughput and factom uptime. Throughput will be monitored via AWS logging, and uptime will be monitored via several methods, including but not limited to: (i) AWS logging; (ii) a heartbeat websocket connected to the backup node; and (iii) another heartbeat websocket connected to an in-house notification stack to automatically and programmatically send alerts to our team.
Q6: Could you elaborate on the role of the specialized company proving fallback?
This was checked pre-emptively and coincides with the answer provided above in Q1. We feel we have adequate in-house capabilities to administer nodes in a safe and reliable manner. However, we are focused first and foremost on the stability of the Factom protocol. As such, we are prepared to engage external parties to assist, if required. We are also prepared to fund that from our own balance sheet and will not be reliant on selling FCT.
Q7: Could you elaborate on the raid 10 setup in combination with AWS?
We will use AWS EBS and attach 4 volumes to each authority/backup instance. We will then simply use ubuntu’s built in RAID setup tools to create our RAID 1+0 setup (2 raid 1 arrays combined into a raid 0 array.) This will enable us to have both redundancy in the unlikely event of disk failure, as well as an overall IO boost.
Q8: What would be the minimal FCT price whilst operating one node to remain profitable?
The AWS spend for a single node should be around $2000/mo. At steady state, 73,000 FCT to 63 Authority servers monthly works out to a breakeven of slightly less than $2 per FCT. However, at that point it’s likely that the network utilization has increased and will require more operational expense so it’s not exactly an apples-to-apples comparison.
While we have considered the breakeven price of running nodes into our analysis, it has not been a major consideration in our decision to move forward in our application to become an authority node. We are very much long-term investors and we want to retain FCT so that we can be aligned with the success of the protocol over time and get exposure to value we feel we bring to the protocol.
We believe in the value that the Factom protocol can create and want to help make that possible.