Entangle Blockchain


The Entangle Blockchain operates as a principal communication nexus, where data is stored, verified, and processed.

Integration with Ethereum and Cosmos Ecosystems

Constructed on the Ethermint framework, the Entangle Blockchain combines the interoperability and scalability provided by Cosmos with the solidity and familiarity inherent to Ethereum. This amalgamation facilitates full Ethereum compatibility while employing the efficiency of the Tendermint Core's Proof-of-Stake consensus mechanism for expedited finality in operations.

Developer Interface and Compatibility

A significant attribute of the Entangle Blockchain is its Web3 JSON-RPC layer, which guarantees uninterrupted interaction with established Ethereum clients and tools, including Metamask, Remix, and Truffle. This ensures that developers can transition or augment their EVM-based applications to a platform that is both scalable and cost-effective, without foregoing the essential tooling and community support.

Smart Contract Deployment

Initial deployment of smart contracts on the Entangle Blockchain is permissioned but requires authorization, thereby ensuring a secure development environment. Authorization for smart contract deployment is obtainable either directly from the Entangle team or via a governance module proposal, aligning with the community's interests.

Performance and Efficiency

The blockchain's performance metrics are designed for high throughput and efficiency, with details on transactions per second (TPS), block time, and maximum transaction size pending. The platform also incorporates mechanisms for managing the emission of its native token $NGL, aimed at providing validators with competitive annual percentage yields (APY).

Service Transactions and Automation

The Entangle Blockchain supports service transactions, facilitating the automated execution of routine, periodic operations essential to the functionality of protocols such as Photon messaging and Data Stream. This automation enhances both accuracy and timeliness, and expands the system's capacity for efficient transaction handling.

Future Developments

Plans are underway to upgrade the blockchain to the latest version of Cosmos, anticipated to further improve block processing speed and overall performance. The reduction in block time intervals from this upgrade is expected to significantly enhance the blockchain's efficiency.

Entangle Blockchain Architecture

The Entangle Blockchain consists of 3 Layers:

  • Application Layer

  • Modules Layer

  • Tendermint Consensus Layer

Application Layer

The Application Layer facilitates the decoding, correctness, and redirection of messages to designated Modules. It encompasses smart contracts, dApps, and other software operating atop the blockchain network, thereby enabling the development of novel applications and services that harness the blockchain's inherent security and transparency.

This layer constitutes the user interface of the blockchain, allowing for direct interaction between consumer devices and the blockchain network. It serves as the front-end through which users engage with the blockchain, while the underlying blockchain stack functions as the back-end. The Application Layer is composed of various components including scripts, application programming interfaces (APIs), user interfaces, frameworks, smart contracts, and dApps.

The protocols within the Application Layer are bifurcated into application and execution segments. The execution layer comprises smart contracts, foundational rules, and chaincode, each playing a pivotal role in the lifecycle of a transaction. Transactions initiate at the application layer, proceed to the execution layer for validation, and culminate at the semantic layer where they are executed.

This layer ultimately delivers blockchain-based applications to end-users, offering specialised functionalities such as wallets, lending, staking, among others. At the core of the Application Layer lies the smart contract, which is programmable code dictating state transitions. Direct user interaction with smart contracts is mediated through the front end of Web3 applications or APIs.

Modules Layer

See the list of modules and their description in the table below.

Module nameDescription

Delegated Proof of Stake (DPoS)

Facilitates staking for Validators and Delegators.


Sending and receiving assets on Entangle Blockchain.

GOV Module

Changes to blockchain parameters, addition of new Validators, Distributors or Agents.

Auth Module

Allows authorized entities to launch smart contracts on Entangle Blockchain.

IBC Module

Facilitates communication with Cosmos-based Chains.

Distributor Module

A database of authorized Distributors added through the GOV Module.

EVM Module

Hosts smart contracts deployed on Entangle Blockchain such as the Controller. Provides composability between Entangle Blockchain and EVM Infrastructure such as Metamask, Hardhat, and Truffle.

Vesting Module

Facilitates vesting of $NGL Tokens.

Tendermint Consensus Layer

Tendermint employs a Byzantine Fault Tolerant (BFT) consensus mechanism within a Proof of Stake (PoS) framework, capable of withstanding up to one-third of faulty nodes within the network. The algorithm facilitates P2P Connections between Validators reaching consensus on new blocks.

Participants in Tendermint


Validators are integral actors within the protocol, responsible for proposing and voting on blocks of transactions. Their role is allocated via round-robin scheduling, based on the proportion of stake they hold.


Delegators, holding tokens but opting out of direct validator responsibilities, delegate their stake to validators. In return, validators levy a commission on earnings accrued from these delegated stakes.

Consensus Process

The consensus within Tendermint involves several steps: Propose, Pre-vote, Pre-commit, Commit, and NewHeight.


In this phase, a designated validator compiles transactions into a block proposal, subsequently broadcasting this to peers.


In the beginning of the Prevote step, each validator makes a decision. If a validator is locked on a proposed block from a previous round, it signs and broadcasts a prevote for the locked block. If the validator had received an acceptable proposal for the current round, it signs and broadcasts a prevote for the proposed block. If the validator had received no proposal or an invalid one, it signs a special nil prevote. All nodes gossip all prevotes for the round to their neighbouring peers during this step.


At the start of the Precommit step, each validator makes a decision. If the validator has received more than 2/3 of prevotes for a particular acceptable block, it signs and broadcasts a precommit for that block. It also locks onto that block and releases any prior locks. If the node had not received more than 2/3 of prevotes for a particular block, then it does not sign or lock anything. During this step, all nodes gossip all precommits for the round to all neighbouring peers.


This step has two parallel conditions that must be satisfied before finalising the round. First, the node must receive the block committed by the network if it hadn’t already, and sign and broadcast a commit for that block. Second, the node must wait until it receives at least 2/3 of commits for the block precommitted by the network. Once both conditions are satisfied, the node sets its CommitTime to the current time and transitions to the NewHeight step.


After a block has been committed by the network, the NewHeight step allows nodes to gather additional commitments for the previously committed block from the preceding height. Nodes remain in this step until a fixed duration of time has passed since the CommitTime of the last block. This process enables block proposals to include more than the minimum 2/3 of commits, thus allowing the commits of slower validators to be included in the subsequent blockchain.

Locking Mechanisms in Voting

Locks are pivotal during the voting stages to ensure consistency and prevent equivocation. This mechanism refers to the action taken by a validator to commit to a specific block during a particular round. When a validator is locked on a block, it means they have chosen to support that block and its position in the blockchain. A lock prevents a validator from quickly changing its support to another block in the same round.

Initiating New Rounds

New rounds are necessitated under circumstances such as proposal failures, invalid blocks, untimely propagation, or inadequate pre-vote/pre-commit consensus. Each scenario underscores the robustness of the Tendermint consensus in maintaining network integrity amidst challenges.


Validators can incur penalties for insufficient or malicious activity:

  • Double signing blocks

Validators will have a percentage of their tokens slashed.

  • Signing less than 50 of the last 100 blocks.

A percentage of staked tokens are slashed. Validators are temporarily put in "jail" for a set period of time.

Last updated