Thanks for the detailed write-up. Follow-up question: How are you going to get all these vendors to use the same solution (Factom)?The first has to do with log verification. VFX production for any major feature film passes through the hands of hundreds of vendors throughout the world.
Could you elaborate on this alert system? What will be monitored for instance? What do you regard as "abnormal activity"?We will build an alert system through our cloud provider to receive notifications of abnormal activity.
Could you tailor that claim to Factom and provide both possible positives and negatives if applicable?Entirely digital workflow: Everything from the source material to the end product is entirely digital and natively writable to the blockchain.
Do you thing there are exceptions for certain type of node operators? If so could you explain?As such, Block Party’s core team pledges to self-finance our first year of operations rather
than selling tokens we receive to fund working capital. The only FCT we sell will be to cover
tax liabilities from disbursements. We believe this is a standard that should be considered for
adoption by all entities participating in the initial Authority Set, as it will greatly reduce
downward price pressure in the FCT market.
Could you elaborate on the type of work these 2 teams will be doing? How do your own 2 system administrators fit into this picture?We will have a maintenance team available 24/7 in two locations: Abu Dhabi, UAE and New York, NY USA.
ISO 27001/27002 encompasses a wide array of topics in the IT security space, so it will be difficult to touch on all of them here. It forms the basis of content security policies in the VFX industry, so we have implemented and are well-versed in all the best practices.Thank you for your application
Could you give us some examples?
We plan to host an alerting server inside of each geographic zone. Logging and alerting will be handled through Splunk, and network interface and general server uptime monitoring will be handled through Observium.NK02)
Could you elaborate on this alert system? What will be monitored for instance? What do you regard as "abnormal activity"?
Please see our response to Matt O's question above, which adds further detail and covers the positive aspects. Any negatives we’re aware of would seem to be the potential pitfalls of blockchain technology more generally, outside the scope of this proposal.NK03)
Could you tailor that claim to Factom and provide both possible positives and negatives if applicable?
We will strip out all unused daemons and services from our Linux build, lock permissions to Factom data to only the username that runs Factom/Docker, set permissions so that systems administrators only have access to the data they require, ensure each sysadmin has their own user/certificate, set a weekly update schedule for critical system security fixes, and send all system logs to an external logging server to check for abnormal activity.NK04)
Could you name a few hardening actions you will perform on the Node itself?
We believe that it's natural for different aspects of the protocol to progress at different rates - all of these parallel activities wrapped up in M3 aren't intrinsically intertwined. In the case of liquidity, we don't think the conditions are optimal for this new supply to come online. So while we can't restructure the disbursement schedule, as it's hard-coded into the protocol (we believe), we can, as a community, institute a vesting schedule for node operators that better aligns everyone's interests. Can there be exceptions? We're not sure - that probably has to be part of a larger conversation with the community. However, we think it's important enough to pledge our commitment to vesting as an individual entity.NK05)
Do you thing there are exceptions for certain type of node operators? If so could you explain?
Yes, they’d be willing to pay the cost associated with the entry credits, and that is factored into our financial projections. However, this gets back to the liquidity question. The best and most sustainable use of FCT distributions is to utilize them for their intended purpose - utility - i.e., generating entry credits. This is our approach. We think imposing a vesting schedule for node operators would incentivize rapid development on their part, as they wouldn't be able to sell FCT for fiat, but they would be able to burn them for entry credits. So at least in the short term, node operators would be strongly incentivized to build demonstrable utility on top of the protocol, and that benefits the protocol in the long term.NK06)
You are talking about application development and using the FCT to accumulate more Entry Credits. Given the pegged price of Entry Credits, wouldn't your customers be willing to pay for the registration then?
Please see posts above with Matt O for more details on the specific applications. Funding is an open question, but we would either self-finance or raise outside capital (leaning toward outside capital). Good investors bring more value than just money - they bring all their relationships, expertise, and experience. So we think that raising money and giving influential people an interest in the success of the protocol would create additional value for everyone. As for checks and balances, we're not entirely sure what you mean -- could you clarify?NK07)
You never go into greater details about possible applications you will be developing. How will the development be funded? What are the checks and balances?
Given how many entities will be involved, we don't see our deferment/financing as something that would provide undue influence. It would give us a seat at the table, which is what we're really after. However, we do understand the concern, and are willing to discuss it further and work with the community to find solutions to address it. One solution could be that any node operator is only allowed to stake 50% (or some other %) of their token distribution, effectively leveling the playing field regardless of each entity's efficiency.Using your economic model and with the proposed levels of deferment to the grant pool, there could be some concerns:
You could gain a lot of influence as a standing party. Could you give us your vision about this?
We are advocating an approach which involves vesting tokens and promoting utility through FCT burning, all of which prevent dumping. After our vesting schedule lapses, we (and all other entities) will sell FCT at prices which they deem to be advantageous. This isn't a bug, it's a normal part of price discovery. The most pressing question is how we deal with this liquidity situation in the short-term. We have proposed solutions for this, but it's ultimately up to the community what standards are adopted. In the long-term, through intiatives promoted by the authority set, we think liquidity will expand to a point where the node-based inflation is not a significant concern.Using your economic model and with the proposed levels of deferment to the grant pool, there could be some concerns:
What are the guarantees you aren't going to accumulate a lot of FCT and dump that on the market once price has taken of?
Our Head of Technology is based in Abu Dhabi, and will be the primary architect and administrator for our nodes. Our NY based sysadmin (Josh Morrissey) will act as secondary support when our HoT is unavailable. We plan on creating a daily hand-off system to ensure that the two sysadmins are aware of each other's activities on a daily basis, with uninterrupted coverage. We'll be able to respond to issues within minutes, and have budgeted to add additional support staff if necessary.NK10)
Could you elaborate on the type of work these 2 teams will be doing? How do your own 2 system administrators fit into this picture?
This is a great question. Creating a system that holds entities accountable for their progress will be essential to the success of the protocol. As we’ll be a private company, it won’t necessarily be to our advantage to disclose everything all the time, but we’re more than happy to be as open as possible at regular intervals - possibly through progress updates in the form of a blog or Discord Town Hall. We’d likely have a Twitter account for the company, though we doubt that would be the main source of information (at least in the early stages). In a broader sense, it feels like the best way to handle this might be for the protocol to have a committee set up for this purpose, which checks in quarterly with the node operators to get a sense of their progress and confirm that they’re actively working towards their stated goals.Thank you for your application.
I think your use case is fantastic and that you have the team to pull it off. My question:
A. 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 since your single node Efficiency is set at 25%. 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 success?