Table of Contents

1 Introduction

1.1 What is Cryptoeconomics?

1.2 What is AMB-NET?

1.3 Supply-Chain Challenges

1.4 Intelligent Design

2 Key Concepts

2.1 AMB-NET Data Overview

2.2 AMB-NET Data Types

2.3 Receipt

2.4 Expiration

2.5 Data Sheltering

2.6 Storage Fee

2.7 Nectar

2.8 Stake

2.9 Penalties

2.9a Storage Challenge

2.9b Data Resilience

2.9c Challenge Fee

2.9d Data Storage Transfer

3 Masternodes and Peers

3.1 Overview

3.2 Apollo

3.3 Hermes

3.4 Atlas

3.5 Perseus

4 Mechanisms

4.1 Primary Data Upload

4.2 Storage Challenge

4.3 Stake Withdrawal

4.4 Storage Transfer

5 Risk Management

5.1 KYC

5.2 Cyber-Risk Mitigation

5.3 Sustainable Governance

6 Constants

6.1 Fees

6.2 Storage Fee Split

6.3 Stakes

6.4 Penalties

7 Conclusion

1. Introduction

1.1 What is Cryptoeconomics?

Cryptoeconomics is a widely misunderstood term and a frequent source of confusion for many in decentralised ecosystems. AMBERnomics, Ambrosus’ official cryptoeconomic model, aims to dispel some of the myths about this emerging field and explain the incentive mechanisms and governance controls that will promote operability, scalability and sustainability throughout our network.

While traditional economics explores human behaviour in relation to the scarcity of goods and services, cryptoeconomics cross-pollinates private-public-key cryptography, free-market incentives, organisational governance and Game Theory concepts. This interdisciplinary field is kindred to mechanism design — a subset of Game Theory, where quantitative techniques are used to devise economic incentives that promote secure and sustainable growth for new systems.

When repurposed for cryptoeconomics, mechanism-design schemas entail the use of free-market principles to resolve information security problems and mitigate operational risks for public blockchain networks, both preemptively and reactively. The key is to engineer a model that rewards “healthy” network behavior, while punishing misconduct to a cost-prohibitive degree for would-be bad actors.

With this in mind, Ambrosus’ cryptoeconomic model will detail the multi-tiered Masternode architecture, data management processes, incentive models, fee structures and risk-management controls that will enable the continuous operability and scalability of the AMB-NET blockchain.

It is the belief of Ambrosus that the staking incentives and governance deterrents discussed in this cryptoeconomic release will propel the rise of a more visible, traceable and sustainable supply-chain ecosystem.

1.2 What is AMB-NET?

The Ambrosus Network (AMB-NET) is a decentralised data-storage system that automates smart contract execution, economic incentives, governance, regulatory compliance and cyber-risk management to help enterprises improve their supply chain processes. At this stage, Ambrosus is targeting life-essential industries like food and pharmaceuticals as its core markets.

Beyond supply chain optimisation, Ambrosus offers enterprises new ways to turn raw product quality, assembly-line and logistical data from IoT sensors into actionable and monetisable business intelligence. To do this, AMB-NET uses IoT sensor technology to collect client supply chain data, which is then authenticated by Proof-of-Authority (PoA) consensus protocols that confer authentication capabilities to the most trusted and high-integrity Masternodes.

These Masternodes then interact cooperatively to enforce the immutability of all Asset and Event metadata published on the blockchain. This model is favorable to Ambrosus’ enterprise clients, because large companies will inevitably operate these specialised nodes, defined as Apollo Masternodes on the AMB-NET system, giving them greater sovereignty over their sensitive data, all of which is stored off-chain.

Fueling the AMB-NET ecosystem is Amber (AMB) a blockchain token that ensures proper functioning of the supply chain-data environments. Using Amber, enterprises can trace the entire journey of their products from assembly line to end-consumer markets, ensuring that their supply chains and distribution networks are functioning properly.

1.3 Supply Chain Challenges

Combining industrial IoT sensor connectivity and autonomous PoA consensus, Ambrosus is designed to address the 5 key dysfunctions of modern supply chain management:

• Fragmented data silos
• Organisational miscommunication
• Inability to immediately process changes in inventory
• Rising global regulatory compliance costs
• Operational disruption and reputational damage caused by product recalls.

Many of these problems stem from a common underlying cause: The lack of a standardised and cost-effective system that trade counterparties can use to securely store, share and optimise their supply chain data. Ambrosus helps enterprises disintegrate their data silos, improving supply chain visibility, organisational communication, loss-prevention and quality control.

1.4 Intelligent Design

Through its AMB-NET core, Ambrosus has devised a secure, enterprise-grade platform, where the bulk of data is stored off-chain on client Masternodes, leaving only a cryptographic signature of entry metadata on the actual ledger. This off-chain storage architecture enables the seamless integration of AMB-NET supply chain intelligence with the internal IT systems of our users, resulting in enhanced interoperability for enterprise clients.

AMB-NET’s intelligent cryptoeconomic design merges best practices from existing cloud-storage solutions, Web 3.0 technology, information security and incentivised Masternode staking. Speaking to the latter, Ambrosus offers three primary classes of Masternodes — Apollo, Hermes and Atlas — and one Peer Node family — Perseus. They perform the following functions:

• Apollo — processes transactions and executes smart contracts
• Hermes — publishes digitally signed metadata to the AMB-NET blockchain
• Atlas — stores public data and promotes information resilience throughout the network
• Perseus — operated by everyday users and both centralised and decentralised applications (dApps)

Masternodes are obtained through rigorous KYC screening, network-threat analysis and usage-priced AMB token-staking. That is to say users must pledge a specified amount of AMB to the network, proportional to the amount of data they are storing, in order to operate AMB-NET Masternodes.

Now that we have given a high-level overview of AMB-NET’s utility and cryptoeconomic design, let us examine the key concepts and mechanisms that make this ecosystem work.

2. Key Concepts

2.1 AMB-NET Data Overview

By default, all data created on or uploaded to AMB-NET is private, as most enterprise data needs to be concealed, due to regulations, contractual agreements and trade-secret protection. All AMB-NET data is stored off-chain and covered only by a guarantee limited to tamper-proofing. The sole Owner of private data is responsible for preventing its loss and/or contamination.

However, data leaves a signature on the AMB-NET blockchain in the form of a hash function — an alphanumeric character string that corresponds to the data entry that was created/uploaded. The hash signature will never reveal any of the content of uploaded entries, rendering it impossible to decrypt or reconstruct private data. Instead, these hash marks preserve metadata in the form of Asset ID, Event ID, author, timestamp, and certain access-control conditions.

Functioning as a serial number or an identification code, this hash mark helps public counterparties, trade partners and regulators cross-reference published data with hash metadata, revealing the time, date and author stamp for the creation of AMB-NET data.

AMB-NET’s intelligent design ensures that data, once published and stored, cannot be modified without an accompanying audit trail, documenting the journey of the bundle or hash sequence.

2.2 AMB-NET Data Types

AMB-NET was designed to process three types of data:

• Private: Material non-public information or other protected data that is created and stored by a client for internal use only. Outside of the data producer, no entity can view these records, as they are securely siloed within the producer’s internal databases. Example: The price a company paid for a delivery of tomatoes.
• Shared: Private data that has been shared explicitly with one or several other peers. Only designated peers with valid authentication tokens are able to access this data. Example: The full history of shipment #223, sent by company Alpha to corporation Beta.
• Public: Private data that has been openly shared with every user on the AMB-NET network. Example: the ingredients list and expiration date on a yoghurt pack.

All AMB-NET data is logged as an “event stream” and classified by two core entity types:

• Assets: Models a physical or logical entity and represents a single stream of Events.
• Events: Captures all the supply chain data collected for one or multiple Assets

2.3 Receipt

To mitigate data-tampering risks, AMB-NET uses a PoA blockchain protocol that generates and stores a cryptographic proof of content at upload time. Due to proliferating Asset and Event entry volumes, it’s impractical to store a separate proof for each entry. Instead, these entries are grouped together into Bundles. A proof (in the form of a hash) of these Bundles is then stored on the blockchain alongside a minimal set of metadata. The actual content is stored on Hermes and Atlas Masternodes, where it can be later retrieved using traditional database technologies.

Bundles only hold full entries for public data. Private data is always represented by hash entries, which only reveal metadata about Assets and Events.

2.4 Expiration

All public AMB-NET data has a pre-defined storage life, with download availability expiring when the storage period ends. This expiration date mechanism can help enterprises comply with regulatory recordkeeping requirements, while mitigating AMB-NET congestion and data decay, when records become irrelevant. Data cleansing at regular specified intervals, ensures AMB-NET’s continuously high-transaction throughput and ledger operability.

AMB-NET enables clients to purge public and private data from their nodes once it has decayed beyond the point of compliance, regulatory or other recall utilities. Data lifespan can be defined at upload, with varying AMB-NET fee schedules determined by the storage needs of the client.

The holding time is specified during Bundle upload and published in the Receipt. It needs to be expressed in multiples of 365 days, with the minimal storage period being 365 days. There is no upper limit to data storage life. Ambrosus empowers its network to independently make those decisions.

AMB-NET’s discretionary data-cleansing feature is a key cryptoeconomic differentiator that ensures continuous operability and efficient transaction throughput for network participants. In this context, AMB-NET users are incentivized to implement data management best practices to promote a better network experience for themselves and the community.

2.5 Data Sheltering

Certain AMB-NET Masternodes will assume Data Sheltering responsibilities for the storage of client data until its expiration date. AMB-NET generally delegates this capability to Hermes Nodes, which produce data, and Atlas Nodes, which resolve Challenges and store data in exchange for AMB token rewards. But storage duties can also be determined by other network interactions and transactions.

2.6 Storage Fee

At the data-upload stage, users must pay a Storage Fee in addition to standard network transaction fees. Storage Fees are used to cover the costs of operating the network and redistributed to support various incentive schemes that reward designated Masternodes for storing or backing up data throughout its information lifecycle. All fees are paid in AMB tokens.

2.7 Nectar

AMB-NET prices AMB transactions in terms of Nectar, a specialized unit that measures the computational intensity of various actions on the network, and on a floating scale, akin to the concept of Gas in Ethereum. Thus, Nectar costs rise as data transactions become larger or more complex. In certain market environments, Nectar’s floating rate can also reinforce AMB-NET price stability, ensuring that Storage and Transaction Fees never become unreasonable or hinder the industrial adoption of AMB-NET. Thus, Nectar and Amber have a dynamic relationship to facilitate harmonic interaction between different stakeholders of AMB-NET.

2.8 Stake

Some AMB-NET users are required to deposit a specified amount of Amber to deter them from behaving in a way that disrupts or impairs the AMB-NET network. When this stake falls below a threshold value, the user loses the right to perform some network functions. The missing AMB needs to be replenished before the user can resume full participation on AMB-NET.

2.9 Penalties

Acting in a way that impairs the proper functioning of AMB-NET results in an AMB penalty for offending users. As it is not always possible to determine if misconduct was intentional, or the result of technical issues, penalties increases with each succeeding offence.

2.9a Storage Challenge

Any user who has assumed Data Sheltering duties can be Challenged by other users to reveal the records they claim to possess. This places the burden of proof on the Shelterer to respond to the challenge with the data being queried. The resolution of each Challenge is handled by an independent and staked Atlas Masternode.

When the Challenge is resolved, the Atlas Masternode that processed the query also becomes a Shelterer of challenged data, multiplying data resilience throughout the AMB-NET network. Failing to respond to a Challenge request results in a monetary penalty, which promotes persistent node engagement with and connectivity to AMB-NET.

2.9b Data Resilience

Data resilience is a key component of AMB-NET’s cryptoeconomic model. The outcome of a successfully resolved Challenge Request, data resilience is the duplication of records across another or various other nodes. AMB-NET incentivises other Masternode participants to copy and shelter this data, as a loss-prevention mechanism to reinforce the continuous discoverability of network Assets and Events.

2.9c Challenge Fee

Initiating a Storage Challenge requires the user to pay a fee in AMB. This Challenge Fee is used to cover the cost of resolving the Challenge and the resulting storage of the duplicate data. Fee-pricing is calculated proportionally to the holding period of challenged data.

2.9d Data Storage Transfer

A Data Shelterer can request that their storage contract be transferred to a different user. The recipient volunteers to shelter the data and, in return, receives a Transfer Fee paid by the requester. This Transfer Fee is priced as proportion of the initial Storage Fee, relative to the remaining storage life of the data, with a small premium included over the base amount.

3. Masternodes and Peers

3.1 Overview

While Peer Nodes are simply actors that interact with blockchain networks, Masternodes are a specialized component of cryptoeconomic systems. Beyond maintaining a full copy of the blockchain running in real-time at all times, Masternodes can perform all of the following higher-level functions:

• Enhance transaction privacy between peers
• Enable instantaneous transactions
• Execute smart contracts
• Participate in consensus

Ambrosus offers users three primary Masternode architectures: Apollo, Hermes and Atlas. Within the Atlas Masternode family, there are three subsets of nodes designated by their storage bandwidth in descending order: Atlas Omega, Atlas Sigma and Atlas Zeta. Meanwhile, Perseus Nodes are AMB-NET’s Peer Node family.

The following sections detail the different roles that network Masternodes and Peer Nodes can perform. These actions are actually automated by software applications and smart contracts. The staking information for each type of Masternodes is provided in Section 6.3.

3.2 Apollo

Apollo Masternodes operate AMB-NET’s PoA blockchain. They are responsible for validating transactions and executing smart-contract code. AMB-NET encourages Apollo activity by rewarding these Masternodes with a Transaction Fee for their services. Because they provide a network-critical service, Apollo Masternodes participants must undergo rigorous KYC and cyber-risk screening and stake a predefined amount of AMB, before they can process transactions.

3.3 Hermes

Hermes Masternodes upload data onto the network. They are the original producers and owners of data that determine its expiration date prior to upload. They can also pay other AMB-NET users a Storage Fee to host the data.

Hermes Masternodes participate in the system because it satisfies their need to store data with specific guaranties, conditions and rules. Because they are data producers, they must provide an amount of AMB proportional to the amount of data they are uploading on to the system, in addition to their basis stake.

3.4 Atlas

Atlas Masternodes are responsible for resolving Storage Challenges between network participants. They settle challenges with Hermes Masternodes and other Atlas Masternodes, in the pursuit of Challenge Fee awards discussed above. When Atlas Masternodes resolve challenges, they also become shelterers of that data. This increases data resilience, which mitigates the risk of information loss.

Atlas Masternodes are incentivised to participate in the system due to the prospect of Challenge Fee awards. Because they shelter data, Atlas Masternodes must stake AMB as well. Additionally, there are three tiers of Atlas Masternodes, ranging from largest data storage capacity to smallest: Atlas Omega, Atlas Sigma and Atlas Zeta.

3.5 Perseus

Regular network peers like mobile consumers, traditional applications and dApps are referred to as Perseus peer nodes. Perseus nodes are limited to downloading data from Hermes and Atlas Masternodes, and cross-referencing it with the hash Receipts stored on the AMB-NET blockchain.

Should the normal data-retrieval mechanisms fail, Perseus nodes can also activate the Storage Challenge mechanism. Perseus nodes engage with AMB-NET because they are interested in the data stored by the network for verification and decision-making purposes. These nodes do not publish or store network data, so they are not required to stake.

4. Mechanisms

4.1 Primary Data Upload

The purpose of this mechanism is to store Bundle proofs on the AMB-NET blockchain. It is performed by data-producing Hermes Masternodes. This is how it works:

1. Assets and Events are gathered by the Producer (Hermes Masternodes) for a given time period
2. A Bundle is created from the gathered entities
3. The Bundle is made available for download using a URL address
4. The Bundle proof is uploaded to the blockchain.

• a. The Producer declares the minimal holding period
• b. The Producer becomes responsible for data sheltering
• c. The smart contract verifies that a correct and proportional Storage Fee is assessed
• d. Part of this Storage Fee is paid to the Apollo Masternode validating the transaction
• e. Another percentage of the Storage Fee is used to initiate 5 Storage Challenges against the Producer’s data entry, with the originator of the Challenge being the smart contract

4.2 Storage Challenge

The Storage Challenge is used to verify that data is being properly stored and to promote data resilience throughout the network. Any network user can initiate a Challenge, with the only prerequisite being the payment of a Challenge Fee set in AMB. This fee is used as payment for the Atlas Masternodes resolving the Challenge and covers their resulting data storage costs when assume Data Sheltering responsibility for duplicated records. The AMB-NET Storage Challenge mechanism works like this:

1. A network participant sends a request to the blockchain specifying:

• a. The Data being challenged
• b. The Hermes or Atlas Masternode being challenged

2. Atlas Masternodes scan the AMB-NET blockchain for new Challenges and intervene, assuming they are not the Masternodes being challenged

3. If one Atlas node (that is not yet sheltering the challenged data) notifies the blockchain that they were able to retrieve the data being challenged:

• a. The first Atlas node to respond is selected to resolve the Challenge
• b. The Atlas node assumes Data Sheltering responsibility for the records being challenged
• c. They receive the Challenge Fee paid from the user that initiated the query

4. If no Atlas nodes respond within a system-defined time period:

• a. An AMB penalty is assessed against the challenged Masternode’s stake
• b. The challenged Masternode is relieved of Data Sheltering duties, preventing them for being penalized twice for the same information gap
• c. The Challenger recaptures the Challenge Fee they initially paid, and as a reward, also receive the AMB penalty paid by the previous Data Shelterer

Note: At the end of the Challenge the responding Atlas Masternode assumes Data Sheltering responsibility. But if they are challenged and fail to produce the data, they will suffer the same fate as the penalized shelterer they replaced.

4.3 Stake Withdrawal

If a Masternode operator wants to withdraw their stake, they must:

1. Stop any interaction with the system that could result in obtaining new Data Sheltering obligations (e.g. uploading a new proof, taking part in Challenges)
2. Wait until all Data they are storing expires. Alternately, stakeholders can employ AMB-NET’s Storage Transfer mechanism to offload their Data Sheltering obligations to other Masternodes in the network.
3. Notify the AMB-NET blockchain about the withdrawal.

4.4 Storage Transfer

Any user sheltering data can request to transfer their storage obligations to another participant on the network. This can help shelterers extricate themselves from their storage duties, enabling them to withdraw their AMB stake. The process works as follows:

1. The Data Shelterer notifies the blockchain that they want to transfer one of their storage obligations:

• a. The Data Shelterer specifies the exact data being transferred
• b. They remit the Storage Transfer Fee

2. Atlas nodes scan the blockchain for new Transfer requests, and act if possible.

3. If one of the Atlas nodes is able to download the data, they can notify the AMB-NET blockchain about their intent to become shelterers of this data.

• a. AMB-NET checks to see if this Atlas Masternode is already storing the data. If they are, this Masternode cannot participate in the Storage Transfer
• b. Only the first Atlas Masternode to respond is selected
• c. They take over as the Data Shelterer
• d. They Receive a Storage Transfer Fee from the requesting Data Shelterer
• e. The system resolves the transaction and no longer considers the requesting Data Shelterer accountable for the data transferred

4. If no Atlas node responds to the request in a system-defined time period:

• a. The requesting user recaptures the Transfer Fee they paid
• b. The requesting user remains the Data Shelterer

5. Risk Management

In the same way compliance and risk management are becoming new revenue drivers for financial institutions, the AMB-NET cryptoeconomy will need the right tools to properly screen, monitor and resolve counterparty risks to achieve its full potential. AMB-NET’s preliminary risk-management framework can be best segmented along the lines of front-end Know Your Customer (KYC) screening for Masternode applicants, accompanied by analogous onboarding processes to analyze the threats posed by counterparty cyber-infrastructures.

5.1 KYC

In the short-term, Ambrosus is exploring the use of Know-Your-Customer (KYC) applications to verify Masternode applicants. To obtain AMB-NET Masternodes, individual and business customers will have to provide some of the following data points: A valid passport for individuals; business tax-ID number for enterprises; primary address; phone number; ultimate beneficial ownership (UBO) information; and a registry of all significant directors, managers and corporate officers for enterprises; and other personally identifying information.

All company representatives, who satisfy a significant control or ownership (25 percent or more) prong over the organisation will be individually screened against a robust set of KYC, anti-money-laundering (AML) and adverse news databases. This process will help mitigate the risk of bad actors exploiting the AMB-NET ecosystem to commit cyber-enabled financial crime.

Down the road, Ambrosus will consider partnering with decentralised KYC providers like uPort. Additionally, Ambrosus is developing tools to monitor network interactions and transactions for suspicious activity to ensure the continuous good-standing of client KYC scores.

5.2 Cyber-Risk Mitigation

Beyond standard KYC and AML-screening, leading cryptoeconomic ecosystems need to have tools to evaluate the cyber-infrastructures of Masternode counterparties before they join the network, and follow-on monitoring capabilities to ensure that third-party systems do not become corrupted. In an evolving threat landscape marked by distributed denial of service (DDoS) attacks that cripple network operations, cryptojacking botnets, industrial espionage and malicious insiders it is imperative that AMB-NET collects as much threat intelligence as possible about the external systems operating its nodes.

To ensure that AMB-NET continues to operate unharmed and without disruption, Ambrosus is exploring partnerships with vendors that offer hybrid-DDoS mitigation and intrusion-detection systems, merging perimeter-based and cloud-based security. Collectively, this framework entails cross-referencing network data for IP address reputation; establishing parameters for appropriate traffic levels to instantly detect usage anomalies on the AMB-NET blockchain; using DDoS signature detection tools to rapidly identify and isolate attack sub-types; and deploying machine learning to decipher increasingly complex threat patterns.

5.3 Sustainable Governance

It may seem counter-intuitive, but the front-end, customer-monitoring and back-end processes highlighted in this section will reduce the threat of operational disruptions, regulatory enforcement actions and other events that could adversely impact the functioning of AMB-NET. These risk management concerns have a direct impact on Ambrosus’ cryptoeconomic model, because a service outage would make it impossible for new Masternodes to stake or for existing components to capture Challenge Fee or Data-Sheltering incentives. Implementing governance best practices from the modern financial industry, Ambrosus cryptoeconomic model is to promote network activity, liquidity and sustainability by preemptively mitigating the risk of adverse selection.

6. Constants

6.1 Fees

• Storage Fee — $10 USD per Bundle per 365 days
• Challenge Fee — 10% of the Storage fee for the same data
• Transfer Fee — part of the Challenge fee proportional to the remaining time the data needs to be held + 10% bonus

6.2 Storage Fee Split

50% is used to start five Ownership Challenges on the data

45% goes to the participating Masternodes

5% is burned

6.3 Stakes

● Apollo — 250’000 AMB

● Hermes — 150’000 AMB

● Atlas — Omega 75’000 AMB / Sigma 30’000 AMB/ Zeta 10’000 AMB

6.4 Penalties

• Base Penalty is 1% of the nominal stake of an actor
• First offence will be result in a Penalty equal to the Base Penalty
• On each following offence, the Penalty is doubled
• After 90 days without an offence, the Penalty is reset to the Base Penalty
• If a user has an insufficient Stake to cover the next potential Penalty, they lose the ability to perform certain actions until a threshold staking amount is replenished.

7. Conclusion

In closing, we hope this introduction to AMBERnomics has demonstrated a digestible and defensible overview of AMB-NET’s data ecosystem, incentive structure, staking mechanisms, and governance controls. The overall impetus of this cryptoeconomic model is to increasingly reward long-term network engagement and integrity through proper delegation and maintenance of Masternodes. To this end, Ambrosus is also modelling incentive mechanisms linked to stake duration, client reputation and enterprise data-management best practices.

Innovating decentralised IoT-data solutions for enterprise supply chains, Ambrosus is emblematic of the Fourth Industrial Revolution technologies that are reshaping trade as we know it. In an age where enterprise value of data (EvD) has become the most critical balance sheet metric for organisations, Ambrosus’ hybrid technology can repurpose companies’ raw supply chain data and metadata into catalysts for monetization, insight and growth.

Initially targeting life-essential food and pharmaceutical markets, Ambrosus could ultimately signify a quantum leap for supply-chain efficiency across industries, helping enterprises and AMB-NET users unlock the next generation of value.

We welcome our Community to share your thoughts and feedback about AMBERnomics!

Legal Disclaimer: This is intended to be a technical vision summary of a cryptoeconomic model 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 ahead of the launch of the main-net and may result in some changes to the specifications 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. 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.