REMAP Token-Economic Design

REMAP builds a stable, secure and scalable blockchain infrastructure, offering essential tools and functionalities to facilitate the development of applications and modules by software developers, individual entrepreneurs or companies, for PropTech users.

The following sections explain REMAP’s approach in more detail. As the REMAP’s Issuance Model is deeply embedded in its architecture, this section includes a discussion of REMAP’s architectural design and layered module structure as well as value transfer using the one-coin approach. Additionally, key features such as role-based validation, Augmented Bonding Curves, revenue distribution, and the strategic phased introduction of the REMAP ecosystem are discussed.

Token aspects of REMAP Layers

The layered architecture of the REMAP has been introduced in Technical Architecture Concept, however, it is still necessary to describe the token economics of the modules created and deployed in these layers. The different layers serve different purposes and are connected via a revenue-sharing system based on REMAP’s layered module architecture.

Layer 1 – Infrastructure Layer:

The infrastructure layer is the foundational layer on which Layer 2 and Layer 3 depend. Layer 1 includes the core, most basic modules (e.g., Consensus, Governance, API) that are a fundamental input for the development of Layer 2 and 3 modules. In this layer the most stable and hard-to-change modules will be configured. Initially, these modules will be provided by REMAP Organization. Changes of the foundations of this layer are governed by DAO 1 (see REMAP Ecosystem Governance). Revenue on Layer 1 is generated by Layer 2 modules (and indirectly Layer 3 modules) that use modules from Layer 1. For example, Layer 1 initially takes a fixed 1% fee share in RMC from the total service commissions gathered by Layer 2 (see revenue model and sale cycle).

Layer 2 – Functionality DApp Layer:

This layer includes tools and functionalities, such as payment and authorization modules, which are employed by Layer 3 applications and created by developers using Layer 1 modules. In other words, they are the foundation for the development of Layer 3 modules. At the launch of the platform, some of these modules will be provided by the REMAP Organization. Like with Layer 1, changes to the foundations of Layer 2 are governed by a distinct DAO (DAO 2; see REMAP Ecosystem Governance). Revenue on Layer 2 is generated by modules from Layer 3 using Layer 2 functionality. For example, Layer 2 initially takes a fixed 2% fee share in RMC from the total service commissions gathered by Layer 3 modules (see revenue model and sale cycle).

Layer 3 – Business DApp Layer:

The Business Layer connects to the end-users (individuals and companies) with applications like the renting module. To create these applications, developers use Layer 2 modules. At the launch of the platform, some of these applications and modules will be provided by REMAP Network. With the growth of the platform, any PropTech functionality can be implemented on this layer by third-party software developers (see Section 5 for examples). Developers will be able to use the platform’s features to create modules without any upfront cost. All changes to this layer will be governed by DAO 3 (see REMAP Ecosystem Governance). Layer 3 modules charge a fixed 3% fee in RMC to end users of the applications on this layer. These revenues feed 2% to Layer 2. The initial 3% fee is the highest among the layers because it is the most specialized layer and the one that directly interacts with the end-users. This fee ensures that software developers are adequately compensated for the creation, maintenance, and user support of these applications.

Revenue Model

The revenue-sharing model provides the incentive to create value within the ecosystem and encourages long-term participation. Below we show how a simplified sales cycle for REMAP layered module architecture could look like:

1. Software developer A creates a new module on Layer 3 and publishes it on the REMAP
   platform, complying with the requirements of the DAO Layer 3.
2. An end-user, individual and/or businesses, uses this module (e.g., P2P Asset Rental Module)
   and pays (in RMC) the fee for using it.
3. Software developer A receives the RMC fee payment through his/her SBT role-based ID.
4. Software developer A then compensates Layer 2 for modules used.
5. In turn, Layer-2 software developers receive this compensation and compensate Layer 1.

For instance, if developer A wishes to publish his/her module for free, developer A still must compensate lower layers for lower-layer modules used in his/her module. An example is: A user wants to rent a building through a renting business logic that resides on Layer 3. The rent for the building costs 1,000 RMCs. In this case, the Layer 3 application creator receives a 3% fee (30 RMCs). If the software developer of the renting module utilized modules from Layer 2 (e.g., a payment module and a verification module), the Layer 3 developer owes 2% of the revenues (20 RMCs) to the Layer 2 module creators. As two Layer 2 modules were used, this fee is split evenly among them, yielding 10 RMCs each. If a Layer 2 module developer used four modules from Layer 1, 1% of the revenues are split evenly among the four Layer 1 module developers. This results in each Layer 1 module developer receiving 2.5 RMCs. This hierarchical structure allows for rewards at each level, encouraging developers to create and contribute modules to the ecosystem.