RewardChain

David Chapman

Factomize
Thank you for the application! Some questions to start:

A. If I understand things correctly, you will conduct an ICO with the same company you use to run your Authority Node. This company will be incorporated in New Zealand. How is the regulatory environment surrounding ICOs in NZ?
 

Alistair McLeay

RewardChain
B. What platform will RewardChain be ICO'd on? Ethereum? Factom? Or?
We are currently exploring options and are organising talks with Paul Snow to see how feasible it is to launch an ICO on Factom as it doesn’t have smart contracts yet. We are also looking at the Ethereum blockchain, and integrating Factom to provide immutable audit trails of the tracking data we will be collecting.
 

Alistair McLeay

RewardChain
Thank you for the application! Some questions to start:

A. If I understand things correctly, you will conduct an ICO with the same company you use to run your Authority Node. This company will be incorporated in New Zealand. How is the regulatory environment surrounding ICOs in NZ?
Yes that is correct. The regulatory environment in New Zealand is generally friendly. We have experience with lawyers and regulators regarding token sales in New Zealand, through a previous project. The Financial Markets Authority (our equivalent of the SEC) is taking an open stance—being careful not to stifle innovation. Note that we have not finalised our legal structure and are exploring different jurisdictions with our lawyers to ensure New Zealand is the best place to launch our utility token sale.
 

David Chapman

Factomize
Thank you for your responses. I'll come straight out with what I like but my concern:

You have a great team. Savvy business people, avid Factom Community member, and strong technically. I love the tools and applications you're planning to build. But then you drop the bomb that the same company you plan to run the Auth Node and develop these tools with is also going to conduct an ICO. Whether NZ is friendly or not, there's still regulatory uncertainty. There's still huge hoops to jump through not just locally, but globally as well. I have serious worries that the ICO will become a financial, time, and energy drain on your company.

Please alleviate my concerns.
 

Alistair McLeay

RewardChain
Thank you for your responses. I'll come straight out with what I like but my concern:

You have a great team. Savvy business people, avid Factom Community member, and strong technically. I love the tools and applications you're planning to build. But then you drop the bomb that the same company you plan to run the Auth Node and develop these tools with is also going to conduct an ICO. Whether NZ is friendly or not, there's still regulatory uncertainty. There's still huge hoops to jump through not just locally, but globally as well. I have serious worries that the ICO will become a financial, time, and energy drain on your company.

Please alleviate my concerns.
Thanks for your clarity. While token sales are certainly a grey area currently, this is the same for any new highly disruptive technology, Factom included. It means a very high level of care and professionalism is required, and we are dedicated to ensuring this.

In terms of applying with the same company, let me provide some context, and outline why I believe this is actually a strong point, rather than a risk.

We are currently pivoting from a different startup in the circular-economy, reusable plastics space (building consumer software) to RewardChain, which is pursuing a token sale to build a reward-based network. We are also building software applications for enterprise customers, and will integrate the token network into these applications.

We wish to integrate Factom closely into RewardChain by running an Auth Set and including these responsibilities as a core part of RewardChain’s business. As we grow we will be attending plenty of conferences, giving talks, forming partnerships with key players in the blockchain space, and we would love for Factom to directly benefit from all of that activity.

Paul has mentioned that with the new structure this year he would like more exposure within the blockchain space, rather than just the large, slow, traditional enterprise world. I believe we can contribute to that in a really meaningful way.

A successful token sale will give us serious capital to deploy to growing our company, and growing our efforts to contribute to development and marketing of the Factom Protocol. We intend for Factom to be integral to our company, whether we utilise Factom to provide immutable audit trails for our data collection, or do the “first token sale on Factom”. As our company grows, we will have more and more resources to deploy to further the Protocol; through development efforts and initiatives to gain more exposure.

We are working full-time on RewardChain, and if selected for M3, will be dedicating serious time and efforts to our work as Auth Node Operators. We aim to grow our team quickly throughout this year, and will be dedicating time to developing Factom, regardless of whether we successfully carry out a token sale or not.

We already have a partner company in Australasia that has committed to integrating our first enterprise application into their business, and we have other fundraising options. We are not dependent on a successful token sale, and the outcome of this initiative should not affect our ability to commit serious resources to Factom.

We are big Factom nerds. We strongly believe in Factom’s vision, and contributing to making that a reality—both personally and as a company. Regardless of what plays out with our token sale plans, as a group of founders, and as a company, we will continue to provide long-term support to Factom by running an Auth Set. Whatever we need to do to ensure long-term stability and progress to Factom, we will do.

I appreciate your honesty, and the opportunity to explain what we are planning in more detail. Please continue to engage with me regarding any further concerns you have.
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK01)
A token sale is definitely not the same anymore as the last few years. It takes money first to maybe receive money in the end. Is there a specific reason why you choose to do this from a single company?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK02)
We have established a comprehensive financial plan to ensure we remain functional and can contribute to and further the Protocol, regardless of the price of FCT and BTC.
Could you provide us some insight, since you are starting of with 3 fulltime employees
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK03)
You talk about pivoting above. Does this mean your current endeavor which you have been building software for 6 years for, will come to an end? Please explain
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK04)
Firewall - We will have a firewall in place so that only the peer to peer port for the nodes and the SSH port is open.
Could you elaborate on the type of firewall? Could you elaborate on the open SSH ports?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK05)
In your architecture picture you are mentioning automatic monitoring of attacks. Could you elaborate on how you determine whether a node is under attack?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK06)
In you architecture picture you are mentioning automatic brain swapping. Could you mention either potential positives and/or negatives with having that automated?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK07)
You pledge 35% efficiency for one node as well as two. You start with 3 full time employees. Could you explain? At what price does FCT have to be with one node to still be operational?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
NK08)
You state a raid 10 setup and separate disks for OS and Data on a VPS. Could you elaborate on the amounts of disks involved and the storage type employed by the cloud provider?
 

Alistair McLeay

RewardChain
NK01)
A token sale is definitely not the same anymore as the last few years. It takes money first to maybe receive money in the end. Is there a specific reason why you choose to do this from a single company?
Thank you for the questions. I appreciate the opportunity to clarify a number of critical things about RewardChain. Some of my answers to your questions would overlap, and I have tried not to repeat myself. For this reason please read all answers to your non-technical questions together—for the fullest context I can provide.

Yes we are aware it takes money first to receive money in the end. We are taking our legal and regulatory compliance extremely seriously, and this, of course, requires significant capital. Between the four co-founders, we have sufficient personal capital we can draw on to fund these efforts. We also have access to a range of equity investors (angels, VC’s, institutional investors) and can draw on them if needed.

Please see our response to DChapman above, where we address his similar question and outline why we believe doing this under a single company is actually a strength, not a risk.
 

Alistair McLeay

RewardChain
NK02)

Could you provide us some insight, since you are starting of with 3 fulltime employees
Between the four co-founders we have capital we can draw on to fund our efforts. The initial three full-time staff are all co-founders, and are in financial positions to support themselves. We will be taking a salary of 21K USD each, annually. We are reinvesting all other revenue into growth and development/marketing efforts. We will be dedicating serious time to furthering the Factom Protocol, integrating Factom into the solutions we are building, and advertising Factom as a key part of our infrastructure to our prospective clients.

We have a 2018 budget, but due to its confidential nature I cannot share it outside the company.
 

Alistair McLeay

RewardChain
NK03)
You talk about pivoting above. Does this mean your current endeavor which you have been building software for 6 years for, will come to an end? Please explain
If you are referring to Schalk, our CTO, having 6 years commercial software development experience and working for Cisco Systems; as of this Friday he will be working full-time on RewardChain.

We recently started a company, RefunMe, with a slightly different team. One member of that team had been working on another company, which has already been in the space we were operating in for 6 years (providing circular economy physical solutions to events and organisations to end single-use plastics).

We are now pivoting to a new company, with a slightly different team, and a new vision—one with a broader focus on building a decentralized, token-based network to incentivise favourable behaviour within service-based businesses. We are also building consumer and enterprise software applications under RewardChain, our new private company, for this use-case.

Factom will be integrated closely into our above vision. We are going to utilise the Factom Protocol within our token-network, whether that is for creating immutable audit trails or launching ‘the first token sale on Factom’. If selected to run an Auth Set we will focus a large portion of our efforts on furthering the protocol, and will continue to do so as we grow our team.

We believe this new structure will have huge benefits for Factom. Unlike companies who are solely operating as Auth Set Operators, we have other revenue sources, and can provide long-term consistent support without concern over the daily, weekly, or monthly fluctuations of FCT.

We as a team and a company want to support Factom in a very serious way. We have significant personal holdings of FCT and have no plans to change that. This is both a passion project of ours, and a business strategy to benefit both Factom and RewardChain.
 

Alistair McLeay

RewardChain
NK07)
You pledge 35% efficiency for one node as well as two. You start with 3 full time employees. Could you explain? At what price does FCT have to be with one node to still be operational?
The three full-time employees are co-founders, and we all have the financial resources to go without pay. Because of this, we can endure any FCT price and still provide ongoing long-term stability and development to Factom. We see Factom as being an integral piece of what we do at RewardChain, long-term, regardless of how profitable running an Auth Set is short-term.

We have decided on 35% efficiency as we believe it is the best balance between contributing a meaningful amount to the Grant Pool, and having sufficient revenue to dedicate specifically to furthering the Factom Protocol. This efficiency has been selected for both one and two servers because we will adjust our spending on furthering the Protocol, according to how much revenue we receive as AuthSet Operators (i.e. with two servers we will contribute twice as much resources).

The 35% accomplishes our goals of contributing a relatively large sum to the Grant Pool, which we believe is incredibly important, and keeping significant revenue to drive our own development efforts.
 

Alistair McLeay

RewardChain
NK04)

Could you elaborate on the type of firewall? Could you elaborate on the open SSH ports?
At the start, we plan to use digitalocean hosting exclusively. We will use their provided cloud firewall to setup the inbound/outbound rules.

We will leave a port open (we won’t use the default port 22) for SSH access in to each VPS for maintenance and updates.

Sorry, also, I meant SSH port not SSH ports. When writing the answers to the application, we were contemplating if there were any benefits to having direct SSH into the docker container for some maintenance, but decided it would be better to just have the one SSH port into the VPS itself open.
 

Alistair McLeay

RewardChain
NK05)
In your architecture picture you are mentioning automatic monitoring of attacks. Could you elaborate on how you determine whether a node is under attack?
Here is our current thinking on this:
  1. Check that the packets coming into the guard nodes are valid Factom Protocol messages (if we have a flood of “garbage” messages coming through, this could be an indication of an attack).
  2. Setting up fail2ban and using the log as an indication of a possible attack (however, noting that we are more concerned about detecting attacks that would bring down the nodes or prevent the nodes from passing the correct messages to the authority servers, we are less concerned, for example, about bruteforce attempts to log into SSH as we will be using SSH keys for login instead of passwords).
  3. Monitoring the overall health of the Factom network - if suddenly lots of nodes in the network go down in one go, that might be an indication of an attack, in which case we might like to be proactive and start spawning additional guard nodes.
We will do an in-depth analysis before deciding on how attacks are detected.
 

Alistair McLeay

RewardChain
NK06)
In you architecture picture you are mentioning automatic brain swapping. Could you mention either potential positives and/or negatives with having that automated?
While we haven’t developed the automatic brain swapping yet, to provide some context, our approach was to have another application (that we would develop) running on each node which would expose a RESTful API for monitoring information on the nodes and also for “doing” the brain swap.

Potential positives:
  • Removes the chance for human error.
  • Allows for faster, more streamlined maintenance.
  • Allows us to keep an audit log of any brainswap activity.
Potential negatives:
  • Potential bugs - this is a big one, while we believe that the brain swapping will be a simple task to automate and is just modifying an isolated file, we would be able to thoroughly test it - but from personal experience, software bugs are inevitable.
  • We would have to open up an additional port for the RESTful API that can be accessed by our “Factom Node Manager”. From a security point of view, the less ports open, the better.
  • Having the ability about doing something like a brainswap at the push of a button, makes it almost, “too easy”, that a system administrator might not think through if a brainswap is necessary as they won’t go through the same thought process of doing a brainswap. I mention this, because there was chatter on discord about some updates potentially needing to be backward in order to do a brain swap. We could improve this by providing confirmation messages before actually doing a brainswap, to make sure whoever is doing maintenance has thought through things properly.
 

Alistair McLeay

RewardChain
NK08)
You state a raid 10 setup and separate disks for OS and Data on a VPS. Could you elaborate on the amounts of disks involved and the storage type employed by the cloud provider?
Digitalocean provides SSD backed block storage volumes that we can attach to our droplets (VPS). We would be using 4 disks for the raid 10 setup.

We have decided with a raid 10 setup to increase redundancy and improve read performance. It is worth noting, the block storage volumes on digitalocean do go through a network. So there would be a concern around latency and network congestion.
 

Matt Osborne

Go Immutable
Exchange Working Group
Legal Working Group
Hi everyone. This was easily one of the most thorough applications we've had. Thank you. You obviously have put a ton of time into it as well as being a part of the community. Another thank you. Not a lot left for me to ask, as David and Niels did a nice job. I will go on record though and share the same concerns as David did about the ICO.
 

David Chapman

Factomize
C. 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 35%. 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?
 

Alistair McLeay

RewardChain
Hi everyone. This was easily one of the most thorough applications we've had. Thank you. You obviously have put a ton of time into it as well as being a part of the community. Another thank you. Not a lot left for me to ask, as David and Niels did a nice job. I will go on record though and share the same concerns as David did about the ICO.
Thank you very much. I’m more than happy to engage with you on your concerns about the token sale, as I do truly believe it is a positive for Factom. I understand concerns related to risk—and we are being extremely diligent in protecting RewardChain with expert lawyers and engaging with the relevant regulatory bodies globally. We will not undergo a token sale if we believe there is any significant risk to any of us personally, RewardChain Limited as a company, or Factom. We will also not undergo the token sale if we do not continue to believe it will have a meaningful benefit to Factom.

Please feel free to share any concerns you have that I can address specifically. We have carefully chosen our structure with the best intentions in mind for our commitment to Factom, and I hope to explain this as clearly and accurately as I can.
 

Matt Osborne

Go Immutable
Exchange Working Group
Legal Working Group
How were you planning on structuring this token sale (open to everyone, just accredited investors, just VCs, etc.)? Thanks
 

Alistair McLeay

RewardChain
C. 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 35%. 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?
Thanks for your questions.
  1. We will communicate with the Standing Parties through several mediums. We will be active on Discord daily, which I have been doing for the last 6+ months. We will also check in to Reddit daily, which I also have been doing for quite some time—we also plan to increase our activity on Reddit, as we believe it is valuable for increasing exposure to Factom.

    We will establish a way to frequently update the community and Standing Parties on our progress—monthly updates via a Medium blog is my current thinking.

  2. We do not yet have a concrete plan of what we will communicate. We will be transparent and be very engaged with the community on all mediums. Open and frequent communication will be a key part of our culture.

    We will engage with the community and Standing Parties to establish best practices for communication. I do not want to finalise our communication strategy yet, as I believe working actively with key players over the initial weeks and months will be critical to setting it up in the best way possible.

    We will publish our development roadmap to the community for each new project we begin, and will strive to keep the community as up to date with our progress as is reasonable. We will be doing agile development, delivering an MVP at the start, followed by deliverable pieces every few weeks. This allows for early usage and feedback, meaning we can be flexible with requirements based on community input.

    As mentioned in 1, we will likely post a monthly Medium Blog outlining our achievements, development progress, and latest efforts to increase Factom’s exposure, particularly within the cryptocurrency space (a priority for us).

  3. Similar to 2, I do not think this should be fully established yet due to the uncertainty we face around what is most important for Auth Node Operators to focus on in the coming months. However, currently I believe there are several metrics that would very likely be valuable:
    1. Frequency and quality of communication on Discord, Reddit, and other social media platforms
    2. Volume of development work completed in our monthly Medium updates
    3. Impact of efforts to increase exposure of Factom (measured through Medium monthly updates and through the reach of marketing initiatives)
As a final note, I will make it a priority for me as CEO to be available every day (with a few exceptions due to travel, sickness etc.) to the Standing Parties, to answer any questions they have.
 
Top