AMBERnomics as it has been introduced, refers to both the macro and micro token-economic infrastructures that have been built into AMB-NET as an integral component of the Ambrosus ecosystem. As a new area of economics that combines mechanism design (a subset of game theory dynamics) with information technology, and decentralised systems engineering, the Ambrosus crypto-economic model has required significant amounts of time and consideration in modelling and revising its various parameters.

Below is a first-time reveal of some of the internal dynamics of the Ambrosus crypto-economy: this begins (1) with a brief summary of the various nodes on the network, followed by (2) an explanation of the Atlas Arena and some of the fundamental considerations currently being modelled therein. Third, (3) the structure and timeline of the compensation mechanism is discussed and outlined. Finally (4) provisional models focused on Apollo masternodes and the compensation structure for both transaction and block rewards are discussed.

Section 1: Upload, Validation, and Sheltering Responsibilities

While more in-depth blog posts have been released in the past discussing the various roles for masternode operators on the Ambrosus network, the basic functionality remains the same:

Apollo Masternodes require a minimal stake of 250,000 Amber (AMB) in order to submit a bid for a spot on the network. As the validator of all smart contracts and transactions executed on the Ambrosus blockchain, Apollo nodes uphold the integrity and truthfulness of all data written onto the blockchain.

Atlas Masternodes, divided into multiple tiers (Omega, Sigma, and Zeta), require respective stakes of 75,000, 30,000, and 10,000 Amber (AMB) in order to gain access to the Atlas Arena: a domain where node operators are able to actively shelter and challenge one another for bundles of data sourced from a Hermes Masternode. The corresponding stakes refer to the frequency with which bundles can be sheltered over a certain period of time: higher stakes, allow for operators to shelter bundles more frequently over a shorter period of time.

Hermes Masternodes, requiring a stake of 150,000 Amber (AMB), are responsible for uploading data onto the network at a cost of 12 USD paid in Amber (AMB).

Together, the Masternodes fulfill three network essential functions: Uploader (Hermes), Validator of Blocks and Smart Contracts (Apollo), and Decentralised Sheltering and Security of all bundles created on the network (Atlas). This ‘macro-economic’ dimension of the Ambrosus crypto-economic model ensures that data across industries and from any stakeholder can be effectively verified, secured, and stored in a decentralised and transparent manner.

Section 2: The Atlas Arena

The Atlas Arena comprises the micro-economic dimension of the Ambrosus crypto-economic model. It is here, where bundles of data are copied from Hermes masternodes by various Atlas masternodes and subsequently sheltered for their bundle lifetime. Two types of challenges are built into the infrastructure of the Atlas Arena: System Challenges, and Atlas Challenges.

A system challenge refers to the process from which a bundle of data is uploaded onto the network and distributed to the Atlas nodes interested in sheltering that bundle. System challenges are therefore strictly limited between a Hermes masternode operator, and multiple Atlas masternode operators. The Hermes operator, after determining the lifetime of the bundle, must pay $12 USD in Amber (AMB) per year of storage. The Hermes operator must then also must decide how many copies of data they wish to create for the bundle being sheltered in distributed storage.

Meanwhile, an Atlas challenge refers to the means by which Atlas masternodes interact with one another so as to ensure that data is stored responsibly and with accountability. Due to the fact that Atlas challenges ensure the proper storage of sensitive enterprise information, Atlas challenges are accompanied by an inbuilt penalty structure. Currently, the exact technicalities for Atlas challenges are being rigorously tested and modified to ensure an optimal environment for both Atlas operators, and enterprises in need of secure data storage.

The penalty structure, also in the process of being tested, is based upon verifying that the Atlas nodes responsible for sheltering data are sufficiently incentivised to correctly perform their sheltering duties in the event of an audit. While the exact system design for penalties is being simulated across multiple scenarios involving different network participants (Atlas, Apollo, and even Hermes Node Operators) the foundational mathematical parameters have been adequately identified:

Let P equal the Penalty for failing to pass an audit.

Let p equal the probability of passing an audit with missing data.

Let R equal the reward for passing the audit.

The following equation expresses the expected reward for an Atlas Node operator, when a bundle of data is not adequately sheltered:

This mathematical foundation ultimately ensures that regardless of the specificities and actors involved, the expected reward for not sheltering data is a negative amount. The equation above, outlines the conditions to make this the case: the expected payout for some missing data is given by multiplying the probability of passing the audit (p) with the reward for passing the audit (R). This amount is then subtracted by the probability of not passing the audit multiplied with the penalty that would be incurred. The penalty therefore must be large enough to ensure that the above term is negative.

With both System and Atlas challenges available within the Atlas Arena, an entirely new threshold of interactivity is created for Atlas masternodes. More specifically, entire sets of strategies can be created and custom-designed around how an Atlas operator wishes to go about sheltering bundles based upon the various network procedures:

When System Challenges are initiated on the network with a bundle of data being uploaded, what kind of bundles will an Atlas operator opt to shelter? Based on the differing durations for each bundle of data, different strategies can be customized for each operator in relation to their long-term goals and the amount of time they wish to shelter a bundle for.

When a transfer procedure is initiated on the network (i.e. because an Atlas operator wishes to make room for other bundles or because the operator cannot maintain its server), will an Atlas operator strategically seek out transfer requests, whereby less sheltering time is required of a particular bundle? How will an Atlas operator determine the frequency with which they pursue transfer requests as opposed to system challenges?

The core idea behind the Atlas Arena, is that it is provides operators with the ability to creatively decide how they wish to pursue sheltering responsibilities on the network in order to maximize their participation while minimizing the amount of penalties incurred.

Section 3: Compensation Modelling

Compensation for the sheltering of bundles by Atlas masternode operators is designed to be dispersed in 28 day segments over the course of the year (as each bundle of data is required to be sheltered for a minimum of one year). Beyond the 28 day increment, the proportion of rewards released during the one year increment is also split as a further measure for incentivising sustainable and enduring network participation.

For every bundle of data stored for one year, the Atlas operator is compensated 78% of that bundle, as paid out in regular intervals of 28 days over 12 months. The remaining 22% (known as the bonus unlock) is compensated in the final 28 day period as a completion bonus for the successful sheltering of the entire bundle storage period.

Slightly more complicated is the modelling for payouts granted a fluctuating price per bundle paid in Amber over the course of time. To manage this uncertainty, the bundle price is fixed once a month in order to provide stability for enterprises uploading data. Using a fluctuating exchange rate of Amber the following notations have been designed:

Since the shortest month is 28 days, during one payout period there can be at most two different bundle prices. We introduce some notations to help us keep track of the exchange rate during one storage period:

Section 4: Apollo Masternode Compensation — Transaction and Block Rewards

Apollo Masternodes validate all transactions written onto the blockchain. In order to operate an Apollo node on AMB-NET a public bid must be made, demonstrating the amount of Amber that one is willing to stake in return for receiving a place on the network. This ‘auction procedure’ as it has been labelled, is a primary determinant in the calculation of block rewards per each Apollo node on the network. At the same time, the Apollo masternodes are allocated 30% of the cost for each bundle of data uploaded onto the network by a Hermes masternode. Both compensation mechanisms are explained in detail below:

Based upon the provisionally set 30% distribution of upload fees, the following proofs have been proposed as a method of calculating the transaction rewards relegated to each Apollo node from each bundle of data that is uploaded:

With these variables the following three criteria can be determined:

Based upon this, the total rewards for Verification (Apollo nodes) of all bundles uploaded on day d is given by the following equation:

The Expected Compensation per Apollo Node: Assuming every Apollo node has the same probability of issuing the next block on the blockchain, the following equation provides the expected reward per Apollo node:

The Expected Compensation per Apollo Node during payout period i:

Block Rewards:

Next, in relation to block rewards, provisional calculations (which remain subject to change) have also been created for the base reward and for individual block rewards. For both, a number of variables must be taken as given:

D = The sum of deposits for all Apollo nodes on the network. This variable refers to the total amount of Amber that all Apollo nodes have locked into a smart contract in order to validate transactions. N = The number of Apollo nodes actively validating transactions on the network at a certain time. d = The deposit of an individual Apollo node being compensated for their network function. This refers to the stake or ‘auction bid’ that a single Apollo node made in order to gain entry onto the network. S = The total supply of Amber (AMB) currently in circulation. T = The target block time calculated in seconds. G = The yearly token generation rate of Amber as a percentage

With these variables, the base reward B, indicative of the total amount of compensation in Amber that is distributed in the form of block rewards, can be ascertained through the following equation:

The block reward, R, indicative of how much Amber is compensated per block validated by a particular Apollo Node with deposit ‘d’ is provided in the following equation:

Importantly, due to the fact that these models are constantly undergoing simulations testing, whereby different parameters are modified and examined, they cannot be taken as definitive at this time. Rather, they serve the function of illustrating what kind of factors are considered while a model is constructed and simulated.

Conclusion:

Beyond what has been disclosed, further modelling for the node cool-down period, Atlas compensation mechanisms, and the specifics of the penalty structure remain in the simulation phase. Similar to the how the Ambrosus developer teams prioritise quality above all else, the Ambrosus Crypto-economic team is equally concerned with ensuring that only the most optimal models are adopted for the network to incorporate into the AMBERnomics architecture. All the while, the underlying goal remains the same: to create a sustainable crypto-economy that strengthens over time as more network participants become involved.

Legal Disclaimer: This is intended to be a technical vision summary of a cryptoeconomic model and masternodes architecture to power AMB-NET platform. It provides as much detail as is possible at this stage of development of the platform. Rigorous testing of these models will be implemented in the forthcoming weeks and months and may result in some changes to the specifications, technical requirements and staking mechanisms. Amber (AMB) is a utility token within AMB-NET. AMB is not a financial instrument and should not be considered as such. Participation in AMB-NET provides a range of technical utilities to stakeholders and enterprises, and should not be considered as a speculative activity, financial transaction or an investment of any sort. The numbers are not guaranteed and are subject to change depending on the technical roll-out and adoption of AMB-NET network, which is a decentralised network governed by a smart contract system.

The users and AMB tokenholders acknowledge and agree that, to the fullest extent permitted by any applicable law, the User will not hold any developers, auditors, contractors, employees or founders of Ambrosus and its affiliated companies, the Smart Contract System and/or AMB-NET liable for any and all damages or injury whatsoever caused by or related to the use of, or the inability to use, AMB or the Smart Contract System under any cause or action whatsoever of any kind in any jurisdiction, including, without limitation, actions for breach of warranty, breach of contract or tort (including negligence) and that developers, auditors contractors or founders of the Smart Contract System, the AMB and/or Ambrosus and its affiliated companies shall not be liable for any indirect, incidental, special, exemplary or consequential damages, including for loss of profits, goodwill or data, in any way whatsoever arising out of the use of, or the inability to use of the Smart Contract System, the Ambrosus Platfrom, AMB-NET and/or AMB.

The Users and AMB tokenholders further specifically acknowledge that developers, auditors, contractors or founders of the AMB, Smart Contract System and/or the Ambrosus and its affiliated companies are not liable, and the Users and AMB tokenholders agrees not to seek to hold them liable, for the conduct of third parties, including other creators of AMB or Masternode Operators and Hosts, and that the risk of creating, holding and using AMB rests entirely with the Users and Tokenholders.

By acquiring, holding or using AMB tokens, and to the extent permitted by law, the Users and AMB Tokenholders agree not to hold any third party (including developers, auditors, contractors or founders) liable for any regulatory implications or liability associated with or arising from the creation, ownership or use of AMB or any other action or transaction related to the Ambrosus Platform, AMB-NET or any related products.

The Users and AMB Tokenholders bear the sole responsibility to determine if their participation in AMB-NET, staking AMB in Masternodes, receiving AMB rewards, have tax implications for them. The Users and AMB Tokenholders agree not to hold any third party (including developers, auditors, contractors, employers or founders of Ambrosus or any affiliated companies) liable for any tax liability associated with participation in AMB-NET, receiving rewards via any of the Masternodes, or any other action or transaction related to Ambrosus or AMB.

This technical vision and development of cryptoeconomics is undertaken by Ambrosus Estonia OÜ, a company with registration number 14390513 registered in Estonia, and governed by the laws of the Republic of Estonia.