Boot and Remote masternodes are now generally available.

Let’s break down what boot and remote masternodes are, what it means that they are generally available, what that means for full masternode holders, touch on “reputation”, and then focus on Balefire.

Akroma’s masternodes are designed to provide features to the Akroma network. Full, boot and remote masternodes are the 3 types of masternodes that are currently available. Balefire, Akroma’s oracle solution, is in development now.

The base masternode type, known as a “full” masternode is the standard Akroma client. These masternodes sync the entire Akroma blockchain, participate in transaction validation and help ensure the health of the geographically distributed network.

You can learn more about “full” masternodes here: https://docs.akroma.io/masternodes/masternode-types/full-masternode

“Boot” masternodes run the same software as “full” masternodes. The difference between these masternodes is that “boot” masternodes have their information included in the Akroma source code and are used by new clients when connecting to the network for the first time. All blockchain platforms use some form of “boot” nodes, for Ethereum they are nodes managed by the Ethereum foundation. For Akroma it is the 20+ “boot” masternodes managed by the Akroma community.

You can learn more about “boot” masternodes here: https://docs.akroma.io/masternodes/masternode-types/boot-masternode

“Remote” masternodes expose the Akroma network to the traditional internet by way of the Akroma REST API. “remote” masternodes give dApp builders APIs that can be used without requiring users to download, sync and run their own Akroma client. The current most prominent example of this is the akroma explorer: https://explorer.akroma.io, there is no single server, and the “remote” masternodes that power the explorer are managed by the community.

You can learn more about “remote” masternodes here: https://docs.akroma.io/masternodes/masternode-types/remote-masternode

Masternode rewards adjustments

The new masternodes have higher AKA lockup requirements, require Proof of Participation and consume more server resources. The Akroma team, with feedback from the beta testers, considered many different adjustments to the rewards system. In the end, we decided to adjust the rewards in the most minimal way possible, without changes to the coin supply, and rely on economic incentive to create a balanced network with masternodes of each type.

On November 1st, the Akroma masternode rewards will be adjusted so that 60% of the daily reward goes to “full” masternodes, 20% to “boot” masternodes and 20% to “remote” masternodes.

Proof of Participation

As we exit the masternode beta we are re-branding what we’ve previously called Proof of Reputation to Proof of Participation. As a user runs a “full” masternode on the Akroma network, we are able to look at the rewards transactions on the blockchain as an assertion that their masternode is participating. As such, the algorithm for Proof of Participation is a sum of the number of transaction in a rolling 120 days, with “boot” and “remote” being worth 3 points, “full” is 1 point.

A big thank you to the beta testers who provided valuable feedback, the Proof of Participation algorithm allows for users to consolidate masternodes without losing points, is stateful — in the event there is an issue with the Akroma monitoring system there is no collateral damage to your reputation.

Balefire

With the launch of the new masternode types and release of Proof of Participation, the infrastructure has been created to allow us to release a feature that requires a high degree of trust in a decentralized fashion. By leveraging Proof of Participation, along with staked AKA, we create a web of trust that allows dApp developers to request data from any API on the internet and have the safety to execute smart-contracts based on those results.

Most of the current development is focused on Kastle, we hope to have a beta of Balefire in January.