IIP-25: Delegate Endorsement


This proposal introduces Delegate Endorsement, enabling individual stakeholders within the IoTeX Network to become Delegates without owning a substantial amount of tokens (i.e., the current minimum self-stake requirement of 1.2M IOTX). Instead, we propose individuals can accept endorsements from other stakeholders to help meet the minimum self-stake requirement. We believe Delegate endorsement promotes inclusivity and decentralization, expanding participation opportunities and fostering a more fair and accessible IoTeX ecosystem. The proposal can be found in the iotexproject official GitHub, here.


The IoTeX network has been built on the principles of decentralization and inclusivity, allowing individuals and entities to actively participate in network consensus as Delegates. In the ecosystem, Delegates are responsible for running the Roll-DPoS consensus protocol to validate network transactions and produce blocks, as well as generate proposals to improve the IoTeX Network. In addition to technical requirements (i.e., maintaining uptime on a powerful hosted server), there are financial requirements to become a Delegate as well, specifically the current requirement of self-staking 1.2M IOTX tokens. This financial requirement has been cited as a barrier for IoTeX stakeholders who want to actively participate in consensus and governance but lack the necessary token holdings.

We propose the implementation of a Delegate Endorsement feature, which would allow stakeholders with substantial holdings to endorse and stake on behalf of aspiring individuals who do not meet the minimum token requirement. This program would enable individuals to actively participate in the network’s governance and consensus process, fostering inclusivity and diversity within the IoTeX ecosystem.




  • Delegate: A participant in the system to register without specifying a bucket

    • Oprations:

      • Register without Bucket: The process by which a delegate formally joins the system without designating a specific bucket.

      • Accept Endorse Request: The ability to accept an endorsement request from an endorser.

      • Terminate Endorsement: The action of terminating an existing endorsement.

  • Endorser: A participant with the capacity to stake an endorsement bucket and endorse a delegate

    • Operations:

      • Stake Endorse Bucket: The process of staking an endorsement bucket

      • Submit Endorse Request: The act of proposing an endorsement to a specific delegate.

      • Cancel Endorse Request: The ability to cancel a previously submitted endorsement request.

      • Revoke Endorsement: The action of unilaterally terminating an existing endorsement

Endorse Flow

  1. Delegate Registration without Bucket:

    i) Delegates can register by paying a registration fee of 100 IOTX.

    ii) Delegates who register without a bucket are not eligible to participate in the consensus process.

    iii) Each owner/operator address can only register as a delegate once.

  2. Endorser Stakes and Creates an Endorsement Bucket:

    i) Endorsers must stake at least 1.2 million IOTX to create an endorsement bucket.

    ii) The staking duration for the endorsement bucket can be freely chosen by the endorser.

    iii) Endorsers have the option to enable auto-staking

    iv) Endorser can stake multiple endorse buckets

  3. Endorser Submits Endorse Request

    i) The endorser selects an unvoted & unstaked endorsement bucket they own.

    ii) The endorser determines the endorsement expiration:

    • Delegates can participate in the consensus process until the endorsement expiration.
    • After the expiration, delegates need to obtain new endorsements to continue participating, while endorsers can proceed with a new round of endorsement.
    • The expiration time is not limited to the stake duration of the bucket. Once the bucket is used for endorsement, it cannot be unstaked until the endorsement is terminated.
    • Minimum 90 days

    iii) Endorsers can only endorse delegates who have not already been endorsed.

    iv) The bucket becomes endorse-locked after submitting, and can not endorse other delegate

  4. Endorser Cancels Endorse Request

    i) The endorser can cancel the request before it is accepted

    ii) The bucket becomes endorse-free after cancellation

  5. Delegate Accepts Endorsement

    i) The delegate can accept the endorse request

    ii) The bucket is bound to the delegate, can not endorse or unstake until endorsement terminate

    ii) The delegate is eligible to participate in the consensus process

Terminate Endorsement

There are three phases about termination:

  1. Trigger: start the termination process

    i) For endorser, there are two options:

    • Expire: once the endorsement starts, it naturally expires after a predefined period

    • Revoke:

      • Endorsers have the ability to unilaterally propose dis-endorsing.

      • A one-week protection period is initiated to allow for a smooth transition.

      • During this period, delegates can actively participate in consensus and search for new endorsers.

      • After the protection period ends, the endorsement relationship is terminated.

    • Comparation:

      • Setting an expiration time makes it more stable as it cannot be revoked at will, which benefits both the platform and the delegate.

      • Supports revoking is more flexible for endorsers, although it has a protection period. However, it is relatively unstable for delegates as endorsers can revoke it at any time.

    ii) For delegates, they have the option to unilaterally terminate their endorsement at will.

    iii) After one of trigger starts, the termination comes to “Locking”

  2. Locking:waiting N epochs to ensure that the assigned task (e.g. Selected as consensus candidate) has been completed and no new tasks will be assigned to it.

    i) N >= 2 at least, because it takes a maximum of 2 epochs to remove a delegate from the consensus candidate list.

    ii) During this period, the bonded bucket can not be unstaked or used to endorse others.

    iii) After this, the endorsement comes to an end.

  3. Terminated:

    i) The delegate is no longer eligible to participate in consensus.

    ii) The delegate becomes endorsable, meaning they can be endorsed by other endorsers.

    iii) The bucket associated with the delegate is unbound and can be used for another endorsement.


  1. Rewards are obtained from the same sources as traditional delegates, which include block rewards, foundation bonuses, and epoch bonuses.

  2. The distribution of rewards is based on the proportion of votes, with voters receiving their share, and the remaining rewards allocated to the endorsement bucket owner.

  3. When calculating voting power, the endorsement bucket also receives a self-stake bonus (i.e. 1.06x).

  4. Delegates have the flexibility to arrange reward distributions with endorsers off-chain, based on agreements made during the endorsement phase.

Delegate State

We redefine the state of delegate nodes in order to better achieve the aforementioned endorsement and terminate processes, as well as to enhance compatibility with existing staking mechanisms.

  1. Registered:

    i) Initialized after registration without a bucket.

    ii) Cannot participate in consensus.

    iii) Can be Self-Stake or Endorse.

  2. Staked:

    i) Attained through Self-Stake or Endorsement.

    ii) Eligible as a consensus candidate.

    ii) If endorsed, they can perform disendorse/ternimate operations.

  3. Exiting:

    i) Indicates the node’s intention to exit.

    ii) During this phase, the bonded bucket cannot be unstaked or used to endorse others.

    iii) Purpose of this state:

    • Continue fulfilling assigned tasks (current epoch’s consensus and the next epoch’s consensus) to ensure no unstaking before task completion.

    • Serve as a potential penalty period in the future.

Endorsement Bucket

  1. A minimum stake of 1.2 million IOTX is required to participate in the endorsement process.

  2. Can stake for any desired duration without special restrictions.

  3. Supports auto-stake, enabling auto-stake bonus in rewards.

  4. Endorsement bucket is dedicated solely to endorsing delegates and cannot be used for general voting.

  5. Once tokens are used for endorsement, they cannot be unstaked until the endorsement is terminated.

  6. Endorsement bucket cannot be used for endorsements after initiating the unstaking process


Comparation between Confirmation on-chain with off-chain

There is an alternative approach to the delegate providing a confirmation on-chain. This alternative involves adding an off-chain step to generation confirmation signature.

  1. Confirmation Signature (off-chain)

    i) Delegates and endorsers communicate off-chain to discuss endorsement matters and reach an agreement.

    ii) The delegate provides a confirmation signature, demonstrating their acceptance of the endorsement.

    iii) The confirmation signature is calculated using ECDSA and includes the following information:

    • Bucket index

    • Endorsement expiration

  2. The endorser provides the confirmation signature, confirming delegate’s agreement with the endorsement.


  • Confirmation signature off-chain

    • Pros:

      • Efficiency: The endorsement is considered valid immediately after completion, without the need for additional on-chain confirmations.

      • Cost Reduction: By eliminating the need for an additional on-chain transaction, there can be potential cost savings.

    • Cons:

      • Additional Signature Generation: Delegates need to generate an additional signature, which may require additional tools or processes. However, we can provide tools to simplify this operation and make it more user-friendly.
  • Acceptance on-chain

    • Pros:

      • Minimal Off-Chain Work: The off-chain process is simplified, and the majority of the work happens on-chain, ensuring a straightforward operation.
    • Cons

      • Additional On-Chain Step: The on-chain acceptance introduces an extra step in the endorsement process, which may require additional resources and potentially increase complexity.

Delegate Benefits

  1. Non-Staking Delegation: Delegates have the opportunity to become a delegate without the need for staking a large amount of tokens. This allows individuals with limited resources to participate in the network’s governance and decision-making processes.

  2. Recognition and Reputation: Delegates who receive endorsements from other participants gain recognition and build a positive reputation within the network. This can lead to increased visibility, credibility, and trust among the community, which in turn can open up opportunities for collaboration, partnerships, and further contributions to the ecosystem.

Endorser Benefits

Unlike staking their own tokens to become a delegate node, endorsing other delegates allows endorsers to avoid the time and effort required to manage a node. By endorsing delegates, endorsers can still actively participate in governance and impact the network’s direction without the need for direct node management responsibilities.

Here is a comparison of three staking methods:

Staking Method Rewards Requirements Risks
Self-Stake Delegate 1.06x - Sufficient tokens
- Managing running node
Complete self-responsibility
Endorse Delegate ~1.06x (Negotiated with delegate) - Sufficient tokens Potential penalties if the delegate engages in illegal activities in the future
Vote Delegate 1x - Small amount of tokens Minimal risk

I find it an interesting idea and in the right direction to increase the decentralization of the network.
However, it does not solve a key problem, which in my opinion is the inactivity and desperation of being left off the list of eligible delegates for long periods of time. This is the case with many potentially valid delegates being permanently left out of block generation rewards. In that situation there is no motivation to keep the node in good condition.
Although it could be that with this design they could group the necessary votes through agreements with “Endorse Delegates”, it would be highly difficult since these delegates cannot increase their reputation by being permanently left out of the block generation activity.
To correct these situation, I would consider interesting a variation of the random method of selecting elected delegates, in which in each epoch one of the 36 delegates elected (block generators) be chosen within the top ten of the delegates who are outside the scope of those eligible: i.e. delegates in positions 37 to 47. This would provide visibility and increase the chances of this group prospering without significantly affecting the rest’s rewards… I think it would be a good complement to this proposal.


I really commend the IoTeX community for continuously striving towards better decentralization and inclusivity. The proposal aligns with the principles of equal participation and access to governance opportunities. From the perspective of a DApp developer in the global south, where financial constraints could be a significant factor in participating in such networks, the introduction of Delegate Endorsement iss a game-changer.

The benefits for both Delegates and Endorsers are well-highlighted, with clear roles and well-defined processes, I am supportive of IIP-24 and believe that its implementation will contribute significantly to the IoTeX ecosystem’s growth and diversity. I look forward to witnessing the positive impact this proposal could have on network participation


I see the benefits of allowing for the endorsement of Delegates as it opens up the opportunity to a wider audience to become a Delegate. One question is this… What is stopping somebody now from creating a second wallet and moving the required $IOTX tokens in and running a second Delgate node? They’re basically doing the same thing, right? I ask Joe NodeRunner to endorse me as a Delegate. He can send the tokens to a wallet that he controls and we come up with a reward split. This can all be done between the two of us outside of the involvement of IoTeX or am I missing a step in the process?


Thanks for your suggestion, and it is another important issue. We are also considering how to enable nodes beyond the top 36 to actively participate in specific tasks. Once we have formulated a preliminary proposal, we will promptly publish it to the community.


This may require a KYC procedure. However, we currently do not have any plans for it.

1 Like

Interesting point. If I understood your question correctly, I would ask: What is your incentive for doing that? This also partially connects with @JoeGoodman 's comment, in the sense that besides the 1.2M, it would quite some effort in marketing and community building in order to be in the top 36 and then enjoy more substantial rewards. So it might not be worth it for you and Joe NodeRunner in your hypothetical scenario to run this scheme. What do you guys think?

Thanks @iChristwin - it’s great having you in our community!


hey everyone, really enjoying the discussion and the thoughts you guys are bringing to the table, I just wanted to update you on the fact that I changed the proposal name to IIP-22 instead.

@iChristwin @chenchen @JoeGoodman @Strangeways (tagging you guys since you’ve been actively participating in the convo :wink:)


A bit of a delay in responding but wanted to follow up. Regarding incentive, I just think that this is something that can be done already, correct? I’m not looking at this as a “scheme” or anything nefarious but rather a means of convenience. I guess I wonder if this is necessary.