A Proposed Solution to Ease the Bonding Requirement and Allow for Community Voting

Introduction:

In a recent post, we shared our experience as a relatively new validator on the Icon network. We specifically talked about how difficult it was, and still is, for us to maintain the 5% bond. By looking at the bonding percentage, it quickly becomes obvious that we’re not the only validator facing this issue. At the time of writing, 8 of the top 20 validators do not meet the 5% bond requirement to varying degrees. Furthermore, the recent CPS discussions brought to light the community’s willingness to participate in the CPS.

We wanted to propose a potential solution that we believe will help any validator relying on community support, as opposed to being self-funded. Furthermore, this solution potentially adds to the stability of the validators, encourages more validators to participate in the CPS, and to the general participation on the Icon network (community voting).

Proposed Solution:

Currently, validators relying on community support find it difficult to raise the required 5% bond, primarily because the network only allows 10 addresses to bond. This presents a barrier to entry for validators, limits the decentralization of the network, and could be a bottleneck for the teams’ development capacity and speed.

To address this issue, we propose the development of a network-level smart contract that allows users to lock their ICX and receive another IRC-2 token called bICX in return, in a 1:1 ratio. The bICX can then be used to delegate bonding power to any validator the user wishes to support perhaps through a dedicated interface. This solution allows users to maintain control of their ICX without giving up custody of their funds.

Benefits/Advantages:

There are several potential advantages to this proposal. It increases participation in the bonding process and reduces barriers to entry for community validators, as they can receive support from a larger pool of users. Another advantage is that it could give holders of bICX who are using it to bond a say in the decision-making process. This is particularly relevant in light of the recent CPS discussions on how to give the community a voice in voting and potentially increase the number of validators registered for the CPS.

By bonding their ICX, bICX holders demonstrate a commitment to the network and should therefore be afforded the opportunity to participate in voting. All bICX holders would be able to vote in a DAO manner, and their collective vote of approval or rejection would be added to the total voting power, in a weighted manner, of the vote of any P-Rep benefiting from bICX bonds. bICX bonded to validators not taking part in the CPS will not carry any voting power, and as such bonders should prefer to support actively engaged validators. This could encourage more validators to actively take part in the CPS.

Potential Drawbacks:

There are a few potential drawbacks to consider with this proposal. One concern may be the added complexity of introducing a new token to the network. Additionally, according to the new proposed governance suggestions put forth by Lydia Labs, this proposal may also come with an increased risk of slashing or penalties in the future. As mentioned previously, we do not necessarily see this as a bad thing considering the added responsibility which comes with having a vote. However, we believe the benefits of increased decentralization and participation outweigh these potential drawbacks. Another risk, is that a network-level malicious contract may hold on to users’ bICX, but this can be overcome with proper auditing.

Conclusion:

In conclusion, we believe that the development of a network-level smart contract that allows users to lock their ICX and receive bICX in return is a promising solution to help some community validators with their bonding requirement on the Icon blockchain. It addresses the issue of limited participation and decentralization, and gives users control over their $ICX without requiring them to give up custody of their funds. It can be a good way to potentially offer ICX holders a way to weigh in on governance decisions. We welcome feedback and discussion from the community on this proposal.

5 Likes

Love the idea!

Is this something Framd is proposing to build?

1 Like

Further decentralizing the network by allowing more bonders sounds good. It would also add capital diversity to validators, making them a bit more volatile in the short term (bond supporters panic selling or cashing out), but more stable in the long run (eggs in many baskets).

Besides complexity, would you say smart contract risk might also be a potential problem? Do you think “bond supporters” will be consistent and keep voting after months and years?


Since the network already has this cool feature that allows multiple bonders, why not expand it allowing more addresses and let each validator make deals with bond supporters that:

1.- Won’t need to lock real ICX into smart contracts.
2.- Won’t give up custody.
3.- They probably don’t care for voting (might be wrong here) so they will trust the judgement for the validator they are freely choosing to support.

Complementary idea:

To make this boring idea a little cooler there could be an UI in place that allows:
1.- Validators to publicly attract bonders with economic incentives or value propositions.
2.- Bond supporters could ask for whitelisting and then to do the actual bond, never leaving the UI.
3.- Validators could have some reputation score (like airbnb hosts) so they are incentivized to keep their word with incentives or goals.

  • I’m not a dev so hopefully this is not too crazy.

  • I think there are a lot of ICX voters that would love getting a little extra APY in this simpler manner.

1 Like

Hey @FRAMD this sounds like a fine idea to meet the bond requirement, just a few tweaks.

1.) Are you sure it’s possible for a smart contract to be a bonder? If it’s not possible, your team (or somebody else) would need to submit a pull request on goloop for the change. I’m not sure of a clear process of getting a PR accepted, but @CyrusVorwald might be able to provide guidance on what to do if you end up needing to pursue this

2.) If it is indeed possible or becomes possible, I’d say this shouldn’t be network level, but just a smart contract FRAMD deploys. Let me know if I’m missing something there.

EDIT: looks like Goloop allows SCOREs to be added as bonders

https://docs.icon.community/icon-stack/client-apis/json-rpc-api/economics-extension#setbonderlist

I just wanted to add that I like the idea, nice suggestion.

1 Like

Love the idea! It is difficult for smaller P-Reps to achieve the requested % bonding with only 10 addresses, which is usually impossible! With this proposal you have more opportunities!