Transmitter Staking & Consensus

Now that we know how Transmitters are managed, let’s dissect the staking model, consensus mechanisms, and the incentive structure designed to ensure the fidelity of data and the robustness of the network.

Entangle introduces a sophisticated staking model, leveraging a Hybrid Delegated Proof of Stake (DPoS) framework to secure its network. Unlike traditional DPoS systems that rely on Super Representatives (SR), Entangle employs its network of Transmitter Agents.

Transmitter Agents come with distinct capability sets, allowing them to register specific protocol support software they operate. This flexible framework enables External Developers to define their protocol needs precisely, such as the type of Transmitter software required, the number of transmitters, the minimum delegation amount, and the inclusion of private Transmitters.

External Developers play a crucial role as the architects behind the protocols requiring data or message transfer across different blockchains. Before participating in the system, External Developers must:

  • Undergo KYC verification.

  • Create and manage their protocols

  • Set up manual transmitters and executor programs

  • Continuously monitor their protocol's balance. Protocol parameters such as message and data bet amounts, rewards, consensus target rates, and Transmitter limits are meticulously defined to ensure optimal operation during each round.

To understand how Transmitters gain information from External Developers, click here.

Transmitter agents are at the heart of the system, tasked with monitoring on-chain and off-chain data and proposing relevant data and messages. After passing KYC verification, Agents stake personal funds, support specific protocols, set up necessary software, and await delegations.

An Agent's Transmitter is chosen for a protocol in the subsequent round if it meets the minimum personal and total delegate requirements, ranking it among the top eligible Agents for the protocol.

Transmitter Staking

Transmitter Agents must lock up a predefined minimum amount of NGL tokens to participate in the network. The staking threshold can vary, influenced by network governance decisions or dynamic parameters designed to adapt to the network's security needs. Agents must also:

  • Declare or revoke support for some set of protocols and add Transmitters to corresponding protocols.

  • Setup required programs for chosen protocols

  • Get the required stake from delegators. Delegators, seeking attractive APY on their NGL tokens, delegate to a range of Agents, claim rewards, and manage their withdrawals in alignment with the approximately one-week round time.

Agent Election

In each protocol, there is a predefined group of static Transmitters, referred to as set M. During each round, a selection process occurs where a subset of agents and Transmitters, denoted as E, is chosen based on specific criteria.

The size of set E combined with set M must not exceed the maximum number of Transmitters allowed by the protocol, expressed as protocol.maxTransmitters.

Each agent (k) within set E must meet two conditions:

  1. Their personal stake must be at least the minimum required by the protocol (k.personalStake >= protocol.minPersonalStake).

  2. Their total delegated stake must also meet or exceed a protocol-defined minimum (k.totalDelegate >= protocol.minTotalDelegate).

The total group of Transmitters for the round, labeled T, is the union of sets M and E (T = M+E).

After determining set T, it is compared with the group of Transmitters from the previous round to identify any changes. This comparison results in two lists:

  1. ToAdd, which includes Transmitters that are new to this round and were not part of the previous round.

  2. ToRemove, which consists of Transmitters that were part of the previous round but are not included in the current one.

These two lists, ToAdd and ToRemove, are then communicated to the Master Smart Contract, which broadcasts the changes across various blockchain networks.

This system ensures a dynamic yet stable pool of Transmitters for each round, optimizing for data accuracy and network resilience.

Round management is a critical function within the Entangle Oracle Solution, orchestrating the lifecycle of data proposals, from submission to finalization, and ensuring the timely execution of omni-chain operations.

This step is managed by the Round Manager contract. Here is a brief overview of what it does:

  • Manages the transition of rounds.

  • Distributes rewards.

  • Updates parameters for the next round.

  • Pause protocols with insufficient stake.

  • Selects Transmitters for the next round.

For each protocol, the selection of Transmitters (from the pool of Agents) for every round takes into account the total number of required Transmitters minus any private Transmitters specified by the protocol.

This ensures that only Transmitters from the top-ranked Agents by total delegated amount, with matching capabilities for the protocol, are chosen. This model encourages users to delegate tokens to their preferred Agents, incentivizing Agents to attract more delegations to increase their chances of selection for protocol tasks.

Last updated