BTC Class of 2020

Inflationary Tokens on OpenDApps Cloud — An Overview & Guide
Exploring the concept of inflation for ERC-20 tokens and how to manage it for tokens deployed on OpenDApps Cloud.Table of contentsIntroductionTypes of inflationary tokens and how they workExamples of inflationary tokensInflation on OpenDApps Cloud IntroductionWhy is it unique?The MathDeployment configuration on OpenDApps CloudInflation rewards management on OpenDApps CloudAutomatic burnStaking rewardsDistribution to an addressIntroductionIn this blog post we will take a look at the concept of...
Decentralized Companies in OpenDApps Cloud — An Overview
Exploring Decentralized Companies and Their Crucial Role in OpenDApps CloudTable of contentsIntroductionWhy do we need Decentralized Companies?Decentralized Autonomous Organizations (DAO)Why do we need Private Decentralized Companies?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 companyIntroductionIn this blog post, we explore the fascinating realm of decentralized companies and the imp...
Guide to Shares-based Multi-Sign Decentralized Companies on OpenDApps Cloud
An in-depth guide and how-to tutorial for shares-based multi-sign companies on OpenDApps, how to deploy them, and how to manage on-chain proposals.Table of contentsIntroductionThe concept of multi-sign decentralized companiesBasics of decentralized companiesOn-chain governance proposal systemMulti-sign voting systemThe concept of shares-based multi-sign decentralized companiesIntroductionCompany shares as ERC1155 NFTsShares-based voting powerDeployment on OpenDApps CloudOn-chain Governance on...

Inflationary Tokens on OpenDApps Cloud — An Overview & Guide
Exploring the concept of inflation for ERC-20 tokens and how to manage it for tokens deployed on OpenDApps Cloud.Table of contentsIntroductionTypes of inflationary tokens and how they workExamples of inflationary tokensInflation on OpenDApps Cloud IntroductionWhy is it unique?The MathDeployment configuration on OpenDApps CloudInflation rewards management on OpenDApps CloudAutomatic burnStaking rewardsDistribution to an addressIntroductionIn this blog post we will take a look at the concept of...
Decentralized Companies in OpenDApps Cloud — An Overview
Exploring Decentralized Companies and Their Crucial Role in OpenDApps CloudTable of contentsIntroductionWhy do we need Decentralized Companies?Decentralized Autonomous Organizations (DAO)Why do we need Private Decentralized Companies?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 companyIntroductionIn this blog post, we explore the fascinating realm of decentralized companies and the imp...
Guide to Shares-based Multi-Sign Decentralized Companies on OpenDApps Cloud
An in-depth guide and how-to tutorial for shares-based multi-sign companies on OpenDApps, how to deploy them, and how to manage on-chain proposals.Table of contentsIntroductionThe concept of multi-sign decentralized companiesBasics of decentralized companiesOn-chain governance proposal systemMulti-sign voting systemThe concept of shares-based multi-sign decentralized companiesIntroductionCompany shares as ERC1155 NFTsShares-based voting powerDeployment on OpenDApps CloudOn-chain Governance on...
BTC Class of 2020

Subscribe to ShadowsCrypto

Subscribe to ShadowsCrypto
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers


In Q1 of 2026, on X, Crypto Factor Labs published a plan for InterChain development for the year, built around the goals set by Crypto Factor's 2026 areas of focus. At the time of publication, InterChain fees rose due to the wMPC price adjustment applied to the Partisia Blockchain. While the plan execution addressed the fee increase, Crypto Factor built it at the end of 2025, focusing on the high overall usage fees.
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.
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.
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.
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.
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.
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.
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:

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.
In Q1 of 2026, on X, Crypto Factor Labs published a plan for InterChain development for the year, built around the goals set by Crypto Factor's 2026 areas of focus. At the time of publication, InterChain fees rose due to the wMPC price adjustment applied to the Partisia Blockchain. While the plan execution addressed the fee increase, Crypto Factor built it at the end of 2025, focusing on the high overall usage fees.
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.
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.
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.
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.
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.
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.
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:

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.
No activity yet