Block Party

ThinlySlicedMeat

Block Party
Hi Matt! In general terms, we see two main opportunities in this space.

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. Currently, movie studios require vendors to follow specific IT security procedures and store their log files for a number of months. In the event of a security breach, they examine these logs to identify the source of the leak. The problem is, this process depends on trust. There is nothing stopping a non-compliant vendor from altering their log files after the fact to cover their tracks. By hashing vendor logs into the Factom blockchain at regular intervals, our solution will allow studios to bridge this gap, establishing a trustless verification system.

From a business standpoint, this will provide significant value to our customers. Content leaks create large liability in dollar terms -- just think of the cost to HBO if the new season of Game of Thrones leaked early. This dynamic sets up attractive market conditions for adoption, as it creates a more secure environment and saves money.

The second area has to do with supply chain management. Since the entire VFX pipeline is digital, we can create a number of different solutions which solve the "last mile" problem present in many blockchain concepts - ie bridging physical to digital. Through a system of hashing vendor-specific metadata into the blockchain, we will be able to track assets (video, CGI, etc) through the VFX industry's global supply chain in real-time. The implications of this technology are vast, from monitoring compliance to enabling new distributed production models.

Given our experience in this industry, we believe that we can sell these solutions through to studios relatively quickly and build it into an industry standard by working with the MPAA. I'm not sure how much deeper into the details I can go in a public forum, but if you have further questions on specific areas, let me know and I'll be happy to try and fill in some color.
 

Matt Osborne

Go Immutable
Exchange Working Group
Legal Working Group
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.
Thanks for the detailed write-up. Follow-up question: How are you going to get all these vendors to use the same solution (Factom)?

Thanks
 

ThinlySlicedMeat

Block Party
By selling the movie studios (Disney, Fox, etc) and/or the MPAA (the self-governing body in this space). The studios already mandate specific IT security policies to their supply chain, which forces those standards through the hundreds of different vendors that support their productions. It's one of the other reasons we think this industry is particularly attractive. By selling a handful of customers (studios), our solution can reach global scale/adoption rapidly.
 

Matt Osborne

Go Immutable
Exchange Working Group
Legal Working Group
By selling the movie studios (Disney, Fox, etc) and/or the MPAA (the self-governing body in this space).
Disney alone has a market cap of $150 billion. How do you get them to listen? Thanks
 

ThinlySlicedMeat

Block Party
Sure, these are big companies, but the decision-makers in content security are a pretty small community. Previously I was the CEO at one of the biggest suppliers in this space (and Matthew was CTO). We've been working with these people for the past 7 years, so getting in the door won't be a problem.

As far as selling the product through, it really comes down to tailoring a tight value proposition that demonstrates P&L savings. As with any sales strategy, you have to know what your customer needs and how you can help them deliver more value. We have a pricing strategy that will enhance security while saving studios money, something customers always listen to. :)
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK02)
We will build an alert system through our cloud provider to receive notifications of abnormal activity.
Could you elaborate on this alert system? What will be monitored for instance? What do you regard as "abnormal activity"?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK03)
Entirely digital workflow: Everything from the source material to the end product is entirely digital and natively writable to the blockchain.
Could you tailor that claim to Factom and provide both possible positives and negatives if applicable?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK05)
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.
Do you thing there are exceptions for certain type of node operators? If so could you explain?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
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?

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?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
Using your economic model and with the proposed levels of deferment to the grant pool, there could be some concerns:

NK08)
You could gain a lot of influence as a standing party. Could you give us your vision about this?

NK09)
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?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK10)
We will have a maintenance team available 24/7 in two locations: Abu Dhabi, UAE and New York, NY USA.
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?
 

David Chapman

Factomize
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?
 

ThinlySlicedMeat

Block Party
Thank you for your application

NK01)

Could you give us some examples?
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.

We plan on building and implementing an information security policy and a change management policy (both adapted from our Head of Technology's previous work). Additionally, we will have clear standard operating procedures, systems will be monitored, system data will be backed up off-site, network access to nodes will be controlled, logs will be recorded off-server, logs will be protected, and we will have a clear access policy.
 

ThinlySlicedMeat

Block Party
NK02)

Could you elaborate on this alert system? What will be monitored for instance? What do you regard as "abnormal activity"?
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.

We plan to monitor system logs, network interfaces, CPU usage, and other important system functions.

We consider "Abnormal Activity" to include very high CPU usage, high network interface utilization, server unresponsiveness, and system service outages.
 

ThinlySlicedMeat

Block Party
NK03)

Could you tailor that claim to Factom and provide both possible positives and negatives if applicable?
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.
 

ThinlySlicedMeat

Block Party
NK04)

Could you name a few hardening actions you will perform on the Node itself?
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.
 

ThinlySlicedMeat

Block Party
NK05)

Do you thing there are exceptions for certain type of node operators? If so could you explain?
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.
 

ThinlySlicedMeat

Block Party
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?
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.
 
Last edited:

ThinlySlicedMeat

Block Party
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?
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?
 

ThinlySlicedMeat

Block Party
Using your economic model and with the proposed levels of deferment to the grant pool, there could be some concerns:

NK08)
You could gain a lot of influence as a standing party. Could you give us your vision about this?
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.

An additional note on deferment (and please forgive us for getting a little philosophical here): at face value, maximum deferment seems like it would be advantageous to the protocol, but we question this from a structural standpoint. For systems to advance rapidly, they need a healthy mix of centralized planning and free-market forces. While the deferment/grants will provide an essential source of centralized funding, that decision-making process is susceptible to the kind of planning-by-committee that can stifle innovation. We feel we should balance this out by allowing node operators to deploy resources in pursuit of their individual strategies, creating a robust marketplace of ideas. By over-leveraging node operators with 50% deferments, we could risk sacrificing the market forces that promote the kind of independent thinking that can lead to transformative innovation.
 

ThinlySlicedMeat

Block Party
Using your economic model and with the proposed levels of deferment to the grant pool, there could be some concerns:

NK09)
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?
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.
 

ThinlySlicedMeat

Block Party
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?
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.
 

ThinlySlicedMeat

Block Party
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?
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.
 
Top