Developers Forum for XinFin XDC Network: duts

[Informative]Community Support Bounty Rules and Application Form

duts — Mon, 04 Sep 2023 14:35:49 +0000

Eligibility:
-Projects can claim the bounty once per year (up to a maximum of 1 million XDC).
-Multi-year funding: Projects seeking funding for over a year should reapply annually, providing proof of progress, especially on-chain data. Exceptional cases may warrant multi-year bounties if the project holds immense value for the XDC Network and community and has proven its success.

Bounty Disbursement Schedule:
Q1: March 31
Q2: June 30
Q3: September 30
Q4: December 31
-Note: Submit proposals at least six weeks before the quarter's end for consideration in that period; late submissions will shift to the next quarter.

Requirements:
-A verified (KYCed) XDC address is mandatory for bounty disbursement.
-Claim your bounty under "Community Support bounty" at the XinFin Bug Bounty Program, Airdrop for community contributor page: https://xinfin.org/bounty.
-Rules, bounty amounts, and legal guidelines can change without prior notice.
-Jury members, who may be affiliated with XDC entities, cannot apply or receive any bounty.

Decentralization and Community Participation:
-Initially, only five projects will participate in this decentralized process. Subsequent adjustments may result from feedback from the community, core team, and jury.
-Onchain voting will be implemented soon.
-The XDC community can suggest jury members. Proposed profiles will undergo thorough evaluations by legal teams, founders, and existing jury members to ensure they are apt for the role and have significant stake in the XDC network.

Proposal Submission:
-Propose and submit budgets at XDC.DEV. Access the Request for Proposal (RFP), which must be completed by all applicants, here: https://docs.google.com/document/d/1ibxDgd2zYOXIjuWt9KjjCHExAcloEexPXgQWt-hb6Tc/edit?usp=sharing. (Also copied in full below).
-Successful projects must secure the approval of 5 of the 6 initial jury members.
-Positive funding outcomes necessitate at least one demo call with the members listed below:
Dustin Sebell - Neutral Community Voice
Matthew Weisenthal - XDC Foundation
Can Inac - XDC.EU GDCE
Rebecah Dausen - TradeFinex.org
Tadashi Yoshida - XDC Japan
Sean White - XDC Australia

Community Engagement:
-Garner community support by promoting your proposal on XDC.DEV, Linkedin, Twitter, and other XDC community channels or social media platforms.

Grant Application for XDC Network Development and Enhancement

I. Introduction:

The XDC Network is seeking proposals from qualified individuals and teams to undertake projects that will contribute to the improvement and evolution of the XDC ecosystem. The details of the application are outlined below.

II. Applicant Details:

Personal Information:
Full Name:
Email Address: For all future correspondences.

About You:
Please provide detailed information about yourself and your team. This should include qualifications, resumes, and especially past crypto work experience.
State if you and your team will be solely dedicated to this project during the active grant period or if you will have other concurrent work obligations.

III. Grant Application Details:

Grant Category:
Protocol development
Applications and integrations
Developer tooling
Code audits
Committees, sub-committees, and DAOs serving the XDC ecosystem
Community service (marketing and education)
Events and hackathons

Project Description:
Provide a detailed description of your project. Relevant links and materials such as websites, Twitter, GitHub, etc. should be included.

Project Goals and Aspirations:
Explain how, if funded, your project will enhance the XDC Network.
Discuss similarities and differences between your project and existing projects on the XDC or other networks.

Milestones:
State the current status of your project.
Detail the milestones and benchmarks of your project, specifying when you expect to meet each of them and how much funding you require at each stage.
If applicable, provide anticipated user-growth metrics with a timeline.

Budget:
Specify the amount of XDC you're requesting. Offer a detailed justification for this amount and describe its allocation. Mention any other funding sources you've secured or have set aside.
Indicate if you'll need to liquidate XDC to support your project and specify the amount and reasons. If liquidation is required, mention if you can use FXD or an UpHold or Kinesis credit card.

Sustainability:
Describe how your project will become self-sufficient. Highlight potential revenue streams or income sources, and list any expected additional operating costs.

Legal:
Provide your legal status and state if your project is incorporated. If so, where? Specify the recipient of the funds if your proposal is accepted.

Additional Information:
Reflect on what further details you'd like to share about yourself or your project.

IV. Proposal Submission:

Positive decisions will be made quarterly: on March 31, June 30, September 30, and December 31.

All positive funding decisions will require at least one demo call with the jury.

V. Evaluation Criteria:

Proposals will be evaluated based on feasibility, potential impact on the XDC Network, team qualifications, budget justification, and sustainability plans.

VI. Additional Notes:

If you have any queries related to this RFP or need further clarification on any point, please reach out.

We look forward to receiving your proposal and exploring the potential ways we can enhance the XDC ecosystem together.

Proposal to Streamline and Further Decentralize the Incentive Structure of the Network

duts — Fri, 01 Sep 2023 21:10:41 +0000

In the following proposal, the current incentive system of the network is analyzed and a series of modifications are proposed to optimize and decentralize the structure. The primary goal is to foster a more decentralized approach, which is essential for maintaining the trust and security integral to the network's operations.

Current Network Incentivization Structure:

Core Masternodes:
• Number: 108
• Rewards (from minting): Each core masternode earns 42 XDC every hour.
• Annual Yield: This equates to an annual yield of 7.37% (or approximately 737,280 XDC) based on a staking requirement of 10,000,000 XDC.
• Subsidy: Additionally, each node is subsidized 22,500 XDC monthly from the Ecosystem Development Fund. This subsidy translates to an additional 270,000 XDC annually, pushing the total annual rewards for a core node to 1,007,280 XDC.
• Total Annual Percentage Yield (APY): The combined APY for core masternodes, factoring in both minted rewards and subsidy, is 10%.

Standby Nodes:
• Number: 242 (as per the 350-node configuration)
• Subsidy: Each standby node is subsidized 66,666 XDC monthly from the Ecosystem Development Fund.
• Annual Yield: This subsidy translates to 8% annual yield, equivalent to 800,000 XDC, based on their identical staking requirement of 10,000,000 XDC.
The cumulative rewards for standby nodes are derived solely from the Ecosystem Development Fund subsidy, with no additional earnings from the minting process.

Current Incentive Dynamics Explained:

The network depends on minting an estimated 5.596 XDC every two-second block. Annually, this accounts for a mint of approximately 88,250,000 XDC. This freshly minted XDC is then proportionally distributed among the validators or core masternodes, all of whom actively contribute to the consensus.

In this scheme, the core masternodes, limited to a total of 108, jointly divvy up about 5.05 XDC. Each core masternode thus earns approximately 42 XDC every half-hour. Since this yields less than the expected Automatic Annual Percentage Yield (APY) of 10%, which is equivalent to 1M XDC annually, core nodes receive a supplementary subsidy of 22,500 XDC each month, drawn from the Ecosystem Development Fund, to make up for the shortfall between the 7.37% APY minted and the expected 10%.

The network also accommodates standby nodes. While they aren't actively engaged in the consensus process, they remain on standby to substitute any core masternode as circumstances dictate. To maintain their readiness, they receive a monthly subsidy of 66,666 XDC from the Ecosystem Development Fund, which equates to an 8% annual yield, or 800,000 XDC, on their identical staking requirement.

Proposed Changes:

The recommendation presented here would eliminate the subsidy model, choosing instead to adopt a more direct minting approach. By doing so, core masternodes would directly obtain their due 10% APY from the protocol, and similarly, standby nodes would receive their 8% APY automatically (if not via the protocol itself, via smart contracts).

The minting for core nodes would adjust to 0.0634 XDC per block for each node, accumulating to 6.8493 XDC for all masternodes per block. The standby nodes, on the other hand, would transition from zero minting to a rate of 0.05073 XDC per block for each node.

The Rationale for Making the Proposed Changes:

The cornerstone of a robust decentralized system rests upon its ability to effectively incentivize validators. These incentives should be structured such that they dissuade malicious behavior, ensuring that each validator's interests align with maintaining integrity and upholding the network's health. A difficulty emerges when validators derive a significant portion of their incentives from third-party entities. No matter how trustworthy or competent such an entity might be, its involvement poses challenges to strict decentralization and, by extension, potentially compromises the security of the system. If the entity ever fails to distribute the rewards consistently, the fabric of incentives underpinning the network risks unraveling. As such, the practice of subsidizing from an external fund was only a provisional measure—a foundational step intended to evolve towards a system wherein the protocol autonomously generates and disburses rewards in a trustless manner.

The proposed increase in the rate of minting does not inherently pose a threat of inducing real inflation within the ecosystem. The logic underpinning this assertion is grounded in understanding the dynamics of supply and demand. Specifically, there exists no tangible difference between funds migrating from the ecosystem development funds (a non-circulating supply) into the circulating supply and those funds that are newly minted by the protocol itself into the circulating supply. From the perspective of market economics, both scenarios introduce equivalent quantities of assets into the circulating medium, rendering them indistinguishable in terms of their inflationary implications.

Increasing the Security and Decreasing the Supply of XDC

duts — Thu, 10 Nov 2022 12:58:32 +0000

Introduction

I propose that we increase on-chain transaction (TX) fees.

I see two general reasons for doing this, which I’ll address first, in Part 1, before getting into the particulars in Part 2. In sum, a negligible increase in TX fees will (A) substantially decrease the supply—if, in a subsequent proposal, we establish an automatic on-chain burn—and it will, more importantly, (B) substantially increase the security of XDC.

Finally, in Part 3, I’ll mention an additional consideration, about the (currently, centralized) way in which masternodes are rewarded, which, I think, should be taken into account in all of this.

Part 1

(A)

The XDC Network is currently micro-inflationary. That is, the network mints about 88,237,728 XDC per year in order to reward masternodes. It’s important to understand that this relatively small amount of minting is crucial to keep the network secure. A permissionless blockchain depends for its safety on properly incentivized network participants. In this case, it’s imperative that the masternodes entrusted with validating the network be incentivized to do so—meaning, rewarded with XDC—and it’s equally imperative that they be rewarded with XDC automatically, in a decentralized way, by the network itself. Without decentralized, automated minting, the masternodes would be dependent on someone or something else for their income, which would put the network at risk. In short, if anything were to happen to the entity subsidizing the masternodes, or if that entity were to engage in any misbehavior, the system of incentives that keeps the network afloat would break down.

But, while minting is absolutely necessary for this reason, we can offset at least some of its inflationary effects by increasing the TX fees as well as the burn rate of XDC, which will serve to decrease XDC’s supply and maybe even, eventually, make XDC deflationary.

XDC Network users always have the option of sending XDC to the burn contract, and some dApps have been designed to do this automatically. But there is presently no automatic on-chain burn mechanism. Only about 700,000 XDC has been manually sent to the burn contract since the network went live in 2019. As compared with about 300,000,000 XDC minted, that isn’t much.

So, this is the first reason why I am proposing that we increase the TX fees: if we decide to increase TX fees, we can then move ahead with a separate proposal to add an automated burn, thus making make the XDC Network less inflationary and maybe even, eventually, deflationary.

(B)

But, as important as that is, the second reason for doing this is much, much more important than the first.

Sending a transaction on a permissionless blockchain requires users to pay a relatively small fee. These TX fees, generally speaking, serve two distinct purposes:

First, since the fees are paid in whole or in part to validators (masternodes), they serve to reward validators for good behavior.

Second, since it costs something to send a transaction, TX fees serve to deter spam, which can create network congestion, degrade the network’s performance, and even, in the worst case scenario, bring down the network entirely. Spamming can be unintentional; but it can also be intentional, as when a bad actor launches a Distributed-Denial-Of-Service (DDoS) attack.

When setting on-chain TX fees, it is therefore necessary to strike a balance between affordability and security. On the one hand, if TX fees are too high, users will be deterred from using the network, which will of course prevent widespread adoption … and that’s no good … BUT, on the other hand, if TX fees are too low, the network can be spammed to death … and that’s not good either.

To illustrate the dilemma we face, consider the case of Ethereum as compared with Solana. XDC was designed partly in order to fill the gap left by Ethereum (ETH), with its prohibitively high TX fees. But Ethereum’s high TX fees, while they deter network adoption, actually do a very good job of keeping the network safe from spamming and DDoS attacks. On the other hand, Solana (SOL) has been vulnerable to multiple high-profile network failures owing partly to the fact that it has such low TX fees: https://www.yahoo.com/video/solana-latest-ddos-attack-leads-120022342.html.

The bad news is that XDC’s TX fees are currently too low to deter spamming and DDoS attacks. A typical transaction on the XDC Network costs at a maximum about 0.0004 XDC (or about $0.000012 @ $0.03/XDC)—usually, transactions are actually much less expensive than that (around 0.000021 XDC), but we’ll err on the side of caution here and go with maximum. Since every block can carry a maximum of 4,000 transactions, it would only cost, at most, about 1.6 XDC to fill an entire block (or about $0.05). And since there are about 1,800 blocks every hour, it would only cost, at most, about $90 to jam the network for an hour, which comes to about $2,160 for an entire day. That’s not costly enough to deter malicious actors or even just innocent, overactive users from clogging the network up.

So, this is the second, and more important, reason why I am proposing that we increase the TX fees: to make the XDC Network more secure and future-proof.

Part 2

The good news is that TX fees are currently so infinitesimally low on XDC that even if we were to increase TX fees 5x or 10x or even 20x, for example, there would be little to no impact on the network’s affordability.

A 5x increase in TX fees would come to about 0.002 XDC or about $0.00006/TX.

A 10x increase would come to about 0.0048 XDC or about $0.000144/TX.

A 20x increase would come to about 0.008 XDC or about $0.00024/TX.

Needless to say, the cost would remain negligible from the point of view of the end-user. But a 5x increase would bring the cost of a DDoS attack over a 24-hour up to $10,800, a 10x increase would bring the cost up to $21,600, and a 20x increase would bring the cost up to $43,200.

In addition to this, a 5x, 10x, or even 20x increase in TX fees would allow the network to burn a more substantial amount of XDC with every TX, potentially doing more to offset the micro-inflation due to the ongoing minting.

That would mean, specifically, if there are on average 10 TXs pers second happening on chain, and if the TX fees were increased by 5x, 10x, or 20x, there would be .02 XDC (or $0.0003), 0.048 XDC (or $0.0006), or 0.08 XDC (or $0.0012) collected per second, respectively. Or, respectively, 630,720 XDC, 1,513,655 XDC, 2,522,800 XDC collected per year. If there are more or less TXs happening per second on chain, the annual amount of XDC collected would of course increase or decrease accordingly.

But the key thing here is that, since all of that XDC could be burned, yearly inflation on XDC would be cut … almost in half, for example, if there were 150 TXs happening per second and TX fees were increased by 20x.

So, in conclusion, by increasing TX fees, we can improve the security of the network. Moreover, if, in a subsequent proposal/vote, we go on to establish an automatic on-chain burn of the newly increased TX fees, we can cut down on inflation. All in all, with this increase, we will be future-proofing XDC and paving the way for additional future-proofing. The most important thing here, I think, is that we take the initiative and increase the TX fees proactively, and not wait until after the XDC Network is subjected to a DDoS attack, which is likely to happen as the Network gains more and more traction and is adopted ever more widely. Lastly, remember that the calculations above are all based on the maximum TX fee, not the average, which is orders of magnitude lower than the maximum.

Part 3

A final consideration.

Masternodes are currently subsidized by funds set aside by XinFin in an ecosystem development fund wallet. Since there is not enough on-chain minting to ensure that masternodes receive the expected 8-10% APY, rewards are manually dispensed to node operators by the tech team every month. Core masternodes are partly and standby masternodes are fully subsidized in this way. However, because the process by which masternodes are rewarded is largely manual, rather than fully automatic, the network is less secure than it could or should be. For, to repeat, if anything were to happen to the entity subsidizing the masternodes, or if that entity were to engage in any misbehavior, the system of incentives that keeps the network afloat would break down.

We should, for this reason, be working toward a fully automated and thus fully decentralized incentive-structure, one in which masternodes are not dependent on monthly payments from any entity, including even XinFin itself. Increasing the TX fees will make it possible, sometime down the road, to generate more rewards from the network and distribute them to masternodes … automatically, in a decentralized way, and not manually.

Conclusion

At the stage, I’m not proposing a specific TX fee increase. Instead, I’m proposing that we agree (or disagree) to increase the TX fee on XDC, probably anywhere between 5-20x ... for all of the abovementioned reasons.

Once we agree on that—if we do—then we can move forward with additional proposals. First, we’ll vote on exactly how much to increase the TX fees. Then, once we decide how much to increase the TX fees, we can decide whether to automatically burn some/all of the larger amount of TX fees collected, and whether (and how) to reward masternodes automatically from the increased TX fees.

Comments are, of course, welcome below.

When you’ve made up your mind, please cast your vote in the comments section: Vote = YES or NO.

Voting will begin today, Thursday, November 10, at 8 AM (EST) and end Thursday November 17 at 8 AM (EST).

Thanks to all in advance for participating in this process!

RESULTS

Thanks again for participating. The results are as follows:

Total Votes: 96
YES votes: 95
NO votes: 1

Overall Post metrics (likes, comments, views):

The wayback machine keeps failing to archive the pages. As soon as it works, I'll update the post with links to the archives pages.