Stratis enters partnership deal with Silicon Valley software company Gluon

We are thrilled and excited to announce that the Silicon Valley based corporation, Gluon, will be joining the Stratis family as one of our flagship verified ICOs. We started this journey with the desire to use our flexible blockchain development platform to meet the needs of real world financial services and businesses, and in offering deployment and support services to Gluon before, during, and after their ICO, we are pleased to say we’re doing just that.
We have watched Gluon from afar, recognising that they were not simply another whitepaper idea, but a remarkable product with existing funding, impressive revenue and a global presence with offices across the US, UK, Sweden and India.
As a business we have always strived to work with like-minded clients who are pushing boundaries and forcing change, something Gluon is powerfully doing within the automotive manufacturing, distribution and retail industry. Gluon’s technology platform establishes a secure network of interconnected vehicles, allowing users to diagnose, track and monitor issues using IoT devices, AI and blockchain.
Combining existing vehicles as well as up and coming technologies such as hybrid, electric cars and self-driving, they are addressing a gap in the market and connecting both the old and current with the new.
Speaking about the latest partnership, Chris Trew, CEO and Founder of Stratis said that “security is paramount for both our businesses and we knew we would be well-aligned to work together, pushing both our organisations into the future-sphere.”
Having built Stratis from the ground up in C# and .NET Framework there’s a flexibility that comes with our solution, giving businesses like Gluon a comprehensive approach to their problems.

Development Update

Stratis Identity App
The Stratis Identity iOS application is currently awaiting approval to be published to the Apple App Store.
The application is complete, and it is now dependant on the review and approval process.
Release Date: Q1 2018
Stratis Sidechains
The Stratis Sidechain technology is based upon the Stratis Full Node. Extensive work has been undertaken to further develop our Stratis Sidechain offering and a number of core features are being implemented. This includes instant sidechain creation and methods to fund the sidechain from the mainchain.
The sidechain team are also working closely with the smart contracts team in order to enable enterprises to run smart contracts on their respective sidechains.

Another core feature of Stratis Blockchain-as-a-Service is the Stratis Blockchain Generation Technology. This has been made available as a separate offering to fulfil any immediate requirements to deploy blockchains for customers whilst the full Stratis Sidechain product is in development.

Alpha Release Date: Q1 2018
Stratis Smart Contracts
Stratis is working on providing a smart contracts solution that will cater for .NET developers by providing a comfortable and familiar development environment, as well as being performant and secure.
We are currently in the implementation phase and the overall architecture is in place. Work is progressing on the gas expenditure and persistent storage aspects of smart contracts.
The Stratis Blockchain Technology Platform is proving to be a first-class platform for C# sidechain and smart contract development and 2018 will be an exciting year for Stratis.
Alpha Release Date: Q1 2018

Stratis Blockchain Generation Technology

Stratis is announcing an exciting milestone in our mission to provide blockchain services to the enterprise. We have achieved the capability to provide custom blockchains based on Stratis Blockchain Technology. This technology is ready today and can begin to be deployed to eagerly awaiting enterprise customers.
Our Stratis Blockchain Generation Technology allows the Stratis Consulting team to create a new blockchain along with wallets, mining and full node infrastructure running on .NET Core using C#. This makes digital asset issuance, custodianship, and ownership transfer on the blockchain a reality for all businesses.
The technology allows the creation of a private blockchain (with its own genesis block) and therefore a new coin. Bespoke versions of the Stratis Full Node are then deployed across the network and a blockchain is born. The blocks can then be mined using either ‘Proof of Work’ or ‘Proof of Stake’ mining. Wallets can be branded with your coin/asset and include your custom coin address scheme.
New public blockchains are also supported.
Customizations will also be available to enterprises that have bespoke requirements such as bigger block sizes, different block intervals or new consensus rules. And because these customizations can be rapidly developed on .NET Core in C# this opens a huge range of possibilities for the enterprise.
Stratis Blockchain Generation Technology works with Microsoft Azure or is deployable on premises or on other cloud network infrastructures.

Stratis Full Node GUI Alpha Release

The Stratis Full Node GUI alpha release is now available on Testnet and is yet another key milestone in our development roadmap.
This release contains the Stratis Full Node GUI which includes the following features:

  • Inclusion of Staking capability
  • Download of the entire Stratis blockchain
  • Supports the Stratis network with Block Validation and Transaction Relay
  • Aids Peer Propagation

The release and supporting documents can be obtained below.
Windows 64-bit
Windows 32-bit
Mac OS X
User Guide

Breeze Wallet with Breeze Privacy Protocol Beta Release

This version of the Breeze Wallet includes the Breeze Privacy Protocol feature as well as an enhanced user interface. It also features the Masternode Client Discovery protocol where the blockchain is used to discover, validate and connect to a Masternode which provides the privacy service. This discovery process is undertaken in a decentralized and trustless manner that is resistant to disruption.
The release is a private Mainnet beta to select community members. This environment allows the select community members and our developers to work closely with one another to monitor wallets and privacy transactions allowing every privacy cycle to be verified. Due to the nature of the technology we are investing in an extended private beta phase prior to moving to an open beta on Mainnet.
Enhancements made to both the Breeze Wallet interface and the Masternode Client Discovery Protocol have also been incorporated into our public Testnet release.
Download the Breeze wallet with Breeze Privacy Protocol (Testnet) from the link below. The wallet will then automatically discover and connect to an available Testnet Masternode.
Packages are available for Windows, Mac and Linux.
Download for Windows 64-bit
Download for Windows 32-bit
Download for Mac OS X
Download for Ubuntu

Masternode Mainnet Beta Release

Today we are delighted to announce the availability of our Masternodes product in a beta version. The Masternodes alpha was successfully released in October, and as a result, we are now ready to move this technology onto the Stratis and Bitcoin Mainnet.
Masternodes provide a resilient, discoverable, and trustless service on the blockchain. This is implemented through a node service advertisement protocol and a client discovery protocol.
The source code is available in the below link and we have also provided a detailed ‘Masternode Set-Up and Configuration for Windows’ User Guide.
Breeze Wallet with Breeze Privacy Protocol Mainnet beta release will be available on Monday 11th December.
Please note our live alpha test Masternode server will no longer be available.
Source Code
Set-Up and Configuration Guide
For more information about how the Masternode registration protocols work please see this technical blog post:

Stratis Academy Update

We have now completed the development of the Stratis Academy Learning Management System( LMS). The Stratis Academy LMS will combine both lessons and a Community Management System to create an environment where developers can learn and collaborate with other developers learning blockchain development.
The next steps are to build the core technical content and walk-through materials. The course content will range from getting started with the Stratis blockchain to developing applications utilising the Stratis Development Framework.
Community features like profiles, discussion boards, and groups, will allow developers to learn faster together with one another.
We are actively working on the structure of courses and the core content. This is the key focus for Stratis Academy going into Q1 2018 and we are certain we will achieve the Stratis academy roadmap milestone ontime or earlier.

Stratis Test ICO

Today we are excited to announce the launch of the ‘Stratis Test ICO’ which utilizes the Stratis ICO platform.
The Stratis ICO Platform is a secure, customizable platform for you to host your own ICO’s on the Stratis Blockchain Network. It has been developed from the ground up in C# and .NET Framework and is easily deployed within Azure.
Security is paramount; therefore, the platform does not store any coins or private keys on the hosting infrastructure.
The Stratis Test ICO is a demonstration of the Stratis ICO Platform to showcase the technology and product we plan to deliver to market soon.
This instance of the Stratis ICO Platform will be available for two weeks and we welcome your support in testing the platform and provide any respective feedback.
Stratis Test ICO
The Stratis Test ICO Instance is now offline.
If you require some $TSTRAT to participate, it can be obtained from the Stratis Faucet.
Stratis Faucet
Stratis Test ICO User Guide

Breeze Wallet MainNet Beta Release

The Breeze Wallet MainNet beta release is now available and represents a key step in our product development roadmap.
The Breeze Wallet release includes and highlights the following:

  • Dual Network functionality: Bitcoin and Stratis
  • Full block SPV wallet
  • HD Wallet (Hierarchical deterministic)
  • Transaction fee privacy consciousness
  • Change address privacy protocol

This is the first Breeze Wallet beta release on MainNet and it will be followed up with the Breeze Wallet with Privacy Protocol (powered by TumbleBit) release on MainNet which is scheduled for this quarter.
The release date for Breeze Wallet with Privacy Protocol (powered by TumbleBit) is on 11th December which includes interaction with the Stratis Masternodes.
The Breeze Wallet showcases our technology with a strong emphasis on privacy and security on the blockchain. These releases will highlight our focus towards providing enterprise blockchain solutions.
Download the Breeze Wallet beta version on MainNet here:

Breeze Wallet Source Code on Github:

Stratis Masternode Registration Protocol

Stratis masternodes solve the problem of providing useful services to a blockchain network while keeping the list of services decentralised and tamper-proof. In the initial masternode implementation the service being provided is the Breeze Privacy Protocol, but it is anticipated that many more services can be added in future.
In order for this goal to be accomplished, each masternode must register (advertise) its existence via the Stratis blockchain. This is what is referred to as the Masternode Registration Protocol. A masternode registration simply consists of a specially formatted Stratis transaction. This transaction contains all the pertinent information needed by a client to connect to and validate the masternode.
A registration transaction, once submitted to the network, remains valid indefinitely until invalidated by one of the consensus rules governing such registrations. These are:

  • The masternode server’s funding address is not funded within the initial window period.
  • The collateral funds are insufficient at the conclusion of the window period (see section Collateral Verification for additional information regarding the collateral and the balance tracking).
  • The collateral funds get moved, wholly or in part, to another address, thereby decreasing the balance below the required threshold.
  • A subsequent registration is made at a greater block height than the original (e.g. to update the masternode’s public parameters).
  • (Currently not enforced) A registration expires every N blocks, requiring the operator to periodically refresh it.

It is the responsibility of the Breeze client software to scan the Stratis blockchain for the most current masternode registrations prior to initiating contact with any server. They do this by observing each incoming block, looking for transactions that match the bitstream format. When a registration is found, it is stored in the node’s local store.
The block height that the registration is received at determines the window period for the masternode funding transaction. The masternode operator has to move the required collateral into the funding address before this window elapses. If this is not done the registration will be regarded as expired and purged from the local storage of all nodes on the network.
Once a sufficient number of valid masternode registrations have been downloaded, the client can select one at random and try to connect to it to utilise its services (e.g. the Breeze Privacy Protocol). Optionally the masternode selection can be performed once the entire blockchain is downloaded, as this is more fair to masternodes that register later in the chain.
The process described above has already been implemented into the Stratis software offering.
Bitstream format for masternode registration transaction
The registration transaction consists of a single transaction broadcast on the Stratis network (either testnet for testing or mainnet for ‘live’ masternodes). This transaction can have any number of funding inputs, as normal.
It has precisely one nulldata (data storage) output marking the entire transaction as a masternode registration. There can be an optional change return output, which if present must be at the end of the entire output list. The remainder of the transaction outputs are of near-dust value. Each output encodes 64 bytes of data into a public key script. The contents and format of the encoded data is described below.
The presumption is that the transaction outputs are not reordered by the broadcasting masternode, as this would result in potential data corruption.

OP_RETURN transaction output
Field Size Description


Encoded public key transaction outputs
Field Size Description
1 1 byte Protocol version byte (if >200, it is a test registration to be ignored by mainnet wallets)
2 2 bytes Length of registration header
3 34 bytes Server ID of masternode (base58 representation of the collateral address, right padded with spaces if it is less than 34 characters long)
4 4 bytes IPv4 address of masternode, one byte per octet. Use 00000000 for an empty address. This field is not used for the Breeze Privacy Protocol; it is a placeholder for future functionality
5 16 bytes IPv6 address of masternode, one byte per octet. Use 00000000 00000000 00000000 00000000 for an empty address. This field is not used for the Breeze Privacy Protocol; it is a placeholder for future functionality
6 16 bytes Masternode server URI, currently this is an ASCII onion address hostname without any prefix or suffix. An empty address is signified by 00000000 00000000 00000000 00000000, but leaving this empty is not valid for the current Breeze Privacy Protocol implementation
7 2 bytes TCP port of masternode, may be ignored by client implementation
8 2 bytes RSA signature length in bytes
9 n bytes RSA signature proving ownership of the Breeze Privacy Protocol server’s private key
10 2 bytes ECDSA signature length in bytes
11 n bytes ECDSA signature made with the private key of the address used as the server ID. This same address is where the collateral will need to be located
12 40 bytes Hash of the Breeze Privacy Protocol server’s configuration file. This may be moved into the header in the next version of the protocol
The protocol format can be extended in future to accommodate new functionality. New fields should attempt as far as possible to retain backward compatibility with the existing fields

On connection with the Breeze Privacy Protocol server by a client, the public key of the server will be verified by the client to ensure that the server is authentic and in possession of the registered keys. The Privacy Protocol is then followed as normal.
Collateral Verification
For the Breeze Privacy Protocol to function well, the creation of numerous or insufficiently powerful masternode servers must be disincentivised. Therefore, consensus rules that govern the validity of a masternode need to be established and enforced by participating client nodes.
A Stratis masternode requires 250 000 Stratis coins (STRAT) to be regarded as compliant. These coins should be kept in a single address, and should not be moved once the funding transaction is performed.
On receipt of each new block, the non-masternodes will check each transaction for those that affect a currently tracked masternode server. If funds have been moved out of the address, the calculated balance is decreased. If funds come in, the calculated balance increases. Once the balance has been computed for a masternode, its registration is automatically deleted if it falls below the 250 000 STRAT threshold. It is therefore not recommended that significant transactional activity be performed with the collateral funds, to avoid inadvertently invalidating registrations.

The above diagram illustrates 4 basic scenarios for a masternode’s registration sequence.

  • Node 1 has made a sufficient funding transaction within the window period, and as such its collateral is regarded as compliant.
  • Node 2 was initially compliant after the window period, but later removed some funds from the address, and therefore no longer has sufficient collateral.
  • Node 3 made two transfers that when aggregated form sufficient collateral in the target address. This is a valid, but non-standard method of performing the funding.
  • Node 4 took too long for the funding transaction to be performed (it was outside the window period), and is therefore regarded as non-compliant in terms of its collateral obligation.

The collateral verification functionality has also already been implemented into the Stratis software offering.
Future improvements
Inter-node discovery protocol
A drawback of the approach outlined in this paper is that every node has to download the entire blockchain from the genesis block onwards in order to accurately determine collateral balances. It is more efficient for registrations to be accumulated by full nodes, and circulated to their peers (full or light nodes) with sufficient proof of their accuracy.
The inter-node discovery protocol has already been implemented in the Stratis node software, but is not currently used in order to keep the initial version as simple as possible. It also has an indirect requirement for the peer policing described in the Peer policing model section.
Improvement proposal – peer policing model
There are some differences between existing masternode implementations and the envisioned Stratis masternode approach. Briefly:

  • Dash masternodes are remunerated ‘passively’. This requires that they be actively pinged in a verifiable way by the remainder of the network to avoid paying a masternode that performs no work.
  • Conversely, a Stratis masternode can currently only earn remuneration via active participation in the Breeze Privacy Protocol with connected clients. This removes the need to directly police the masternode in this sense.
  • Due to the high cost of a top tier Stratis masternode, it is presumed that the operator will be economically incentivised to positively participate in the network. This is similar to the core tenets of the Proof Of Stake consensus mechanism.

There are also some aspects of the Dash approach that are desirable to emulate, particularly the ability to have the collateral in ‘cold’ storage.
The requirements for the Stratis top tier masternode may be summarised as follows:

  • The node operator must be in possession of at least 250 000 Stratis (i.e. they possess the private key to move or spend them).
  • These collateral Stratis must be present in a single address.
  • Moving the Stratis collateral to a different address invalidates any proof of possession generated prior to the move.

These requirements need to be actively enforced to prevent dilution of the Privacy Protocol security model. It is proposed that the entities most suited to perform the enforcement are the masternode’s peers on the Stratis network. These peers may be one of the following:

  • Another masternode (essentially a full node with additional features).
  • A ‘full’ node with a complete copy of the Stratis blockchain.
  • A ‘light’ node that does not retain a copy of the entire chain, but does at least retain block headers.
  • Other types of nodes are outside of the scope of this document.

The onus is on a particular masternode to advertise its services to the network. This means that every node can elect whether or not to regard a masternode registration as valid, depending on the information it has available to it. From a game-theoretic perspective, it is advantageous for the operators of ‘rival’ masternodes to immediately present proofs of non-compliance of a particular masternode to the rest of the network. It is additionally presumed that there is no advantage to be gained for an honest node to propagate registrations known to be invalid.
An example of the ‘lifetime’ of a registration & implementation of the ‘proof of non-compliance’ concept is as follows:

  1. Operator configures masternode, which generates masternode registration Y on startup.
  2. Node operator moves sufficient collateral into address X (the ‘funding transaction’). This needs to be done within a finite window period after the registration transaction is made.
  3. Registration Y is broadcast as a transaction to peer nodes for inclusion into the Stratis blockchain in block Z.
  4. The registration is cached on each peer node. Nodes that join the network after block Z need not download the entire chain to receive registration Y – they can receive lists of verified historical registrations by communicating with their peers (inter-node discovery protocol). Light nodes can validate registrations for themselves by evaluating the Merkle proof of the registration against their locally downloaded block header storage.
  5. All full nodes on the network can directly evaluate the balance available in address X at any time. Therefore, if it transpires that a spurious masternode registration has been broadcast (which may happen) the full nodes will not forward that registration on to new peers. Peers that attempt to send known-invalid registrations will receive a proof of non-compliance in response.
  6. The status quo persists for a period of time without any changes that affect masternode registration validity.
  7. The masternode operator moves a portion of the funds from address X elsewhere, i.e. they are now below the collateral requirement.
  8. All nodes that download blocks will immediately be able to tell that the balance of X has changed, although a light node may not know what the actual balance is. Full nodes do know (or can calculate) what the balance is, and can construct a proof thereof showing that the masternode is no longer compliant.
  9. The non-compliance proof will be broadcast between nodes. This could be done pre-emptively (i.e. broadcast proof to all known peers immediately), or it could be done passively in response to receiving an invalid registration from a peer.

At a high level, the proof of insufficient funds will consist of the following elements:

  • A copy of the ‘funding transaction’ for the masternode. This is defined in more detail in the Funding Transaction
  • The registration record itself (in its entirety, as the peer may not have downloaded it yet).
  • At least one complete transaction with the funding transaction included as one or more of its inputs i.e. showing that collateral funds have been moved/spent.
  • The net result of the movement transactions must be that the balance of the collateral address is < 250 000 STRAT.
  • Merkle proof(s) for the movement transaction(s) showing that they are included in a block at the same or higher height than the funding transaction.

A light node should be able to interrogate a peer node about the perceived status of one or more masternodes. If the peer being interrogated is also a light node, it will only be able to pass along proofs it already received and stored from the full nodes.
Funding transaction
The funding transaction for a masternode is the transaction that assigns the 250 000 Stratis collateral to a given address. It is recommended that only a single transaction output be used for this, to keep the size of the proofs communicated between peers to a minimum.
There is also naturally a possible gap between the block height of the funding transaction and the block height of the registration transaction, during which some fund movement may have occurred. This should not be a problem, as full nodes will evaluate the solvency of the masternode and determine whether to propagate its registration to other peers via the inter-node protocol.
Some possible attack/DoS vectors
The most vulnerable portion of the network are the light nodes. The proof mechanism therefore needs to be robust enough to allow the light nodes to participate in policing the masternode registrations without having the entire blockchain available.
The masternode operators also need to be protected from rogue full nodes attempting to stifle traffic to particular masternodes by censoring their registrations. This is mitigated by the decentralised nature of the Stratis blockchain. It is only required that a sufficient number of honest nodes participate to minimise or negate the impact of rogue nodes, as the registrations will percolate through the network via the blocks & inter-node protocol. A rogue full node cannot generate a fake proof of non-compliance, as the Merkle proofs will fail to be validated.
Masternode operators may generate copious registration transactions (i.e. spam) in an attempt to sway client nodes to use their server. This is mitigated by a rule that a client node will only keep the most recent valid registration for each known masternode, so spamming the network does not result in an increased likelihood that a client will select a particular masternode server.
It is important that a masternode operator avoid moving their collateral funds in such a way that they inadvertently provide an avenue for full nodes to construct a non-compliance proof. If funds need to be moved it is recommended that an entirely new address be used & a new registration performed. This will naturally cause the previous registration to be invalidated and removed from the caches of nodes on the network. The new registration will, conversely, be cached and used going forwards.

1 2 11 12 13 14
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Consent to display content from - Youtube
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound