//STORE enables these computing, economic, and governance primitives

Zero-fee settlement-layer enables

Zero-fee, peer-to-peer value transfer

Fast transactions

Scalable transactions

Democratic and 2/3 censorship resistant governance (one entity, one vote)

Tokenized Data enables

Data to be open and tradable

Data to be programmable by third party apps and devices

Data to have a monetary premium (like $STORE, $BTC, $ETH, $EOS, and gold)

Datacoin revenue to be shared with users, citizens, more

…which enables these high-level use cases

Zero-fee settlement-layer enabled

Tokenized data enabled (p2p cloud)

High-level Use Cases

Fast, zero-fee, programmable payments for the public internet

Voting on the global rules of a decentralized, zero-fee digital asset

Zero-fee, 2/3 censorship resistant value transfer of data as a digital asset

Voting on the global rules of decentralized, open, and programmable data

A web2 app developer opening APIs for other developers to build with (for $STORE)

An IoT device developer live streaming datasets for anyone to access (for $STORE)

A health care system making a prized and rare dataset available (for $STORE)

An autonomous car or drone opening its ML-ready, live data streams (for $STORE)

A local government streaming IoT device data for anyone to access (for $STORE)

(If we publish, we’ll award you with 100,000 $STORE – enough to compete in founding mining auctions.)

While STORE transactions are zero-fee for both end users and developers, if STORE is initially deployed as n ERC20 token on Ethereum, applicable gas fees apply on Ethereum. All settlement transactions on Ethereum incur gas fees. When the ERC20 STORE tokens are swapped with native STORE token tokens, transactions will be settled on the STORE network and at that time, zero-fee transactions are resumed.

April 17, 2018 . 5 min read

STORE Software Development Protocol Inspired by Impenetrable Fort Knox

Project Fort Knox: STORE takes major steps to secure its code base with the help of the Amazon Blockchain Strategy Group

Amazon Blockchain Strategy Group boosts efforts to secure code


  • STORE subscribes to the philosophy of secure by design.
  • Protection of the entire system is built into the infrastructure, processes, development and testing, as well as the consensus protocol.
  • STORE has identified three primary areas that must be secured:
    1. Public blockchain
    2. Wallet and governance infrastructure
    3. Development process and environment

The U.S. stores its gold bullion reserve at Fort Knox, an Army base in Kentucky. (Source: Fort Knox Archive)


Public blockchains using a decentralized workforce to build open-source software have to address a wide range of security concerns. STORE is creating software and a cutting-edge organization around security.

This document is Part 1 of STORE’s discussion of its approach to securing the blockchain and its supporting infrastructure. It is codenamed Fort Knox after the famous fortified vault in Kentucky.

Like some of the largest cryptocurrency organizations in the world, STORE works with the Amazon Blockchain Strategy Group to secure its code base and CI/CD environment (and more).

Secure by Design

For a cryptocurrency network, security cannot be an afterthought where you add something later. The protocol, infrastructure, processes, development, and testing must be built around security. Security built into the consensus protocol is commonly understood. End-to-end security built into an open development environment, not so much. Secure by design involves the following traits.

  • Security levels and end-to-end auditability — The system should have multiple, well-defined security levels so the components and processes in the system can be assigned appropriate security levels. There should not any component or process with an undefined security level. Every access to the component or process and every operation performed must be auditable and the audits must be maintained through the life of the system.
  • Role-based access control — The security levels and audits must be accompanied by a role-based access control to the components and processes in the system. There shouldn’t be an access without an explicit role associated with it.
  • Continuous monitoring, alerting and notifications — The access control patterns must generate appropriate alerts continuously. Alerts should also have well-defined actions, so they can be executed when they are generated. The actions can be as simple as notifications — call, text, email responsible people — or as dramatic as freezing or killing the system.
  • Continuous test — The system should have built-in attacks for all possible attacks that it can defend, so it can defend them continuously. This is the only way we can be confident that the system can resist real attacks. So all documented vulnerabilities are built into the system and they are exploited continuously to test the system’s defense.

Secure System Design

Wallet, governance and other services: The STORE wallet, governance infrastructure, and other related services are hosted on STORE. Services are hosted on Amazon Web Service with a multi-datacenter, multi-VPC design, shown in Figure 1, below.

Figure 1 — A sample deployment diagram hosting STORE services

The following measures are taken to secure these services.

  • Virtual Private Clouds (VPC) — Services are deployed in their own VPC, segregated from other services. Shared access is not permitted. This design allows for VPC specific role definition, access control, and prevents unnecessary access from one service to another.
  • Role-based access control — All access to hosted services such as production updates, bug fixes, access to logs and underlying data stores, etc. are controlled by specific roles. These roles are confined to the underlying VPC. As a result, roles granted to one service cannot be used with another service.
    If a person must access multiple services, they will need explicit roles granted for those services.
  • No public access for hosted services — Hosted services and their infrastructure pieces are inaccessible from the public Internet. Access is by well-defined APIs that have secure access terminated at the load balancer. As a result, direct attacks are possible on these services.
  • No direct developer access to hosted services — The developers cannot SSH (secure-shell access) directly into any of the services from their development machines. They will need to gain access from a bastion host that includes enabled role-based access. Such a setup prevents access to the secure services from a compromised development machine.
  • Dynamic shared secrets — Password protected and single master secret key access is not utilized because of ease of compromise. Rather, access is channeled through a secure key management infrastructure implementing Shamir’s secret sharing (https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). This scheme splits the master key into N parts and M of N (for example, 3 of 5) parts are required to gain access to the system. Depending on the role, this can be “1 of 2”, “2 of 3”, “3 of 5”, or similar access control. For the system to work, the required number of people holding the necessary key parts must come together to open the vault preventing a single person from inadvertently performing catastrophic operations.
  • Continuous auditing and monitoring — As discussed previously, access is monitored so appropriate alerting can be used when needed.


Secure by design principle models the security in the design rather than in implementation or as an afterthought. Trust is distributed so a single person or entity cannot be the weakest link in the system. Security is a multi-tiered system and all components and processes are explicitly assigned appropriate security levels. As a result, all access is monitored and audited.

The blockchain networks are vulnerable to various types of attacks. STORE models its network with built-in attacks so the system can defend itself continuously, preventing ‘surprises’ when real attacks are mounted.

Coming in Part 2

Details on Secure System Design for the public blockchain as well as the development process and environment.

More Reading

To learn more about some of the largest security failures, hacks and breaches in history, affecting companies like Yahoo, eBay and Equifax:


See more about hacks of blockchain-related technology companies such as the Mt. Gox exchange, https://en.wikipedia.org/wiki/Mt._Gox and Italian coin exchange BitGrail, https://techcrunch.com/2018/02/12/bitgrail-hack-nano/

Thanks for your email address! You'll start receiving updates soon.


KYC/AML checks are required for securities law compliance. This will be a Reg D and Reg S global offering.


Nothing herein is intended to be an offer to sell or solicitation of offer to buy, STORE tokens or rights to receive STORE tokens in the future. In the event that STORE conducts an offering of STORE tokens (or rights to receive STORE tokens in the future), STORE will do so in compliance with all applicable laws which may include the Securities Act of 1933 and the rules and regulations promulgated thereunder, as well as applicable state and foreign law. Any offering for sale to US Persons in a regulated transaction will be pursuant to a registration statement qualified by the Securities and Exchange Commission, or an applicable exemption from the registration requirements.