HashnStore is a French company applying for M3 Authority Nodes. We aim to become the Francophone reference on the Factom Protocol.

Our team is composed of Matthias Fortin, Elie Bonin and Frédéric Faye, three enthusiastic French engineers.

We have posted a short presentation of HashnStore on the public Discord channel dedicated to M3 applicants.

Feel free to ask us any question.

Bien à vous.
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 SUBSTANTIAL marketing and development work which is important despite your node Efficiency being set at 40%. The Standing Parties will 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 marketing and development progress and success?
Before we reply to these questions, there are few things to have in mind in relation to HashnStore and the ecosystem it would operate in. HashnStore's connections are deep and in various spheres, and it shouldn't be taken lightly. What would cost a decent amount of marketing expenses can be achieved for free by our members. French engineering schools cultivate strong bonds between alumni, and they are to be reckoned with, and especially at Arts et Métiers ParisTech, Matthias's school. To that, should be added that regular marketing to various parties - not standing parties - can be achieved for free in a first time, as France allows to onboard unpaid interns, which is a normal practice here. The marketing labour is rather cheap in France. When financially stable enough, we will think about raising expenses on that particular aspect, through a dedicated team.
Point is: what would cost money for most to reach interested parties would be almost free for HashnStore's members. The marketing can be achieved almost for free too. This leave to the core members both time and money for tasks which most require them.

1. The communication with the Standing Parties will be split in two, what can be shared in the public sphere, and what cannot. Also, running an Authority Node implies efficiency and seriousness. Hence, we believe at HashnStore that the communication through means like Discord or Slack should be reduced as much as possible. This is why HashnStore will publish its public news on its website site first, and will get them shared through more traditional social media, such as a newsletter, Twitter, LinkedIn, and Facebook, as we aim at training students. We have to target their favorite way of sharing and receiving news. As for more sensible information, we expect the Standing Parties to come up with a centralised solution to share information; it might be a dedicated website with limited access, or an already existing application, such as Discord for the time being.

2. Given the definition of a Standing Party, we should keep in mind that these parties include both allies, and competitors. Having this in mind, HashnStore will be more than happy to share information aiming to increase the stability of the network, such as certain network or server metrics. This task can easily be automated. HashnStore also expects to display non-sensitive node information on a dedicated website, to display our node reliability.

HashnStore has pledge to share with its community a monthly newsletter reporting reached milestone, new expectations, conferences given, etc. It will be shared as stated in the first paragraph. As for the network metrics, we thought about automasing this task by sending a weekly Prometheus-feed report to a centralised place, where Standing Parties could share network intels. Let’s not forget the most important thing is having the Protocol up and running as smoothly as possible. Also, for punctual requests by the Standing Parties, HashnStore will reserve the right to assess whether the request should be addressed. Public news will be shared monthly, network metric are expected to be shared weekly solely with Standing Parties, and punctual queries will be addressed as soon as practicable if deemed acceptable.

3. In its application, HashnStore has provided a realistic timetable over the next 15 months, ensuring a slow and steady devleopment. The first three months are dedicated to schools and civil servants prospection; the next 12 months HashnStore will be training students, strengthening its political ties, and looking for interested private companies; the last three months will be dedicated to the development of Proof of Concepts and we hope a suffisant breakthrough in the political discussions.

Having this timetable in mind, gauging our marketing and development progress will be rather easy as each taken action part of the above scheme will be subject to an article, or a simple announcement (conferences, school workshops or class lessons, meetings, etc). The Protocol being young, the Standing Parties can’t afford to keep these shadowed. Also, the blockchain being really a hot topic in France, HashnStore should get any hurdle to get third parties news exposure from schools or deputies. The public roadmap and expected results HashnStore gave to itself will be public on our website, with each new achievement being duly reported on it. (number of schools reached, class lessons given, time spent in conference, etc)
The other way to gauge our marketing and development success other than getting news exposure is to use the metrics provided by social medias, such as Twitter and Facebook.They are simple numbers - followers, retweets, likes, shares, number of time displayed, etc. These should fairly reflect our success as HashnStore mainly targets students - who spend a decent amount of time on social networks - and French civil servants - who are eager to get public exposure on hot topic to drag attention.

Past these first 15 months, our success will be gauged by our ability to expand toward new countries, but also by our financial results. After having trained numerous students, HashnStore will be pleased to onboard the best talents to develop a consulting branch and much more.

Thanks for the time spent reviewing our application.
Last edited:
TH #1

Connection Down
Set a program that ping the servers every one minute to see if the connection is up or down. If one of
the main servers is down, we will act accordingly to Brain-Transfer the Authority Identity from the
defective server onto the backup server, to ensure continuous and smooth Authority Server operation.
Can you explain how you would do this in practice? If the server was operating as a federated server would it still be a federated server after this brain transfer?
We have already contacted several public figures known for supporting the
blockchain technology :
o Mounir Mahjoubi (Secretary of State for Digital) - He recently signed the “European
Blockchain Partnership” on behalf of France,
o Pierre Person (Deputy) - Rapporteur of the fact-finding mission about crypto-assets,
o Laure de La Raudière (Deputy) - Rapporteur of the fact-finding mission about
blockchain use cases.
Could you elaborate "contacted". Sending an e-mail, phoning a secretary? Had a meeting?
We will use Prometheus as the monitoring and alerting solution, as it offers an easy to deploy and
elegant interface. Signals to be monitored are:
 Host resources (processor load, disk usage, network usage, system logs, cpu temperature, and
every signal we deem necessary)
 Application uptime
On top of that, both main servers and the backup server will be subject to one-minute ping to test their
Could you elaborate on how you measure "Application uptime"?
Authority identity of main server 1 will be swapped with the AWS server, this way we can ensure a
continuous Protocol usage. While the AWS server acts as the Authority Server, the main server 1 will
also receive the update, after which another Brain-Switch will occur between the main server 1 and
the AWS server. This whole process will be repeated for the main server 2. And finally, the backup
server will also receive the update.
Given the possible timing of updates for node operators on mainnet would this procedure always yield the desired result in time according to you?
Set a program that ping the servers every one minute to see if the connection is up or down. If one of
the main servers is down, we will act accordingly to Brain-Transfer the Authority Identity from the
defective server onto the backup server, to ensure continuous and smooth Authority Server operation.
The main server will be sync again with the network and left running for at least 6 hours as such. If no
network issue occurs in the meantime, another Brain-Transfer will be processed, in order to get the
Authority Node hosted back onto the main server dedicated to it.
Could you think of possible scenario's where this could fail?
The Factom
Protocol being one of the cheapest and most secure way to get this result, it would naturally be the
chosen Protocol to enforce this new integrity paradigm. In this case, HashnStore would be the first and
legitimate third party to get legacy systems updated to support the Factom Protocol features.
You envisioned the future. Could you explain the last statement from above. Take into account that in your vision there would be a vibrant ecosystem around Factom
For the brain-swap question TH01:

To monitor our servers and get fastest response in case of downtime we will use two methods. First we will set up a simple script that ping servers to know when a server is down. This will be link with an SMTP server to send us directly an email notification. Additionally we will use Prometheus alertManager that will also alert us in case of internet connection downtime, docker down, performance issues.

In the case where one of our main servers goes down, be it from an outage or an internet connection issue, messages via both email and GSM will be sent to the core members of HashnStore, but also to the sysadmin members from Nakamotech with the methodology described above. We understand that as soon as the Federated Server is down, once back on track it would have lost its Federated Server status and would be downgraded to an Audit Server, as the Audit Servers set ensures the redundancy of the whole network.
To reply to the first question, our servers will have a special routine to avoid any reboot of the node after a certain down time. This is to ensure that a node has to be manually restarted in case of an issue. Also, as explained in the application document, HashnStore will always have a follower node fully sync with the same hardware spec as our main servers. To handle this, then, we have this solution:
As the follower node will always be fully sync, we simply have to export the factom.conf from the Authority Node to the follower node. If we can’t access to the Authority Node we will restore the factom.conf from a backup; thanks to this identity switch the follower node will then be recognised as the Authority Node, up and running
Every data transfer will be instructed through SSH by authorized people. Once the main server issue is solved, a brain-transfer will be done between the main server newly sync node and the ex-follower node.
To reply to the second question, … if the brain-transfer is processed between two running sync nodes, the Federated status is kept. While, if the brain-transfer is processed after an outage, then as explained above, the Federated Server will be downgraded to an Audit Server.

For the EU legislation question NK01:

To highlight this idea, two example were given in the application document with, we believe, a interesting synergy with the Factom Protocol.
The first given example was the MiFID directive - Markets in Financial Instruments Directive (2004/39/EC). The goal of MiFID is to bring in the European financial industry more discipline, to rise its competitiveness and to establish more reporting. In other terms, to enhance its transparency for the lawmakers.

Elie Bonin oversaw its recent application in the hedge funds he worked in, and the various difficulties it triggered on the tech side. New rules were set up with different brokers, but the biggest thing was that every single transaction has to be reported, duly detailed with all possible metadata. Once these data are sent to the authorities, there is no tamper proof way to ensure that the data have conserved their integrity. This very specific action of sending numerous trades details everyday to a centralised authority represents a golden opportunity for the Factom Protocol, as it would offer to both parties a way to protect themselves. In a not-so-far future, we envision that companies and the central authority would have to factomize/hash the daily content sent and receive, to ensure that both parties are processing the same set of data.

The second example is about the General Data Protection Regulation (GDPR) which is a massive piece of regulation to digest for every company processing EU citizen’s data. The GDPR grants various rights to the EU citizens, from the right to access data, the right to get them erase but also to get them fongible with different systems.

There is actually no real way for a mere citizen to assess whether or not the data provided by a company represents the entirety of what it has. Nor is it possible for the same citizen to be certain that the data he/she wants erased are actually processed the correct way. Having said that, there is a dedicated authority that oversees that every action is taken properly. This authority has the right to fine rogue companies. The vision HashnStore has on this particular topic is audacious, we would even say ambitious, but nonetheless it’s plausible. The Factom Protocol could be used efficiently here to ensure that the citizen’s right is preserved and respected. Let’s imagine a system where companies are willing, for instance, on a daily basis to provide to the supervisory authority a list of hashes corresponding to the data held on each customer they have, list of hashes that could be publicly accessible upon certain conditions; a citizen who asked a company to see what data it keeps on he/she would then be able to compare it with the list sent to the authority. No middle man can intercept and exploit the data, the citizen’s rights are respected, and the company proves to be compliant with the legislation.

We believe that many more example as such could be find by exploring properly the current EU legislations. People would then recognise the Factom Protocol as a mean ensuring everybody’s rights.

For the RAID question NK04:

For the node 1 it will RAID 1 system. Indeed we will have two physical disks. As per RAID 1 configuration, those two physical disks will be a mirror of each one. With this in case of a disk failure or breakdown the data will still be available and the run will be able to keep running. Hence we will use two SSD disk of 250Gb.

For the emails question NK02:

As explained in the application document, the blockchain tech is a very hot topic in France, and some politicians are starting to openly debate about it. These three parties (two deputies, and one membre of the government) were contacted via emails on general strategic questions about the blockchain tech, and the French environment. Other people from the public service were contacted via email to establish cordial relations.

Being able to further our dialog with such parties through phone calls or face to face meetings would be much more easier with the Factom Protocol aura. One of HashnStore’s goals is to lobby straight to the law makers, whose ears are always made more available when a discussion is backed by an existing solution.

For the bandwidth question NK03:

The bandwidth is provided by the French biggest and best internet provider: Orange. To get the best experience we obviously subscribed for the Pro offer, which includes 1Gbps, 24h/7 technical assistance and a fixe IP.

For the full time job and the salary question NK09:

The document details that several thresholds of salary will exist, depending on the factoids price, and it starts at a low 1000€. It has been deciding as such for two main reasons:
1. HashnStore believe that before the employees are better paid, the structure needs first to find a financial equilibrium, or simply to fill its war chest a bit. The reason we apply to run an Authority Node is because we believe in the project. Hence, better pay will simply follow with the factoids rising price.
2. The first threshold was also set this low to show that HashnStore members are not solely interested by the monthly factoids manna.

The first full-time employee also has a peculiar position as having taken the crypto wave quite early, he is financially set. This aspect strengthens the two points mentioned above. Financial stability first, and a pledge not to be solely interested by the factoids manna.

For the Vision of the future question NK10:

HashnStore puts itself in the long-term footing. Our strategy will be deployed slowly but firmly. We understand that the ecosystem around the Factom Protocol will be vibrant, as described by the application document picture made by Elie Bonin - see his article.

The interesting part about our strategy is that HashnStore aims to train the next generation of programmers on the Factom Protocol. Our primary targets are French engineering schools, with which we already have deep connections. Thanks to this, HashnStore will be positioned to onboard young talents with promising projects. This early access to this rare skill and level of comprehension of the protocol should provide to HashnStore a competitive advantage.

In other words, we will know the students; we will have trained them; we will have talked to the interested parties willing to implement the Factom solution; we will have talked to the French law makers; HashnStore will be at the center of the French Factom ecosystem. And as France is increasingly supporting startups from the blockchain industry and trying to push for the application of French standards, we would have the political and financial support to also expand ourselves abroad.

All these elements strengthen our view that HashnStore would have all the necessary means to be a central player in Europe regarding the Factom Protocol.

For the Foundation question NK11:

We thoroughly thought about this with the HashnStore team. We came to the conclusion that having a foundation offers several benefits:

1. to have a Factom Foundation-like structure to spread information about the Factom Protocol
2. the HashnStore core members will start has the core members of the Foundation. But as the time passes we expect to be replaced by new people. This dual system will provide us with a non-profit organisation to promote the Factom Protocol regardless any commercial interests.
3. a foundation is a perfect tool to onboard new persons without having to pay them a salary. It is easier to create an adhesion effect though this structure.
4. if the for-profit structure dies, we will be left with the foundation as a mean to promote the Protocol. Our efforts are not lost this way, and would be ensured through donations.
5. less administrative expenses have to be paid to maintain a foundation alive too.

For the Load balance question NK06:

As per any server optimization we will try to handle the inbound connection to serve the best experience for people trying to connect to our node. It means that in the first phase we will have only one server handling the connections. This should work smoothly as the be at its beginning.

However, as the network will grow up and our node receives lots of connections we will try to find a solution to keep handling those connections smoothly. One solution that we have been thinking about is to install a load balancer. For now it is impossible to have the same Authority node on two different servers however as a proposition to a massive growth in the network we will ask the foundation for the possibility to have two Authority node with the same identity on two differents servers.

Our idea behind this request is to install a load balancer through HAproxy. This means setting up a Load balancer in front of those two Authority nodes to dispatch all the requests made to the node on a dynamic round robin way. The load balancer will affect dynamically weight to each of the two nodes and then forward the user connection to the node having less connections.
We think that this could really help handle huge growth in the network and the usage of the Factom blockchain.

For the Application Uptime question NK05:

To measure application uptime we will use at least this few metrics:
- uptime of the server using a ping script and prometheus
- uptime of the docker deamon using prometheus
- uptime of the docker composition and each composant using prometheus
- uptime of factomd using prometheus and using a comparison between heights from our node and heights from explorer.factom.org

For the 15-month timeframe and sale aspect MattO 01:

We ended up with a 15 months timeframe quite simply. Everything is about the correct timing. These 15 months are divided in three parts. After a month of solely ensuring that servers are running smoothly, developing the HashnStore website, creating the HashnStore for profit and non-profit structures, we end up with:
- the first three months that spans from June to August - summer holydays, people have an available ear, be it to schedule courses on Factom, or to talk to public or private representative.
- the next nine months that spans from September to May - it's the class period for engineering students. It provides much time to train them. But it is also the time were politicians are actif and eager to jump on new ideas.
- the next three months that spans from June to August - it is the internship period for students. Time for the best PoC to be implemented with interested parties. But also to adjust the class lessons to best fit the firms expectations.

Rinse and repeat. It is a simplified view, but the idea is here. HashnStore will be a factory of young talents, knowing the Factom Protocol like no one.

From a sales perspective, Matthias Fortin is treasurer of a state-approved organisation. Aside from signing the organisation accounts, he is also mandated to raise funds. Matthias often talks to both private companies (Orange, Bouygues, etc) and public representatives (State, regions, cities). He successfully raised 160k€ this way in 2017. In addition to raising funds, Matthias also brought these private companies to provide skills through worked hours. The time passed by professional working for his organization accounts for 500k€. Being state-approved, the board, of which Matthias is part of, is sometimes invited with other similar organisations at the National Education Ministry to discuss head on with the Minister. To conclude with Matthias experience, he often has to push recommandations to the executive committee of EDF - the biggest French and 80% state-owned electricity producer and distributor.

HashnStore lacks a "real" business man, but Matthias's profile is not far from this and he has the adequate ton to discuss with various parties, as explained above, which is more than enough for our first 15-month plan. Also, as explained in the application document, HashnStore would easily be eligible for startup incubation in multiple incubators, if we feel the necessity. These structures would provide an extra set of skills in the business and strategy branches. In addition, there is no real business man in who really comprehend the blockchain technology and its benefit. Most blockchain evangelists and sales are tech people. HashnStore is made of tech people too, who are the best positioned to speak the companies CIO. Hence, there is no need to invest more time or money from the start in the business development aspect.

As for the network to be leveraged, as of now, no one from the team had to use its own. Apart maybe from one example. CryptUp, of which Elie's part of, gave a conference on the blockchain technology, in front of 100 students and professors. The room was gladly provided for free by the INSEEC group, of which ECE Paris - Elie and Frédéric's school - is part of. The INSEEC Group has campuses across the globe, with a focus in Europe. Matthias's Alumni network is also the biggest in Europe and is famous for its deep and various ramifications in every aspect of the economy at the executive level (R&D, industry, IT, Finance, Consulting, etc.). Add to this our personal and professional networks. HashnStore feels very confident in its capacity to leverage its network to further the Factom Protocol.

For the update timing question NK07:

We think the solution provided here is the most simple and secure way to proceed with the update of each node. Updating all the nodes at once seems too risky to us, hence the choice to update one at a time via a proxy node punctually set up on AWS, as described in our application document.

We will proceed to more testing in the days to come to encompass all the possible scenarios, to conclude by an overall checkup with both the guides and the Factom Foundation to determine whether an aspect of the update timing is missing on our end.

For the failing scenario question NK08:

If we decompose the overall idea, we can isolate several operations:
- ping the servers - detects which server is down
- ensuring that the defective node won't reboot to avoid having two nodes with the same identity running, because of the next step
- action of transfering the Identity from the defective node to the backup node through SSH
- reboot of the defective server as a follower node, fully sync
- wait for given amount of time to ensure that the new follower node acts normally
- action of transferring the Identity from the backup node back in to the ex-defective node through SSH

An extra step is to check the server's log and reports from Prometheus to allow positive feedbacks.

Every action listed here represents a point of failure. Having said that, all our servers will be hosted by different services.
One unlikely scenario would be for the back up server to be down at the same time as the first defective server. Also, if an update occurs in the meantime, the new follower node can be updated before the brain-transfer is processed. The most critical step is during the Brain-Swap. Best practices have to be used to ensure the highest level of security.
Last edited: