The goals for InterChain in 2026 are simple: scalable, stable, and lower fees; faster execution and finality; further decentralization of consensus. After implementing the initial set of configuration changes and introducing a subsidy for on-chain block consensus to address the wMPC adjustment, the Anchor fork is the first structural set of changes applied to InterChain in pursuit of the set goals.

In this article, we will address the underlying reasons that shaped the set goals and describe the changes introduced by Anchor.

Interchain fee model

Before we dive into the different interchain components, let's introduce the fee model behind InterChain consensus execution. The fee model is at the core of InterChain transaction planning, estimation, and execution. It models the required fees for all executing chains, InterChain on-chain consensus, mempool management, and node operators' revenue.

We can define a simplified version of the full model as follows:

The simplified model helps us define the three main drivers of InterChain transaction fees: masterchain on-chain consensus fees, partial-chain on-chain consensus, and transaction execution and mempool fees.

Of the three main parts, the largest contributor to the overall fee is the masterchain consensus fees, paid in wMPC on the Partisia Blockchain. Masterchain consensus fees are also the main reason for fee instability stemming from adjustments to wMPC gas properties, as they directly affect InterChain execution and transaction fees.

To achieve scalable, stable fees for InterChain transactions, the main focus is on optimizing and reducing the masterchain consensus fee and removing its dependence on wMPC gas properties. This focus is clearly evident in the published 2026 plan for InterChain development and in the upcoming Anchor fork.

Masterchain on-chain consensus

Before we describe the fee-optimization paths for the masterchain consensus, we need to define its current state. The InterChain masterchain consensus is part of the overall block and transaction lifecycles, focused on building, signing, and publishing master blocks. The process is split into several steps, being executed both off and on-chain.

The following diagram shows a simplified version of the masterchain consensus steps before the Anchor fork:

As seen in the diagram, most of the consensus executes on-chain: multi-chain block proposal, state validation, and the full signing and publishing lifecycle. This process is part of the initial InterChain design, which allows it to rely less on specialized nodes and rather operate mostly through smart contracts deployed on existing L1 blockchains.

This design also introduces smart contract execution fees that, at scale, do not align with InterChain's long-term goals for cheap and fast cross-chain execution. For these reasons, and as described in the 2026 focus points plan, InterChain is transitioning to a more balanced design in which off-chain and on-chain execution require fees with a more predictable, stable, and scalable size.

The introduction of the subsidy focused on a temporary reduction in mempool commitment and state validation fees, making block signing and publishing the main fee contributors.

Block confirmation

To fully understand and appreciate the changes introduced by the Anchor fork to transaction execution speed, we need to define the current block confirmation process.

In the InterChain block lifecycle, confirmation of masterchain blocks directly dictates finalization of transactions. Partial chains prepare transaction execution parts during the block publishing lifecycle, but they execute them only after blocks are confirmed.

In the initial InterChain design, confirmation of blocks is part of the new block publish execution. After the set confirmation time passes, the next minted block contains an array of confirmed block hashes, thereby confirming these master blocks. Once the new master block mints, the publication of corresponding partial blocks executes the transaction parts of the confirmed master blocks.

The following diagram shows the confirmation lifecycle according to the IC initial design:

This design requires a new block to confirm the previous one, leading to variable transaction finality times depending on the blockchain's usage. Such variable execution does not align with InterChain's long-term goal to provide fast, predictable execution of cross-chain transactions.

"Anchor" fork

The first fork of InterChain introduces changes focused on fee stabilisation and reduction, and sets the first steps towards the decentralisation of the blockchain.

Let's look over "Anchor" in greater detail and showcase how the fork makes InterChain faster, cheaper, and more scalable.

Off-chain block signing

Before the Anchor fork, as described above, the main contributors to masterchain consensus fees are block signing and publishing. As a first step towards greater balance in off-chain and on-chain masterchain consensus execution, "Anchor" introduces off-chain block signing.

The change splits the current block lifecycle, removing the on-chain trigger for block signing and replacing it with an off-chain process that uses the already available p2p protocol. Once a new master block is built, InterChain block signers pull the block from the master chain, sign it, and broadcast their signatures. Once quorum is reached, signatures are pushed to the masterchain, where validation is executed, and the block is stored.

The consensus changes eliminate unnecessary on-chain event registration overhead, resulting in a faster, cheaper signing process. The publish process for master blocks remains the same, but also benefits from lower execution costs by replacing the external call pipeline with direct publication.

The following diagram shows the block lifecycle after the Anchor fork:

From the diagram, we can see how off-chain signing affects the overall lifecycle: it removes parts not covered by the subsidy, effectively lowering fees for InterChain transaction execution, and sets up the process for more scalable consensus.

Independent confirmation

The introduction of confirmation as part of the block publish lifecycle, as per InterChain's initial design, is a simple, cost-effective way to achieve final transaction execution. It does not require additional steps in master and partial block lifecycles, nor does it require verification of any additional oracle node or block signer signatures.

By design, InterChain does not mint or publish empty master blocks, and during periods of an empty mempool, block time becomes variable until activity resumes. This design plays a major role in InterChain's sustainability and multi-chain throughput, as nodes prepare and execute blocks only for active partial chains. The design that prevents minting empty blocks also introduces a delay in confirming past blocks during periods of low activity, effectively delaying transaction execution - hurting actual transaction throughput and limiting use cases that require an exact timeframe of execution.

A predictable finality for transactions is one of the requirements set for InterChain in 2026 due to upcoming use cases and protocol requirements, and to address this, "Anchor" introduces independent block confirmations. The change decouples confirmation from the block publish lifecycle and introduces an independent step for block confirmation in the master and partial block lifecycles.

Master block confirmations will use the lighter p2p block signer protocol to introduce an extra consensus step with minimal cost and overhead. This extra step in the master block lifecycle will execute once block timestamps meet the required confirmation time in a single Partisia Blockchain transaction containing block confirmation signatures.

To fully implement independent confirmation and timely transaction execution, partial chain block confirmation is also decoupled from the block publishing process. As a result, an independent block confirmation step is added to the partial block lifecycle, implemented as an oracle event submission that witnesses the master block confirmation time. Once partial block confirmation is completed, all scheduled transactions in the block are executed and cannot be reverted, achieving finality.

The following diagram shows the new master block lifecycle, featuring independent block confirmations as well as confirmation witness execution as part of the partial block lifecycle:

Conclusion

The changes introduced by "Anchor" are the first step towards the bigger goals set for 2026: lowering the fees for masterchain consensus and transaction execution, and achieving predictable execution time. As a result of the changes, blocktime and confirmation time are further reduced to meet new project requirements.

On top of fee and time reduction, block signing change is the first step towards the goal of decentralization - increasing the value of InterChain nodes. Further down the year, decentralization of node operations will increase the stability and security of the blockchain, and future forks will introduce further changes to achieve this goal.

We are happy to announce the first fork of the InterChain mainnet, and we continue to work toward achieving the set goals in sync with the focus areas.

Table of contents

1. Introduction

2. Types of inflationary tokens and how they work

3. Examples of inflationary tokens

4. Inflation on OpenDApps Cloud 

   1. Introduction

   2. Why is it unique?

   3. The Math

5. Deployment configuration on OpenDApps Cloud

6. Inflation rewards management on OpenDApps Cloud

   1. Automatic burn

   2. Staking rewards

   3. Distribution to an address

Introduction

In this blog post we will take a look at the concept of inflation for ERC-20 tokens, how inflation found a use-case for cryptocurrencies, and what are the real-world examples of successful projects with inflationary tokens.

We will also show you how to deploy inflationary tokens using OpenDApps Cloud Testnet dApp with an explanation of the available configurations for deployment as well as the management of inflation rewards.

Before we start make sure you have MetaMask set up and you have successfully connected and logged into OpenDApps Cloud. A quick guide on how to do that on testnets can be read here:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/UKO8kgnS8bELkxTr1mvLmfUeujFHL14nQUEFhJuk4-o

Before taking a grasp into inflationary tokens you have to be familiar with the concept of ERC-20 tokens and OpenDApps Cloud Token-as-a-Service solution. An overview of those can be found in this blog post:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/NY793yev6-g-0YouIRggNEZ4CmtRBdpQXwu1lXGk1_8

Let’s get started!

Types of inflationary tokens and how they work

Similar to most real-world currencies, inflation for cryptocurrencies is by definition the creation of new tokens, which increases the total supply of the cryptocurrency. Most of the time there is a big difference in the means of how new tokens are created for cryptocurrencies compared to real-world currencies.

The inflation for real-world currencies comes mostly from central banks' issuance of new banknotes and banks loaning more than their actual reserves. In the cryptocurrency world, inflation can be created in many different ways, some of which being:

1. Inflation as block rewards for native tokens — new tokens are created every block and are paid out to the miner/validator that mines the block. This creates an incentive for miners/validators to participate in consensus further securing and distributing the blockchain. Block rewards are a fundamental part of most blockchains and most of the time they come from inflation.

2. Periodically mint a fixed amount of tokens as a reward for owners — a token is supplied with a mint function that can be manually called once a fixed amount of time has passed and a fixed amount of tokens are created to reward the owners. This is a common practice in DeFi protocols that supplies the creators with fresh capital for running and working on that protocol.

3. Algorithmically increase the supply with rewards distribution — the supply of the token is increased through an algorithm with increasing or decreasing rewards. Each time the new tokens are minted they are distributed as rewards to various receipts in a configurable manner. This can be seen in newer blockchains where block rewards are distributed to various needs and not only to miners/validators.

Another big difference between inflationary tokens is the existence of maximum supply. Some tokens have a max supply and mining of new tokens stops after that number is reached while others have an endless process of new tokens issuance while offering other means to limit the increase of supply without a theoretical maximum.

Examples of inflationary tokens

Here we will take a look at some existing cryptocurrencies and tokens using inflation as a part of supply distribution.

1. Bitcoin — the first and the biggest blockchain that currently exists. New amounts of the native token BTC are issued every block and rewarded to the miner. BTC block rewards are minted on a timeline decreasing every few years at a predefined block height — an event called halving. The process continues until the max supply of 21,000,000 BTC is reached and block rewards are removed. This is one of the most well-known algorithms of inflation in the cryptocurrency world.

2. Ethereum — the original EVM blockchain has a different approach to inflation. ETH has no maximum supply and new tokens are issued every block without a predefined algorithm for decreasing block rewards size. The size is rather decided by Ethereum Improvement Proposals. Ethereum approach gives more flexibility and promises better longevity than having a fixed supply while still managing to reduce total supply with the burning fees.

3. DeFiChain — a fork of Bitcoin that follows the same decreasing block rewards algorithm with max supply but adds additional features to inflation like configurable rewards distribution through DFIP voting. This is a powerful addition to the algorithm while still maintaining the original properties of the Bitcoin solution.

4. Uniswap — a DeFi protocol that launched its token UNI on Ethereum. The UNI token has a different approach to inflation and it has defined a 2% inflation per year after the first 4 years. The rewards are distributed to the community to ensure continued participation.

Inflation on OpenDApps Cloud

Introduction

Inflationary tokens are one of the unique selling points of OpenDApps Cloud Token-as-a-Service solution. Inflation is not easy to program in ERC-20 tokens and that is the reason why it is quite rare while being pretty common for native tokens.

If an ERC-20 token is inflationary, most of the time it is through some time-based manual minting, and no standard or available service is providing an easy and reliable algorithm for ERC-20 inflationary tokens.

This is where the OpenDApps Cloud Token-as-a-Service solution shines. It offers very flexible and easy-to-deploy algorithmic-based inflationary tokens. The tokens have all the other benefits of the OpenDApps Cloud ERC-20 template while offering the additional configuration of inflationary cycle rewards distribution.

Why is it unique?

OpenDApps Cloud Token-as-a-Service solution takes the good from all available inflation solutions and combines them into a single inflation algorithm.

Inflationary tokens deployed on OpenDApps Cloud have a max supply and start with a total supply between 50% and 90%. The rest of the supply is minted automatically for every predefined amount of underlying blockchain blocks with a decreasing cycle rewards size similar to Bitcoin. The cycle rewards do not get reduced in half every cycle but rather follow a formula ensuring a decrease to 0 when approaching max supply.

Cycle rewards distribution from inflation is fully customizable and configurable at any time during the lifetime of the token. Rewards distribution is inspired by the DeFiChain approach to inflation and it can be configured to provide rewards to owners, to staking contracts, and much more through wallet distribution.

The Math

This paragraph is here to show the formulas behind the decreasing cycle rewards and total supply increase through inflation. It might be a little geeky so read on with caution.

Let’s get right into it.

First, we will define the initial supply that our token will start with as well as the max supply. Those two are input parameters for our inflationary token and from them, we can easily calculate the supply of inflationary rewards:

We can have to define the total number of rewards cycles we want our rewards supply to be distributed in:

From here we want to define the algorithmic formula for the size of rewards for a particular cycle. We are using a decreasing rewards algorithm where the size of the rewards decreases with a fixed amount each cycle until reaching 0 on cycle C(X) + 1:

We can calculate the limit of UR(X, Y) to check if rewards will actually reach 0 if Y -> C(X) + 1:

After we defined the formula for the algorithmic decrease of cycle rewards we need to define the formula for the calculation of total unlocked rewards for a particular cycle as the sum of all unlocked rewards for the past cycles:

From here it is pretty easy to define what the total supply of rewards R(X) will be if we use the total unlocked rewards TUR(X, Y) with Y equal to the last cycle C(X):

With R(X) already known, we can use it to finally calculate the size of the rewards in the first cycle Y = 1, UR(X, 1):

Our inflationary token template takes the parameters for M(X) and I(X), calculates R(X) and UR(X, 1), and after that uses TUR(X, Y) and UR(X, Y) to mint additional supply according to decreasing rewards algorithm.

If you got this far, kudos to you!

Let’s move on to some more interesting stuff.

Deployment configuration on OpenDApps Cloud

Inflation can be enabled for tokens in OpenDApps Cloud in the phase of deployment. Before we dive into the available configuration for inflation make sure you know how tokens are deployed in our dApp from our guide:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/TEtZDO4ibj843rVXv8HuARpOQ1Xhv2ItZtcDGtgbTOU

Now that we know how to deploy tokens let’s look closer into the available configuration for inflation. After we enabled it we can see three main sliders:

The Initial Supply slider is important because this is the number that the token will start with as a total supply after deployment. It is defined as a % from Max Supply defined using the slider in tokenomics:

The combination of Max Supply and Initial Supply is used to calculate cycle rewards according to the decreasing rewards algorithm described in the math section above.

The next slide Rewards Minting Speed allows for the configuration of cycle speed. Every cycle new supply is minted according to the decreasing cycle rewards algorithm.The cycle speed is defined in blocks but it is converted into approximate time according to the blockchain block speed.

The slide Rewards Per Mint allows for the configuration of the AVERAGE rewards per mint through the lifetime of the token according to the decreasing cycle rewards algorithm.It is essentially UR(X, 1) / 2 (sorry for the math, see above), and in practice, it controls the number of cycles that will be executed for the distribution of the supply of the cycle rewards.

With these options, we can fully control the inflation parameters and once we are happy with the result of size and timeframe we can deploy our token. The configuration for the rewards and decreasing cycle rewards algorithm are permanent for the token and cannot be changed after deployment!

After successful deployment, the information for current supply, average rewards per cycle, and max supply reach are available at the tokenomics page in OpenDApps Cloud dApp:

Inflation rewards management on OpenDApps Cloud

After deployment, inflation rewards distribution can be fully customized and configured at any point in time in the lifetime of the token. To manage the configuration we need to go to the tokenomics editor page which is accessible through the dashboard:

Once we are on the tokenomics editor page we can switch to the inflation tab where we can manage the rewards distribution:

As we can see there are some predefined values in the inflation rewards tab.There is a 1% tax for all inflationary tokens deployed on OpenDApps Cloud that is paid to the platform through the rewards and it cannot be altered or removed!

Let’s look into the different possibilities.

Automatic burn

Any unused rewards are automatically burned and from the initial state of inflation configuration, 99% of the rewards are burned. We need to add distribution to change that and we can monitor the burn size from the Burned Rewards Slider:

Staking rewards

If we have staking deployed we can use the Staking Rewards slider to feed the staking contract with fresh tokens every cycle to distribute to the holders part of the staking pool:

This is a great way to generate staking rewards and provide holders with an incentive to hold and stake their tokens for the long term while the project is still in development.

Distribution to an address

Similar to tokenomics, for any other needs we can use the wallet distribution configuration. It allows us to configure a % from inflation rewards to be contributed to any wallet or contract address we provide. This option is the backbone of all custom utilities like marketing or developer payments, charity, custom contract interactions, and much more.

To add an address to rewards distribution we can use that “Add Address To Distribution” input, part of the inflation rewards management form:

For this example, we will input a wallet from the theoretical developer. Once we input the wallet, a slider will pop up allowing us to configure the requested % from rewards we want to distribute to the wallet:

After we execute the save transaction we will have the option to edit the distribution at any time as well as to remove any we do not need anymore:

This wraps it up with our overview and guide to inflationary tokens in OpenDApps Cloud.

In-depth guides on available services and other SaaS-related information resources are available in this blog and any related content will be linked here:

1. OpenDApps Cloud — Testnet Connection and Testing Guide

2. Token-as-a-Service on OpenDApps Cloud — An Overview

3. Guide: How to deploy ERC-20 Tokens using OpenDApps Cloud

4. Tokenomics on OpenDApps Cloud — An Overview & Guide

5. Baseline Price Insurance Service for Tokens on OpenDApps Cloud — An Overview

6. Decentralized Companies in OpenDApps Cloud — An Overview

7. More….

Table of contents

1. Introduction

2. What are tokenomics?

3. Importance of tokenomics in ERC-20 tokens

4. Example of tokenomics

5. Management of tokenomics for tokens on OpenDApps Cloud

   1. Types of taxation

   2. Taxation limitations

   3. Automatic burn

   4. Automatic addition of liquidity to DEX

   5. Staking Rewards

   6. Distribution to an address

Introduction

In this blog post, we will dive into the concept of tokenomics, how they are connected to ERC-20 tokens, and how they became one of the main powers behind any blockchain project.

We will look over some examples of tokenomics use cases as well as take a deep dive into the management of tokenomics for tokens deployed using OpenDApps Cloud services.

Before we start make sure you have MetaMask set up and you have successfully connected and logged into OpenDApps Cloud. A quick guide on how to do that on testnets can be read here:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/UKO8kgnS8bELkxTr1mvLmfUeujFHL14nQUEFhJuk4-o

Before taking a grasp into tokenomics you have to be familiar with the concept of ERC-20 tokens and OpenDApps Cloud Token-as-a-Service solution. An overview of those can be found in this blog post:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/NY793yev6-g-0YouIRggNEZ4CmtRBdpQXwu1lXGk1_8

Let’s get started!

What are tokenomics?

In the context of ERC-20 tokens, tokenomics encompasses various factors that influence the token’s value, distribution, and utility within the blockchain network.

Tokenomics can vary significantly from project to project. Careful consideration is crucial for creating a token that aligns with the project’s goals, engages the community, and maintains a healthy economic ecosystem.

Here are some key components of tokenomics in ERC-20 tokens:

1. Total Supply: The total number of tokens that will ever exist. This number is usually fixed during the token’s creation and can affect scarcity.

2. Initial Distribution: How tokens are initially distributed among participants. This could include an allocation to the project team, early investors, advisors, partners, and the broader community through a token sale.

3. Token Issuance Rate: If the token supply is not fixed, the rate at which new tokens are created and introduced into the ecosystem can impact inflation and scarcity dynamics.

4. Transfer Taxation: Tokens add taxation on buy/sell transactions or on all transfers. The tokens gathered from the taxation are distributed and used for different utilities like burning, buyback, developer or marketing pays.

Importance of tokenomics in ERC-20 tokens

Tokenomics is important for ERC-20 tokens, serving as the strategic blueprint that shapes the token’s entire lifecycle. It holds the economic framework that defines the token’s utility, and distribution within the blockchain ecosystem. This framework directly influences investor sentiment, user engagement, and the project’s overall success.

At its core, tokenomics aligns incentives and behaviors within the ecosystem. A well-designed tokenomics model establishes clear motivations for users, developers, and investors, fostering active participation and contribution. This, in turn, generates a network effect as more users join the ecosystem, potentially enhancing the token’s value proposition and attractiveness.

Furthermore, tokenomics provides the groundwork for sustainable growth. By determining token issuance, scarcity, and utility mechanisms, projects can manage volatility, prevent extreme inflation or deflation, and ensure the token remains a viable means of exchange and value storage. In sum, tokenomics is the strategic backbone that not only influences economic dynamics but also defines the essence of a project’s community, utility, and long-term potential.

Example of tokenomics

Almost every token deployed on an EVM blockchain has some kind of taxation on buy and sell transactions. The funds are then used to fulfill the utility goal set by the project owners. To show the power of tokenomics we will take a look at the well-known token SafeMoon. The tokenomics of SafeMoon are built around taxation on every transfer.

The tokens from the taxation are then split into different parts:

1. Token Reflections— 4% is split proportionally among all holders

2. Auto Liquidity: 3% to Liquidity Pool

3. Auto Burn: 2% to Burn

4. Wallet Transfer: 1% to Ecosystem Growth Fund

As we can see tokenomics can be a powerful instrument that shapes the token and allows very flexible distributions.

Management of tokenomics for tokens on OpenDApps Cloud

The tokenomics configuration for the taxation of transfers is fully customizable and changeable at any time for tokens deployed using OpenDApps Cloud.

If you want to learn how to deploy ERC-20 tokens using OpenDApps Cloud read our guide:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/TEtZDO4ibj843rVXv8HuARpOQ1Xhv2ItZtcDGtgbTOU

Once a token is deployed using OpenDApps Cloud dApp we have access to the Tokenomics configuration page. To access we can go to our dashboard, find our token and select “Manage Tokenomics” from that menu:

This will transfer us to the “Manage Tokenomics” page for the token. Here we can adjust taxation tokenomics executed on buy, sell, or wallet transfers:

As we can see all tokens deployed using OpenDApps Cloud dApp have a default buy and sell tax of 1% which goes to the platform as service fee. The maximum tax from all distributions combined per tax type is 9%, or 10% if we include the 1% service tax.

Let's dive into the individual configurations and how they can interact with our token and what can be achieved with them.

Types of taxation

As it can be seen from the photos above there are 3 main types of taxation in OpenDApps Cloud Token-as-a-Service tokenomics. The types are as follows:

1. Buy tax — taxation is executed on all buys from any DEX where the token is listed using OpenDApps Cloud Treasury. After each buy the tokenomics configuration is executed and tokens are distributed utilizing it.

2. Sell tax — taxation is executed on all sells to any DEX where the token is listed using OpenDApps Cloud Treasury. After each sale the tokenomics configuration is executed and tokens are distributed utilizing it.

3. Transfer tax — taxation is executed on transfers between wallets. After each wallet transfer the tokenomics configuration is executed and tokens are distributed utilizing it. Transfer tax is disabled by default and has to be enabled before tokenomics are executed.

Taxation limitations

To ensure fair use and a smoother experience for the token holders, OpenDApps Cloud has put in place some limitations to the allowed configurations of tokenomics.

The maximum size of taxes for any of the supported taxation is 10% which is fair and more than enough for any kind of need. This ensures that project owners will not lock holders with a 99% tax on transfers creating a honeypot.

Transfers between a wallet and a contract cannot be taxed, allowing for a smoother experience with staking, asset backing, and any other service from OpenDApps Cloud.

Automating liquidity is not executed on each transaction because it will allow sandwich attacks. Instead, the tokens are collected until a threshold is met and the swap in addition to liquidity is executed from an external service providing trustable oracle data on the price for permits eliminating the typical attack on automatic liquidity tokens.

Staking rewards can be configured from taxation only when the staking service is used and deployed. Otherwise, the rewards cannot be configured.

Automatic burn

Burning is a way to decrease the supply of a token. A lot of tokens implement automatic burning tokenomics with their taxation on buy or sell transactions. This turns the token deflationary reducing the supply with every transaction.

Tokens deployed using OpenDApps Cloud dApp have access to automatic burn using the “Auto Burn” Slider:

Moving the slider to the right will increase the automatic burn for our buy tax. The slider then allows us to save the configuration onto the blockchain:

After we click save we can execute the transaction and after it is successful our tokenomics configuration will now distribute 5% of each buy to automatic burning making our token deflationary. The burning can be observed in a blockchain explorer where buys will have 5% of tokens being sent to the empty address 0x0000….

Automatic addition of liquidity to DEX

Liquidity on a DEX is usually an indicator of token price strength. The greater the percentage of liquidity compared to the market cap, the more stable the price is during large volumes. This is why a lot of projects incorporate auto liquidity into their transfer taxation strengthening their liquidity a little each time a transfer take place.

Tokens deployed using OpenDApps Cloud dApp have access to auto liquidity after they have listed their token on a DEX using the “DEX Listing” toolkit. After the token is listed on a DEX, the “Auto Liquidity” slider can be used to set up auto liquidity distribution:

Staking Rewards

Staking is one of the most common ways to reward token holders for their diamond hands. Staking often requires holders to give their tokens to a smart contract where streams of rewards are collected and later holders can collect them depending on their staking pool share.

One way to generate a stream of staking rewards is through taxation distribution where a % of every transaction for the selected taxation type is transferred to the staking contract as rewards for holders.

Tokens deployed using OpenDApps Cloud dApp can configure staking rewards from taxation after they have deployed a staking service using the “Deploy Staking” toolkit:

After deployment of the staking service, staking rewards distribution can be enabled from the tokenomics management form:

Clicking the “Enable” button will execute a blockchain transaction allowing us to input the required % of taxation for the staking rewards distribution using the slider:

Distribution to an address

If we have any other idea for tokenomics distribution we can use the very powerful “Auto Distribution”. It allows us to configure a % from any taxation to be contributed to any wallet or contract address we provide. This option is the backbone of all custom utilities like marketing or developer payments, charity, custom contract interactions, and much more.

To add an address to automatic distribution we can use that “Add Address To Distribution” input, part of the tokenomics management form:

For this example, we will input a wallet that we will use for developer payments from taxation. Once we input the wallet, a slider will pop up allowing us to configure the requested % from taxation we want to distribute to the wallet:

After we execute the save transaction we will have the option to edit the distribution at any time as well as to remove any we do not need anymore:

This wraps it up with our overview and guide to tokenomics in OpenDApps Cloud.

In-depth guides on available services and other SaaS-related information resources are available in this blog and any related content will be linked here:

1. OpenDApps Cloud — Testnet Connection and Testing Guide

2. Token-as-a-Service on OpenDApps Cloud — An Overview

3. Guide: How to deploy ERC-20 Tokens using OpenDApps Cloud

4. Inflationary Tokens on OpenDApps Cloud — An Overview & Guide

5. Baseline Price Insurance Service for Tokens on OpenDApps Cloud — An Overview

6. Decentralized Companies in OpenDApps Cloud — An Overview

7. More….

Table of contents

1. Introduction

2. What are ERC-20 tokens?

3. Difference between ERC-20 tokens and native cryptocurrencies

4. Usecase for ERC-20 tokens for projects

5. Token-as-a-Service on OpenDApps Cloud5.1 Introduction5.2 Tokenomics5.3 Inflation5.4 Additional Services

Introduction

In this blog post, we will dive into the world of ERC-20 tokens and how they became the most deployed smart contract standard in the whole crypto industry.

We will overview their history, their use cases for projects, and how they differ from native cryptocurrencies. We will also explore the concept of tokens deployed as a software-as-a-service solution — Token-as-a-Service on OpenDApps Cloud.

We will also look into the possibilities for using OpenDApps services to build projects around tokens and how they can be extended by using some of the platforms’ other services like staking, dApp-as-a-Service, etc.

Let’s dive in.

What are ERC-20 tokens?

ERC-20 tokens are a type of digital asset that is built on the Ethereum blockchain. The ERC-20 introduces a standard for Fungible Tokens, in other words, they have a property that makes each Token exactly the same (in type and value). ERC-20 tokens have become one of the most widely used and adopted token standards in the blockchain ecosystem.

ERC-20 tokens are implemented as smart contracts on the Ethereum blockchain and later on, implemented on other EVM-compatible blockchains like BEP-20 on BSC. ERC-20-compatible smart contracts must implement a specific set of functions to be compliant with the standard. These functions include getting the total supply of tokens, checking an account’s balance, transferring tokens from one account to another, and approving spending allowances for other accounts.

ERC-20 tokens can be transferred and owned like any other cryptocurrency. They can be sent from one Ethereum address to another using Ethereum transactions.

The ERC-20 standard has played a significant role in the development of the decentralized finance (DeFi) ecosystem and the creation of various utility and governance tokens.

Difference between ERC-20 tokens and native cryptocurrencies

ERC-20 tokens are built on existing blockchain platforms as smart contracts within the blockchain, utilizing its infrastructure and security features while native cryptocurrencies are the primary currency of a specific blockchain platform, part of the blockchain’s protocol, and are not built on top of another platform.

ERC-20 tokens are created to serve various purposes and use cases, such as fundraising, utility within a specific platform, governance, or even representing real-world assets while native cryptocurrencies primarily serve as a medium of exchange within their blockchain and are used for paying transactions fees, incentivizing network participants (e.g., miners or validators), and as a store of value.

ERC-20 tokens adhere to a specific set of rules and standards that ensures interoperability among different tokens, meaning they can be easily integrated into various wallets, exchanges, and decentralized applications (dApps). Native cryptocurrencies have their unique protocols and rules specific to their blockchain and are generally not interchangeable with each other without additional layers of cross-chain technology.

In summary, ERC-20 tokens are tokens built on top of an existing blockchain platform (like Ethereum) and can have various use cases, while native cryptocurrencies are the primary digital assets of their respective blockchains and are used primarily for value transfer and network operations.

Usecase for ERC-20 tokens for projects

ERC-20 tokens are very useful and flexible, offering projects endless possibilities for development.

ERC-20 tokens have become the standard choice for fundraising. Startups and projects can create their own ERC-20 tokens and sell them to investors in exchange for native currency.

Many projects create ERC-20 tokens as utility tokens, which can be used within their platform or ecosystem to access services, products, or specific functionalities. These tokens act as digital assets providing incentives for users to participate in the platform.

ERC-20 tokens can be used as governance tokens, giving holders the right to vote on decisions within a decentralized platform or organization. These tokens enable community involvement in the project’s development.

ERC-20 tokens have become the backbone of the DeFi ecosystem. They are used as collateral, liquidity providers, lending assets, and governance tokens in various DeFi protocols and platforms.

Businesses can create ERC-20 tokens to reward users for their engagement, loyalty, or specific actions within their platforms. These tokens act as a digital representation of value that users can accumulate and redeem for various benefits.

Overall, ERC-20 tokens offer a versatile and efficient way for projects to raise funds, create utility, and engage with their communities, making them a popular choice for a wide range of use cases within the blockchain space.

Token-as-a-Service on OpenDApps Cloud

Introduction

The purpose of OpenDApps Cloud is to offer developers and project owners the necessary resources for deploying and utilizing smart contracts on the blockchain without the need to manually write or deploy code.

Our concept for software-as-a-service on the blockchain is based on this approach, and OpenDApps Cloud offers a Token-as-a-Service deployer as one of its main solutions. This deployer allows clients to easily create, manage, and extend ERC-20-based tokens directly from the OpenDApps Cloud UI, without the need for coding or manually calling smart contracts.

When tokens are deployed through OpenDApps Cloud deployer, they can utilize fully dynamic tokenomics to manage taxes for both buying and selling on any DEX, as well as transfers between holders. For advanced tokens, inflation is also an option with a maximum supply minted over customized periods and distribute rewards in a fully customizable manner.

On top of the general management of tokens, OpenDApps Cloud offers extensions for deployed tokens in the form of services like staking, dApp-as-a-Service, baseline price insurance, and more.

Tokenomics

ERC-20 tokenomics involve the automatic distribution of collected taxes from transfers. Tokens typically have a 1–10% buy/sell tax for various utilities like marketing, development, automatic burn, or charity. Usually, tokenomics are static and allow for a % calibration but not utility distribution changes.

On OpenDApps Cloud, tokens can customize their tokenomics through the user interface. There are two levels of complexity available: basic and advanced tax tokenomics. The basic level enables tokens to have a single buy/sell tax ranging from 1% to 10% for all DEX listings. The advanced level offers individual configurations for buy, sell, and transfer taxes, each with its distributions.

No matter the level or tax configuration selected, there are various options for distributing any unused tax amounts from tokenomics. These include:

1. Automatic burn: Tokenomics can be set up to burn a percentage of collected taxes, which can reduce the total token supply. This can make a token deflationary if there is a high volume.

2. Add to DEX liquidity: Tokenomics can be configured to add a percentage of collected taxes to existing liquidity on a DEX. This is a great option for projects looking to strengthen their liquidity on a specific DEX.

3. Provide staking rewards: If the token has a staking service deployed on OpenDApps Cloud, tokenomics can be set up to provide a percentage of collected taxes to the staking rewards pool. This option is perfect for projects aiming to reward long-term holders.

4. Transfer to a wallet/contract: Any percentage of taxes collected through tokenomics can be transferred to a designated wallet or contract. This allows for funding development or marketing wallets, as well as providing tokens to any contract with custom functionality created by the project.

The great thing about OpenDApps Cloud is that you can change those tokenomics at any time allowing projects to evolve over time without the need for migrating to a new token and smart contract.

An in-depth overview and how-to-use tokenomics for tokens will be available in a separate post:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/SV2_VxkSbf4nwNtR-XI3aKQPOOKMa8HBKKxAtp01Vwo

Inflation

In the blockchain space, inflation is a concept mostly known to exist in native cryptocurrencies and rarely in ERC-20 tokens. The reason for that might be that there is no standard or common practice when it comes to programmable inflation on top of ERC-20 tokens and if the inflation is long-term, bugs and issues might not arise until much later.

The Token-as-a-Service solutions from OpenDApps Cloud provide an option for projects to enable inflation for their tokens on deployment and later on fully customize rewards distribution. OpenDApps Cloud UI makes it easier to manage inflation without having to write complex minting algorithms and rewards distribution.

Rewards minting and distribution are fully automatic over a configured block distance with a max supply that cannot be changed once the token is deployed ensuring holders that no more tokens than expected will be minted.

Rewards distribution is fully customizable at any time and supports all the configurations available to tokenomics like auto-burn, staking rewards, and distribution to wallets and contracts.

An in-depth overview and how-to-use inflation for tokens will be available in a separate post:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/wQM3c35XKukDZivfE6NJD8nRXNfOdFpdr_40xAVgbOI

Additional Services

OpenDApps Cloud aims to provide fully extendable and customizable products to our clients who can use additional services to shape and extend their projects based on ERC-20 tokens. Some of the additional services available include:

Staking-as-a-ServiceTokens deployed using OpenDApps Cloud have access to the staking service. After deployment staking can be configured for the token to provide rewards from different sources like tokenomics, inflation, revenue streams, or manual top-ups. Those rewards are then distributed to holders using the staking from the project dApp on configurable time periods and amounts.

More about staking service can be found in the dedicated post about Staking-as-a-Service: TBD

dApps-as-a-ServiceTokens deployed using OpenDApps Cloud can use our subscription-based service for providing a dApp for the token containing all the information available on-chain for the token as well as giving access to all the additional services available for the token like dex swaps, staking, asset backing, etc.

More about the dApp service can be found in the dedicated post about dApp-as-a-Service: TBD

Baseline price insuranceBaseline Price Insurance is a service designed to provide an asset-backed baseline price for a token independent of its market price. The asset-backing ensures that the baseline price can only increase and tokens can be exchanged for part of the asset-backing at any time.

More about the asset backing service can be found in the dedicated post:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/6fD0XesiGF0VqwJOGFfYbja8E4L5HFrNUBfm-8f0CQE

In-depth guides on available services and other SaaS-related information resources are available in this blog and any related content will be linked here:

1. OpenDApps Cloud — Testnet Connection and Testing Guide

2. Guide: How to deploy ERC-20 Tokens using OpenDApps Cloud

3. Tokenomics on OpenDApps Cloud — An Overview & Guide

4. Inflationary Tokens on OpenDApps Cloud — An Overview & Guide

5. Baseline Price Insurance Service for Tokens on OpenDApps Cloud — An Overview

6. Decentralized Companies in OpenDApps Cloud — An Overview

7. More….

Table of contents

1. Introduction

2. What is Asset Backing?

3. Baseline Price Insurance Service on OpenDApps Cloud3.1 Introduction3.2 How it works3.3 Baseline Price vs Market Price3.4 The Math

4. Deployment on OpenDApps Cloud [TBD]

5. Backing Management on OpenDApps Cloud [TBD]

Introduction

In this blog post, we will do a quick overview of asset backing and how it is used to create the baseline price insurance service on OpenDApps Cloud.

We will examine the service, revealing how it works on the blockchain. We will compare the baseline price to the market price, and how it creates arbitrage possibilities. We will also go deeper into the math behind baseline price and how it can only increase over time.

What is Asset Backing?

In traditional finance, asset-backed securities refer to securities with value deriving from a single asset or a pool of assets which act as collateral for the security — “backing” it. When that total value of assets is divided by the total issues of security we get the baseline price for it that is “backed” by the assets. These assets are often illiquid and the security cannot be directly exchanged for them but the value of the assets secures the price of the security in case of company liquidation.

In decentralized finance, asset backing is most often associated with tokens. In most instances, asset backing is implemented using a smart contract that holds one or more assets that act as collateral for the token. As a result, the token can be exchanged for part of the assets which creates a baseline price equal to the total value of the assets divided by the total supply of a token.

The price created from asset backing is called baseline price in most of DeFi and it is different from the market price of a token. The market price of a token comes from DEX and CEX listings, while the baseline price is only defined from the assets held by the contract and it is only available through it.

Baseline Price Insurance Service on OpenDApps Cloud

IntroductionBaseline Price Insurance is a service designed to provide an asset-backed baseline price for a token independent of its market price. The asset-backing ensures that the baseline price can only increase and tokens can be exchanged for part of the asset-backing at any time.

How it worksTokens deployed using OpenDApps Cloud have access to additional services tied to their token. Such services are token staking, second-layer swaps, and baseline price insurance.

The service uses a fully-configurable array of assets to ensure the baseline price through asset backing. Clients can customize the assets used with support for ERC20 tokens and native cryptocurrencies. Additional assets for the asset-backing smart contract can be added manually or configured through tokenomics, inflation, or integrated parts of the OpenDApps ecosystem.

The service smart contract keeps track of available assets and provides a real-time baseline price based on circulation supply. The baseline price increases when one of two things happens: circulation supply decreases (token burn) or additional assets are added to the underlying contract.

To use the service, clients use our dApp to deploy a non-upgradeable contract with minimal public interface and no backdoors or direct asset manipulations. Once deployed, token holders of the client project can swap their tokens for the baseline price at any time.

Baseline Price vs Market PriceThe market price of a token is the value of a single token traded on a decentralized (DEX) or a centralized exchange (CEX).

On a DEX the price of an asset is determined by the interaction of buyers and sellers within the exchange’s automated market-making mechanism. The DEX smart contract calculates the new asset ratio based on the pool’s existing reserves and the amount being traded. If a token is published with a blockchain native token as a pair for the liquidity pool, the token price will be tied up to the native token price!

In a centralized exchange (CEX), the price of a cryptocurrency is typically determined by the forces of supply and demand in the market. CEXs provide a platform where buyers and sellers can place orders to buy or sell cryptocurrencies, and the prices are determined through the matching of these orders.

The baseline price of a token supporting asset backing is determined by the value of underlying assets held by the backing smart contract divided by the circulating supply of the token. Any % of the supply of tokens traded to the smart contract will be exchanged for the same % of the backing assets. This mechanism ensures that the ratio between collateral assets and circulating supply remains the same at all times.

Any exchanges of tokens on a DEX or a CEX do not have any direct impact on the baseline price unless they change the circulating supply of the token (eg. burn). If any burn occurs on trades the baseline price increases as well because the ratio between collateral assets and circulating supply increases as well.

Any exchanges of tokens for baseline price do not affect the market price. However, if the market price gets lower than the baseline price, an arbitrage opportunity occurs where people can buy tokens from the DEX (as an example) and exchange them for assets from asset-backing. This arbitrage trade can be executed until the market price with fees is greater or equal to the baseline price.

The Math

In this chapter, we will take a look at the math behind the baseline price and how it can ensure a stable $ value for a token when the price of the native currency falls rapidly and how arbitrage trading has no effect on the baseline price.Be warned that this can get geeky very quickly! Continue reading this part with caution!

For this example, we will use DFI on DMC Testnet and a test token asset-backed using a $ pegged coin.First, we give some initial variable and function names:

After that, we define the DEX price of a token, the baseline price from the price insurance service, and delta P measuring the arbitrage possibility between the two prices:

From here we can define the prices for our test token measured in tDFI and tUSD, as well as the delta P:

As we can see when the market price in tUSD is lower than the baseline price there is an arbitrage opportunity. Let’s calculate the size of the swap required to increase the market price back up close to the baseline price. Here we will find N — the amount of OPENDT that has to be bought in a swap to increase market price close to baseline price (delta P close to 1):

Now when we can define the size of the swap required for arbitrage to bring the market price to the baseline price in tUSD we can show how the arbitrage trading cannot decrease the baseline price even if all tokens on the DEX are exchanged for assets.

First, we show that if the DFI price is measured in tUSD heads toward 0, the market price of OPENDT measured in tUSD hands toward 0 as well:

Now we can show that if the market price of OPENDT measured in tUSD hands toward 0, delta P heads toward 0 opening arbitrage opportunity between the market and baseline price:

And finally, we can show that if delta P heads towards 0 (“endless” arbitrage), the arbitrage trades are limited to the supply of the token on the DEX, reserving the remaining assets for the rest of the circulating supply and preserving the baseline price:

Congratulations if you made it this far in the math train.Cheers to you! Let’s move on to the good stuff.

Deployment on OpenDApps Cloud [TBD]

Backing Management on OpenDApps Cloud [TBD]

In-depth guides on all available services and other SaaS-related information resources will be available later on in this blog and any related content will be linked here:

1. OpenDApps Cloud — Testnet Connection and Testing Guide

2. Token-as-a-Service on OpenDApps Cloud — An Overview

3. Guide: How to deploy ERC-20 Tokens using OpenDApps Cloud

4. Tokenomics on OpenDApps Cloud — An Overview & Guide

5. Inflationary Tokens on OpenDApps Cloud — An Overview & Guide

6. Decentralized Companies in OpenDApps Cloud — An Overview

7. More….

Table of content

1. Introduction

2. The concept of multi-sign decentralized companies
   2.1 Basics of decentralized companies
   2.2 On-chain governance proposal system
   2.3 Multi-sign voting system

3. The concept of hierarchical multi-sign decentralized companies
   3.1 Introduction
   3.2 Roles in a hierarchical multi-sign company
   3.3 Hierarchy-based voting power

4. Deployment on OpenDApps Cloud

5. On-chain Governance on OpenDApps Cloud

6. Team management on OpenDApps Cloud

Introduction

In this blog post, we dive deep into the concept of hierarchical multi-sign companies, what is their purpose, and how to manage one using the OpenDApps Cloud.

Hierarchical multi-sign companies are one of the three main types of decentralized companies introduced by OpenDApps Cloud. You should read our quick overview of decentralized companies if you have not already:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/2BTqt_DirC5J5G1HzZk2K8Eyqb2burBIHUxwUNh3Rfs

If you want to read more about other types of decentralized companies you can find the links to our guides at the bottom of this blog post.

Let’s start.

The concept of multi-sign decentralized companies

We have already covered the concept of decentralized companies in our guide to share-based multi-sign companies. Here we will publish a shorter version so we do not repeat the same content. If you are interested in a more in-depth overview of the concept for multi-sign decentralized companies check out our guide here:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/6kSsWQcsTm-qvFGIn_YnxqgLOp46QZPAJyFARA-e8UQ

Basics of decentralized companies

Decentralized companies on OpenDApps are smart contracts deployed on EVM-compatible blockchains that represent an entity. The team can execute transactions through the contract allowing for it to own assets, execute transfers, call other contracts, and much more.

Decentralized entities on OpenDApps are really powerful and can create complex structures of organizations.

On-chain governance proposal system

On-chain governance relies on the blockchain itself to facilitate decision-making and enforce rules. It brings transparency, immutability, and decentralized control directly to the governance mechanism.

The fundamental idea is to use smart contracts that allow stakeholders/shareholders to propose, discuss, and vote on the execution of transactions on the blockchain.

On OpenDApps Cloud multi-sign decentralized companies use a proposal system to realize on-chain governance.

Multi-sign voting system

After the proposal is submitted to the blockchain, other stakeholders can vote to support the execution of the proposal or skip voting if they are against it. If a proposal meets the criteria for being approved, any stakeholder can then execute the pending transactions and the proposal will be marked as finished.

When the proposal is executed, all pending transactions will be executed as well as making all the changes submitted in the proposal. After executing the proposal is no longer available for voting and if a reversal of changes is needed it is required to make a new proposal.

The concept of hierarchical multi-sign decentralized companies

Introduction

Hierarchical multi-sign companies are smart contracts owned by a team divided into multiple groups with different levels of voting power. The smart contract requires transaction signatures from a predefined % of each hierarchy level and a predefined % of total signatures (total = sum of all signers on all levels).

Hierarchical multi-sign companies are meant for entities where approval from a small group of members, like an executive board, is crucial for a decision to be executed. At the same time, overall approval from the whole team is required.

Roles in a hierarchical multi-sign company

Hierarchical multi-sign companies on OpenDApps Cloud support two main roles — Root signers and Leaf signers.

Root signer role is meant for the higher management positions in a company like an executive board or a group of owners/founders. Their vote is part of the high-tier approval, exclusive to the root signer role, as well as being a part of the overall approval for proposals.

The leaf signer role is meant for the rest of the management and/or team members who are part of the decision-making in the organization. Their vote is part only of the overall approval of proposals.

On OpenDApps Cloud hierarchical multi-sign companies have unlimited root and leaf signers but with a minimum of one root signer to operate.

Hierarchy-based voting power

The hierarchical structure described allows root signers to veto decisions if they do not sign an approval for it to be executed in the high-tier approval. For a proposal to be approved and executed ALL root signers have to approve it.

A large group of leaf signers can also stop a proposal if they do not sign the execution bringing overall approval below the required threshold. For a proposal to be executed 50%(100% on Testnet) of the total signers have to sign and approval. (total = leaf + root count)

Caution should be executed when promoting root signers because their signature is required for every proposal.
ONLY promote trusted and highly available members to the root signer role!

Deployment on OpenDApps Cloud

The deployment of companies through OpenDApps Cloud is the same for all types of companies with the only difference being the ownership type.

First, prepare your setup and connect to OpenDApps Cloud dApp. For this guide, we will use Testnet dApp on DeFiChain MetaChain Testnet. Instructions on how to prepare your setup and how to connect to our dApp can be found in our guide:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/UKO8kgnS8bELkxTr1mvLmfUeujFHL14nQUEFhJuk4-o

After connecting to OpenDApps Cloud dApp we will see the dashboard. From there, we have to click the “Create Company” button to start our deployment:

This opens up the “Create New Company” from where we will see a 3-step wizard for the deployment of our decentralized company smart contract:

The first thing is to create and sign the NFT metadata for the company. Just fill in a name for the company, select a logo, and click the “Sign Metadata” button.

When we click on Sign Metadata, our wallet will ask us to create a signature using the eth_signTypedData_v4 method. You can read more about signature types in wallets here: Click me!
In MetaMask it should look like this in the wallet UI:

Once the signature is complete the wizard will move to step 2 and we can mint the metadata before deploying the company. We click on the “Mint Metadata” button:

After the successful upload of the metadata, we can deploy the company on the blockchain. We select “Hierarchical Multi-Sign Contract” as an ownership type and click the “Create Company” button:

If we have deployed other companies we will have to select who will be the initial root signer for the company from the “Select Executor of Transaction”. We will not create a multi-level company and for that, we select “Connected Wallet”:

After the selection of the initial owner, we will see the transaction for deployment in our wallet. In MetaMask execution will look like this:

After confirmation of the transaction and its successful execution, we will be presented with a message for success and buttons to return to the dashboard or to check the transaction in a block explorer.

If we want to check out our company on the dashboard we can use the “Go to dashboard” button. After the deployment of companies, the dApp requires the new blocks to be indexed before the company is visible. If the process is still ongoing you will see a message on your dashboard.

Once the blocks are indexed we can refresh our dashboard and the newly deployed company will be there.

Congratulations! You deployed your first hierarchical multi-sign company! Read the rest of the guide to learn how to manage it through governance.

Оn-chain Governance on OpenDApps Cloud

On-chain governance for hierarchical multi-sign companies is through the proposal system. Proposals are made up of multiple transactions that can be added to the proposal through the usage of our platform.
For example, we will create a proposal for the creation of a token.

Let’s start creating a token by clicking the “Create Token” button on the dashboard:

We will be greeted with a form to fill up and create the token. If we want the token to be owned by our company we will select our shares-based multi-sign company from the owner menu:

We will fill out the rest of the form and get to the last step of the deployment process for the token.
A more in-depth guide for the deployment of tokens can be found in our blog post: TBD
We click the “Create Token” button to finish the deployment process:

As we can see any action we take on OpenDApps Cloud dApp as a multi-sign organization will result in a transaction being added to our draft proposal. From here we can click continue and add additional transactions to our draft proposal like management of tokenomics, managing our treasury, etc. Once we are ready with our draft we can take a look at its state from the “Open draft” button or the menu on our dashboard:

When we visit our proposal we can inspect all the transactions which will be part of it and when we are ready we can publish the proposal to the on-chain governance for voting using the “Publish Proposal” Button:

We will be prompted by our wallet to execute the transaction for publishing the proposal for on-chain voting. In MetaMask this looks like this:

Once the transaction is successful we can go to the list of proposals using two main methods. We can click the “View list of proposals” button after successfully publishing one or by using the menu on our dashboard:

After publishing the proposal we will have to wait for the indexing process to complete before we will have access to our proposal in OpenDApps Cloud dApp:

Once the indexing is complete we can reload the data and we will see our new proposal at the top of the list. The list contains all the proposals from the past and their results:

To place our vote on a proposal we can click the button “Vote for proposal” and a form will open with information about the proposal:

Here we can see all the transactions (method calls), the voting time available and what current approval is. As we can see for our hierarchical multi-sign proposals, an approval of 100% is required from Root Signers, and a 50% total approval (100% on Testnet) is required for execution.

In the example company, we are the only signer, and if we want to vote with support of the proposal we can click the “Vote to Support Proposal” button. This will open up a transaction execution dialog in our wallet. In MetaMast this will look like this:

After the successful execution of the transaction, our vote will be counted for approval on the chain. Background indexing will be required to show our wallet in the voters’ list but the support for approval will be updated immediately allowing execution if the proposal has a total approval > 50% (100% on Testnet) and 100% approval from Root Signers:

To execute an already approved proposal we can click the green “Execute Proposal” button and confirm the transaction in our wallet.

After the successful execution of the proposal, it will no longer be available for voting and it will only be accessible in view-only mode for people to see the results and the transactions executed with it:

Everything you want to do in the name of a hierarchical company has to be done with the on-chain proposal governance system.

Congratulations! You successfully created, published, and executed an on-chain governance proposal.

Team management on OpenDApps Cloud.

The hierarchical multi-sign company team is managed through OpenDapps Cloud dApp. To access the team management control you need to go to the dashboard, find your company, and from the menu select “Add/Remove voters”:

After that, we will be redirected to the team management page where we can see the list of root and leaf signers:

From here we can promote and demote signers. Every change to the list of signers will have to be published as a proposal using the on-chain governance. After the successful execution of such a proposal, the list of signers will change and for the next proposal, the new signers will have to participate.

In-depth guides on all available services and other SaaS-related information resources will be available later on in this blog and any related content will be linked here:

1. OpenDApps Cloud — Testnet Connection and Testing Guide

2. Decentralized Companies in OpenDApps Cloud — An Overview

3. Single Entity Decentralized Companies Overview (TBD)

4. Guide to Shares-based Multi-Sign Decentralized Companies on OpenDApps Cloud

5. Token-as-a-Service Overview (TBD)

6. More….

Table of contents

• Introduction

• The concept of multi-sign decentralized companies

  • Basics of decentralized companies

  • On-chain governance proposal system

  • Multi-sign voting system

• The concept of shares-based multi-sign decentralized companies

  • Introduction

  • Company shares as ERC1155 NFTs

  • Shares-based voting power

• Deployment on OpenDApps Cloud

• On-chain Governance on OpenDApps Cloud

• Company shares ownership transfer

  • Transfer shares directly from OpenDApps Cloud

  • Transfer shares via NFTs transfer

  • Sell/Buy Shares on NFT Marketplaces

Introduction

In this blog post, we dive deep into the concept of shares-based multi-sign Companies, what are they meant to do, and how to deploy one using the OpenDApps Cloud dApp.

Shares-based multi-sign decentralized companies are one of the three main types of decentralized companies supported by OpenDApps Cloud. If you want to read a quick overview of the idea behind decentralized companies, please read our blog post here:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/2BTqt_DirC5J5G1HzZk2K8Eyqb2burBIHUxwUNh3Rfs

If you are interested in an in-depth guide for one of the other types of decentralized companies you can find the links to our other guides at the bottom of this blog post.

Let’s dive in.

The concept of multi-sign decentralized companies

Basics of decentralized companies

Decentralized companies on OpenDApps are smart contracts deployed on EVM-compatible blockchain that represent the organization as a blockchain entity. The smart contract can be managed by a team of select ownership types and owners can execute transactions through the contract allowing for it to own assets, execute transfers, call functions of other contracts, and much more.

Decentralized companies on OpenDApps are really powerful and can create structures not accessible to developers and organizations using simple DAOs. OpenDApps Cloud provides customers with three main options or ownership of deployed decentralized companies.

On-chain governance proposal system

In the realm of blockchain technology, governance refers to the process of making decisions and implementing changes to a blockchain network, managing a decentralized protocol, or executing company transfers and transactions.

On-chain governance is a specific approach to decentralized governance that relies on the blockchain itself to facilitate decision-making and enforce rules. On-chain governance brings transparency, immutability, and decentralized control directly to the governance mechanism.

The fundamental idea behind on-chain governance is to use smart contracts or protocol-level mechanisms to enable stakeholders/shareholders to propose, discuss, and vote on the execution of transactions on the blockchain.

On OpenDApps Cloud decentralized companies use on-chain governance to execute company operations. Multi-sign companies use a proposal system to realize on-chain governance where any stakeholder can propose with consists of one or more transactions to be executed.

Multi-sign voting system

After the proposal is submitted to the blockchain, other stakeholders can vote to support the execution of the proposal or skip voting if they are against it. If a proposal meets the criteria for being approved, any stakeholder can then execute the pending transactions and the proposal will be marked as finished.

When the proposal is executed, all pending transactions will be executed as well as making all the changes submitted in the proposal. After executing the proposal is no longer available for voting and if a reversal of changes is needed it is required to make a new proposal.

The concept of shares-based multi-sign decentralized companies

Introduction

Shares-based multi-sign companies are smart contracts owned by multiple entities that require transaction signatures from multiple owners to execute transactions.

Shares-based multi-sign companies are created to mimic the real-world private companies where ownership is split into stakeholders owning different % of the company. On OpenDApps Cloud shares-based companies have a total of 1000 shares that can be split between different entities — wallets or other companies.

Any owner of shares has the right to propose, vote on and execute approved proposals in the name of the company through the contract.

Company shares as ERC1155 NFTs

The ownership shares for the shares-based company contract and thus for the company are represented by an NFT, part of an ERC1155 NFT Collection by OpenDApps Ownership Infrastructure.

The NFT shares are fully compatible with the ERC1155 standard making them very flexible for transferring ownership. The shares can be transferred, sold on marketplaces, and auctioned as any other NFT.

In the future, there should be a place for people to trade company shares in a decentralized marketplace specializing in decentralized companies.

An example of such NFT collection with NFTs for company ownership can be seen on DeFiChain MetaChain Testnet:

Shares-based voting power

For shares-based companies, proposals need to have 50% + 1 approval from stakeholders. Every share counts as one vote and the total available shares in a shares-based multi-sign company are 1000. This means that stakeholders holding a total of more than 500 shares have to approve the proposal before it can be executed.

Deployment on OpenDApps Cloud

The deployment of decentralized companies through OpenDApps Cloud is the same for all types of companies with the only difference in the ownership type selection.

First, we need to prepare our setup and connect to OpenDApps Cloud dApp. For this example, we will use Testnets dApp and DeFiChain MetaChain Testnet. You can find instructions on how to prepare your setup and how to connect to our dApp from our guide:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/UKO8kgnS8bELkxTr1mvLmfUeujFHL14nQUEFhJuk4-o

After we have connected to OpenDApps Cloud dApp we will see our dashboard. From there, we have to click the “Create Company” button to start our deployment:

This opens up the “Create New Company” from where we will see a 3-step wizard for the deployment of our decentralized company smart contract:

The first thing we have to do is to create and sign our NFT metadata for the minting of the ownership shares. We do that by filling in a name for our company, selecting a logo, and clicking the “Sign Metadata” button.

When we click on Sign Metadata, our wallet will ask us to create a signature for the metadata using the eth_signTypedData_v4 method. You can read more about signature types in wallets here: Click me!We are using MetaMask for this guide and the signature looks like this in the wallet UI:

Once we sign the metadata the wizard will move to step 2 where we can mint the metadata for our company before we deploy it. We can do that by clicking the “Mint Metadata” button to upload it to IPFS:

After the successful upload of the metadata to IPFS, the only thing left to do is to deploy the company on the blockchain. For that we need to select a company ownership type for this guide we will select “NFT shares Multi-Sign Contract” and click the “Create Company” button which will deploy a shares-based multi-sign company for us:

If we have already deployed other companies we will have to select who will be the initial owner of the company from the “Select Executor of Transaction”. For this guide, we will not create multi-level companies and will select “Connected Wallet” and click “Confirm”:

After the selection of the initial owner, we will see the transaction for deployment in our wallet. In MetaMask execution will look like this:

After confirmation of the transaction and its successful execution, we will be presented with a message for success and buttons to return to the dashboard or to check the transaction in a block explorer.

If we want to check out our company on the dashboard we can use the “Go to dashboard” button. After the deployment of companies, the dApp requires the new blocks to be indexed before the company is visible. If the process is still ongoing you will see a message on your dashboard.

Once the blocks are indexed we can refresh our dashboard and the newly deployed company will be there.

Congratulations! You deployed your first shares-based multi-sign company! Read the rest of the guide to learn how to manage it through governance and how you can transfer shares to new stakeholders.

Оn-chain Governance on OpenDApps Cloud

On-chain governance for shares-based multi-sign companies is through the proposal system. Proposals are made up of multiple transactions that can be added to the proposal through the usage of our platform.For example, we will create a proposal for the creation of a token, and then we will create another to make some changes to the tokenomics of the token.

Let’s start creating a token by clicking the “Create Token” button on the dashboard:

We will be greeted with a form to fill up and create the token. If we want the token to be owned by our company we will select our shares-based multi-sign company from the owner menu:

We will fill out the rest of the form and get to the last step of the deployment process for the token. A more in-depth guide for the deployment of tokens can be found in our blog post: TBDWe click the “Create Token” button to finish the deployment process. Usually, if we are deploying the token with our wallet instead of a multi-sign we will be prompted from our wallet to confirm the transaction. But because we are using a multi-sign company we will see a success message telling us that the transaction has been added to our draft for a proposal:

As we can see any action we take on OpenDApps Cloud dApp as a multi-sign organization will result in a transaction being added to our draft proposal. From here we can click continue and add additional transactions to our draft proposal like management of tokenomics, managing our treasury, etc. Once we are ready with our draft we can take a look at its state from the “Open draft” button or the menu on our dashboard:

When we visit our proposal we can inspect all the transactions which will be part of it and when we are ready we can publish the proposal to the on-chain governance for voting using the “Publish Proposal” Button:

We will be prompted by our wallet to execute the transaction for publishing the proposal for on-chain voting. In MetaMask this looks like this:

Once the transaction is successful we will see a successful message and an option to view the list of proposals for the company. We can go to the list of proposals using two main methods. We can click the “View list of proposals” button after successfully publishing one or by using the menu on our dashboard:

After publishing the proposal we will have to wait for the indexing process to complete before we will have access to our proposal in OpenDApps Cloud dApp:

Once the indexing is complete we can reload the data and we will see our new proposal at the top of the list. The list contains all the proposals from the past and their results:

To place our vote on a proposal we can click the button “Vote for proposal” and a form will open with information about the proposal:

Here we can see all the transactions (method calls), the voting time available and what current support is. As we can see for shares-based multi-sign proposals a approval of 50.1% is required. To vote for approval of the proposal we can click the “Vote to Support Proposal” button. This will open up a transaction execution dialog in our wallet. In MetaMast this will look like this:

After the successful execution of the transaction, our vote will be counted for approval on the chain. Background indexing will be required to show our wallet in the voters’ list but the support for approval will be updated immediately allowing execution if the proposal has an approval > 50.1%:

To execute an already approved proposal we can click the green “Execute Proposal” button and confirm the transaction in our wallet:

After the successful execution of the proposal, it will no longer be available for voting and it will only be accessible in view-only mode for people to see the results and the transactions executed with it:

Everything you want to do in the name of a shares-based company has to be done with the on-chain proposal governance system.

Congratulations! You successfully created, published, and executed an on-chain governance proposal.

Company shares ownership transfer

Shares-based multi-sign company ownership is really flexible due to the ERC1155 implementation of the shares structure. Transfer of ownership can be achieved with any NFT transfer available on the market as well as using OpenDApps Cloud dApp.

When a shares-based company is created all the 1000 shares are transferred to the deployer and from there they can be transferred with any preferred method.

Transfer shares directly from OpenDApps Cloud

One simple way to directly transfer shares is with the OpenDApps Cloud Transfer ownership instrument. To access it you must select the “Transfer Shares” option from the company management menu:

This will open up a page showing us the current shareholders, their stakes, and the option to transfer our shares. To transfer shares to another wallet or company we can click the “Transfer Shares” button.

This will open up a dialog where we can input to whom we wanna transfer shares and how much from our current holding we want to transfer. If we are doing this operation as a company owner of that shares we will see the amount of shares owned by the company. For this guide, we will send 250 shares [25%] to a random community member on DeFiChain MetaChain Testnet.

Once we are ready with our input we can confirm the dialog and a transaction window will show in our wallet if we are executing it as a single entity or the transaction will be added to our draft proposal if we are executing it as a multi-sign company.

After a successful transfer, background indexing will be required for us to see the new list of stakeholders.

After the indexing is finished we will see the new list with all shareholders.

Transfer shares via NFTs transfer

Another way to transfer shares is through an NFT transfer directly from your wallet if it supports ERC1155 collections. For this to work you need to add the NFT collection containing the NFTs for your company. For DeFiChain MetaChain Testnet the NFT collection address is: 0xd403A282F7D4FeB117Ba1664E307BE9Bb94d0467

We can add the collection in MetaMask to see our shares as part of our wallet.

After we add the collection we can transfer the NFTs directly to another wallet or company. Just keep in mind that every NFT is worth 0.1% of the ownership stake at the company. For this guide, we will transfer shares to a random community member on DMC Testnet.

Sell/Buy Shares on NFT Marketplaces

Shares for companies can also be sold or bought on any NFT marketplace on the selected blockchain. Such marketplaces include OpenSea, Rarible, and others. You just have to publish an offer or a listing for the NFT and others can buy or sell you shares.

In the future, we plan on launching a dedicated NFT marketplace for company shares to give investors a place to find good deals on decentralized companies.

In-depth guides on all available services and other SaaS-related information resources will be available later on in this blog and any related content will be linked here:

1. OpenDApps Cloud — Testnet Connection and Testing Guide

2. Decentralized Companies in OpenDApps Cloud — An Overview

3. Single Entity Decentralized Companies Overview (TBD)

4. Guide to Hierarchical Multi-Sign Decentralized Companies on OpenDApps Cloud

5. Token-as-a-Service Overview (TBD)

6. More….

Table of contents

1. Introduction

2. Why do we need Decentralized Companies?

3. Decentralized Autonomous Organizations (DAO)

4. Why do we need Private Decentralized Companies?

5. Private Decentralized Companies on OpenDApps Cloud 5.1 Companies owned by a single entity 5.2 Multi-sign hierarchical company 5.3 Multi-sign shares-based company

Introduction

In this blog post, we explore the fascinating realm of decentralized companies and the impact they are having on the crypto space as well as on real-world business.

We will overview the principles, advantages, and real-world applications of these entities, showing how they can help projects and businesses leverage blockchain transparency and stability.

We’ll go through the concept of decentralized autonomous organizations (DAOs), multi-sign smart contracts, and more while highlighting the benefits they offer in terms of transparency and efficiency. We will also look at new concepts for decentralized companies introduced by OpenDApps Cloud and how private companies can now take advantage of decentralized organizations.

Why do we need Decentralized Companies?

Decentralized companies are innovative organizational structures, empowered by blockchain technology, paving the way for the next big step in organization ownership and trust.

Through the use of blockchain technology, decentralized organizations can provide an immutable and auditable record of transactions, operations, and decision-making processes. This transparency builds trust among participants, as they can verify and validate the actions and intentions of the company.

Decentralized companies cut out intermediaries, reducing costs and increasing efficiency. This saves time and resources but also enables faster and more secure transactions, ultimately benefiting both the company and its customers.

Traditional barriers to entry, such as geographical limitations or institutional biases, are diminished in decentralized ecosystems. Anyone with an internet connection can participate, contribute, and reap the rewards of these organizations, regardless of their background or location.

In conclusion, decentralized companies are a necessity for building a more transparent and resilient future. These organizations offer an alternative paradigm that unlocks unlimited potential for innovation, collaboration, and positive change.

Decentralized Autonomous Organizations (DAO)

A DAO, short for Decentralized Autonomous Organization, is a type of organization that operates based on smart contracts aiming to eliminate the need for traditional hierarchical structures and centralized control.

In a DAO, decision-making and governance processes are automated and executed through self-executing code often referred to as smart contracts. It defines the rules and protocols that govern the organization’s operations.

DAOs are designed to be decentralized, meaning decision-making power is distributed among the participants or token holders within the organization. All transactions, proposals, and voting outcomes are recorded on the blockchain and are publicly accessible, ensuring accountability and trust.

DAOs can be utilized for a wide range of purposes, such as decentralized finance (DeFi), governance of blockchain protocols, collective decision-making, and community-driven initiatives.

Why do we need Private Decentralized Companies?

While DAOs provide a very good structure for most decentralized organizations, the ownership is usually limited to distributed governance tokens. This model is close to real-world public companies in a way that everybody who buys these tokens take part in the organization’s decision-making.

Public governance can be very limiting for organizations that want to be decentralized and leverage blockchain technology but have private ownership. This gap between real-world private organizations and DAOs is where private decentralized companies can help more organizations enter the blockchain space.

Private decentralized companies can allow the same level of transparency, security of decision-making, and resilience to censorship as DAOs but at the same time provide the option for private and/or multi-level ownership.

Private Decentralized Companies on OpenDApps Cloud

Private decentralized companies are a new concept that OpenDApps Cloud brings into the blockchain space to help fill the gap between a real-world private company and DAOs.

Decentralized companies on OpenDApps are smart contracts deployed on EVM-compatible blockchain that represent the organization as a blockchain entity. That smart contract can then be managed by the team of select ownership type and owners can execute transactions through the contract allowing for it to own assets, other contracts, and much more.

The concept of private decentralized companies is a powerful tool for organizing and managing a business on the blockchain. It even allows multi-level companies to exist because every decentralized company represented by a smart contract can own other companies.

Here is an example multi-level company structure of OpenDApps Cloud:

Decentralized companies on OpenDApps are really powerful and can create structures not accessible to developers and organizations using simple DAOs. OpenDApps Cloud provides customers with three main options or ownership of deployed decentralized companies.

Companies owned by a single entity

These companies are represented by a smart contract that has a single owner — a wallet or another contract. The ownership of the contract and thus of the company is represented by a NFT part of OpenDApps Ownership Infrastructure. Transfer of ownership of the company is as easy as transferring or selling the NFT.

The owner of the ownership NFT has the rights to execute transactions in the name of the company through the contract, manage funds owned by the contract and also manage child companies.

More details on managing and deploying companies owned by a single entity will be available in a dedicated blog post.

Multi-sign hierarchical companies

Multi-sign companies are smart contracts owned by multiple entities that require transaction signatures from multiple owners to execute transactions. One type of multi-sign ownership is through a hierarchical structure.

In a hierarchical structure, the owners are split into two groups — root signers and leaf signers. When a transaction is executed it requires approval from all root signers and 50% + 1 approval from all signers (root + leaf). This effectively means that a transaction cannot be executed without approval from all root signers meaning they have the power to veto proposals. At the same time, leaf signers can still block a transaction if enough oppose it and approval of 50% cannot be reached.

Hierarchical multi-sign ownership is a very secure and powerful ownership structure that is very useful for private companies with multi-level management.

More details on managing and deploying multi-sign hierarchical companies will be available in a dedicated blog post.

Multi-sign shares-based company

Like multi-sign hierarchical companies, multi-sign shares-based companies are smart contracts owned by multiple entities that require transaction signatures from multiple owners to execute transactions.

The ownership shares for the contract and thus for the company are represented by a NFT part of OpenDApps Ownership Infrastructure. Transfer of ownership shares is as easy as transferring or selling the NFT.

An owner of ownership shares NFT has the right to propose and execute approved transactions in the name of the company through the contract. For a transaction to be executed, a proposal with approval from 50% + 1 share is required.

More details on managing and deploying multi-sign shares-based companies will be available in a dedicated blog post:

https://mirror.xyz/0x95297b3A42991F16D09cBbC73aec12160A999250/6kSsWQcsTm-qvFGIn_YnxqgLOp46QZPAJyFARA-e8UQ

In-depth guides on all available services and other SaaS-related information resources will be available later on in this blog and any related content will be linked here:

1. OpenDApps Cloud — Testnet Connection and Testing Guide

2. Single Entity Decentralized Companies Overview (TBD)

3. Guide to Shares-based Multi-Sign Decentralized Companies on OpenDApps Cloud

4. Guide to Hierarchical Multi-Sign Decentralized Companies on OpenDApps Cloud

5. Token-as-a-Service Overview (TBD)

6. More….