[Status: Draft] XIP-4: Node Incentive Framework



xip: 4
title: Node Incentive Framework
author: [StatusQuoKiller](https://geohacker.xyo.network/u/statusquokiller)
status: Draft
category:  Cryptoeconomics | Diviner | Archivist 
created: (2019-05-15) 


Incentivize Archivist and Diviner operation with the cryptoeconomic reserve to add value to the XYO token by improving network size/quality in addition to creating an atmosphere of scarcity and holding for the XYO token.


  1. Currently, a node operator is not rewarded beyond his or her stake and the following problem arises: It makes more economic sense for any rational individual to stake someone else’s node while saving their own time and money to increase their own stake. In other words, contributing to the network’s ability to provide a service to a customer is an economically irrational decision.

  2. Solicit network participation beyond geomining kits and HODLing. Incentivize the infrastructure. It should be pointed out that even BTC required node operation to own a wallet and transact with BTC at its onset - they incentivized the network, and did not allow staking and waiting (crossing fingers) until some level of maturity was established.

  3. The financial circumstances of potential node operators should not prohibit the growth of the network. Giving upside exposure to people with little to invest in staking, but means of operating a node, provides growth incentive without leaning on the wallets of the community, (tired) investors, and overly ambitious crypto geeks “doing it for fun”

  4. Staking and token burning, in and of themselves, only add value to the token through the economic principle of scarcity while ignoring the quality of the service advertised by the network and provided by the nodes. This fact does not foster an environment of participation and/or expansion which is necessary to fulfill the basic promise of the network. Ultimately, staking and burning tokens will not compensate for the lack of value of the networks services that will arise without node participation.


Two types of rewards are established below. They are followed by some other concepts for support.

  1. NODE CREATION REWARDS - Award XYO to new node operators from the reserve until the reserve is empty.

    a. It can only be retrieved after X months of successful operation, to provide insurance against bad actors. This could be viewed as providing stake for the operators.
    b. This is independent of stake put up by the operator.

  2. OPERATOR TRANSACTION REWARDS - The owner of a node will receive a reward from the cryptoeconomic reserve equivalent to some small percentage, “rate lock (see 4 below)”, of the total of each transaction reward sent to his or her node. This is mutually exclusive to his or her staked reward.

    a. This percentage should be small (.001 -2%) of a node’s total rewards so as not to disincentivize staking.
    b. Rewards cannot be retrieved for X weeks/months to incentivize continued operation. One cannot obtain the rewards earned last month until additional successful operation occurs. The “carrot” metaphor almost literally applies here.
    c. An equivalent amount of this reward will also be burned from the reserve. This means that as the network gains operational momentum, the reserve burns. This is not equivalent to burning tokens as others buy them as it relates to the product and service - not investor speculation.

  3. THE SWITCH - Once the rewards can no longer be taken from the cryptoeconomic reserve, the operators reward is taken from the total reward sent to his or her node for each transaction. This will be a milestone event for XYO and true demonstration of it’s adoption.

    1, 2 & 3: OperatorRewards = RateLock*TransactionRewards = AmountBurned

    And the reward is source from the reserve while applicable, then sourced from the transaction itself.

  4. RATE LOCK - The percentage offered to the node operator, “rate lock,” would be a function of the total number of nodes on the network. If there are less than 100 Archivists online, then a new archivist could lock in a 2% rate. If there are more than 100 Archivists, then the operator rate lock would decrease with the number of nodes - incentivizing earlier participation and continued operation. Once a very large number of nodes exists (TBD), the rate degradation could cease in order to continue soliciting node participation.

    For n<100, Operator Rate = 2%
    For n>100, Operator Rate = 2% *100/n
    For n> VERY LARGE NUMBER (TBD), Operator rate is locked in at .001% to continue incentivizing even after the network saturates

    This rate could potentially exist for each node type to ensure a balanced distribution of nodes. However, the network already has similar properties due to its architecture.

  5. RATE LOCK WALLET - Provide a whitelist wallet at the time of initial rate lock. If a node goes down for an innocent reason, the operator is allocated 30days to bring up a new node without risk of losing their rate. When the operator points to the whitelist wallet within the time period, the initial rate lock is implemented. If the operator cannot re-establish their services within the 30 day time period, they lose their rate lock.

  6. RATE LOCK POSITION - View rate lock not as a rate, but as a place in line. Archivist #200 will always have a rate lock of 1%. If Archivist #200 leaves the community for more than 30days, then archivist 201 takes the 200 spot and associated rate. All newcomers go to the end of the line.

    5 & 6 - So if a node goes down, the operator is given a chance to bring it back up without losing rate lock.
    But if operators leave the network or are removed, those who arrived later move up the ranks so that newcomers can never have a better rate lock that someone who’s been providing services for longer.


The fact that staking by itself is easily preferable to building and operating a node is very prohibitive to expanding the network, and leads to the question of “wait, what are we staking?”….

We want to incentivize the product - not just HODLing. The product is the decentralization, storage, and compute power of the network. These things are the support and foundation for Bound Witnesses to propagate and exist.

The value proposition goes from “invest your money in XYO because we’re gonna burn tokens” to “invest a small amount of time and money into contributing to the value of the network to provide a product worth investing in …… And we’ll burn some tokens while we’re at it, and you’ll earn more tokens as well”

Scheduling the rate lock is to motivate action now instead of later.

Viewing rate lock as a position in line provides relief from the “what if my node melts” concern and gives newcomers the potential for improving their rate lock position with time if those ahead of them leave or are removed from the network.

There is a space to explore with changing rate locks as a function of services provided to the network. Currently, early adopters get better rates. The other approach is to increase ones rate with time agnostic of starting position. However, this does not carry the urgency that the current proposition has. Moreover, it would be more complex to vary each operators rate with time, and the total amount of costs going to rate lock would be less predictable as we don’t know how long operators will stay with the network. The current proposal establishes a ranking system with a known rate lock for each rank - simple and predictable.

An argument can certainly be made to NOT burn tokens if the tokens are used incentivize nodes for a longer period of time. But I think the cat’s out of the bag RE burning. Could be bad optics to double back on that now.


  1. I’m looking for input on rate lock values. The numbers in the rate scheduling below are sensical to me, but derived from nothing but “sounds right”.

    For n<100, Operator Rate = 2%
    For n>100, Operator Rate = 2% *100/n
    For n> VERY LARGE NUMBER (TBD), Operator rate is locked in at .001% to continue incentivizing even after the network saturates

  2. Also not opposed to changing the word “rate lock” to something more apropos.

  3. Looking for commentary on if burning tokens is better than saving them and offering as a reward for node generation. The proposal, as is, suggests doing both - but only because XYO has already advertised that they will burn. I guess we could keep doing 1:1 burn with buy, and not burn 1:1 with operator rewards as I’ve suggested here.

  4. Looking for time spans for delaying the receipt of node creation rewards and operator transaction rewards. I’m inclined to provide large but heavily delayed rewards for creation (1.5M XYO, 1 Year) and more readily available rewards for operator transactions (RateLock*TotalNodeTransactionRewards, 30days).


There are likely technical implications here since smart contracts and node registries would need to be created or modified. I am in the midst of learning to be a coder (10,000+ lines of MATLAB and some introductory software under my belt), but this should be left to the professionals for now.

• Node registries to include rate locks. (effectively node type, position in line, and resulting rate lock)
• New smart contract to send rewards from reserve to operator and burn reserve.
• Once reserve is depleted, implement rate lock on transaction reward smart contracts.

Next Steps

Approval or dismissal of this idea should occur prior to or near the releases of stable Diviner and Archivist code. If undecided, we should at least track the necessary information from Diviners and Archivists coming online now should we decide to pull the trigger.

An easy to establish, off chain record could be made to temporarily track the first nodes on the network and create “IOUs” for creation rewards. IOUs for operator transactions rewards should be derivable from the network’s history retroactively when XYO can catch its breath. Eventually, rate lock should become part of the official node registration process through the matrix and transaction rewards implemented in smart contracts.


@scott @pizzamind from me to you

i meant to write this 6 months ago - had a draft :man_facepalming:

1 Like

This type of badass input is what the XIP section was built for. Excellent job!

Personally I’m against token burns for XYO, but love them for literally everything else I’m investing in. Because on the biz dev side, it’s massive power I can use to get things built, help the FHR, create alliances, stake nodes, etc… i can see the value in burning some if it brings a cash infusion to the company so we can hire more devs. That serves the best and highest good for everyone. There are many days i wish the original 100B total supply was still around. Sounds crazy but i see the massive potential in this space and this project. We could absolutely run out of tokens at some point and buying them back from the market (if allowed to legally) would be a real smart move.

The Rate Lock concept is neat.

I think early node incentives are important. It decreases our own need to spend on data storage resources during a time when we need to manage expenses well. Node operators have a ton of expenses to pay, while staked token owners do not. For many early days, months, maybe years, rewards will not “seem worth it” to many. Yet the node operator costs continue every month, the staked tokens are one and done.

I’ve been thinking about an ongoing stipend to node operators who have a 95% uptime or more. This stipend would be paid in XYO tokens added to the node operator’s own stake.

I also think a fraction of the XYO paid for a query itself should go to node operators. 10% if opted in to add that payout to stake, 5% immediately liquid.



Thanks for the feedback! I’m also weary of the burn since reserve can be used to add true value to the network rather than the playing the scarcity (gimick) game. But since the burn seems to be well socialized and desired at this point, there’s some serious risk of community recoil if it was taken off the table.

I think Rate Lock does a good job of catalyzing functional growth, while your 5% or 10% for keep vs. stake does a good job of promoting scarcity and monetary value in the long term.

RateLock = 5% *100/n + KS

Where KS is keep/stake and is 5% or 10%

Of course the actual percentages I’m calling out are notional.

However, and this is important, we will still run into the problem of the fact that its economically irrational to run a node if it’s cheaper to just buy tokens. This is why I have the “creation reward”. It’s high value but delayed. So one can justify running a node for a year (or more) when they’re guaranteed some amount of tokens after some period of up time. It allows me, as a potential operator, to be comfortable with eating node costs in the short term.

The economic rationality has to exist for all asks. If were asking people to start a node, we have to answer the “why should I?” question beyond “XYO is really cool” . The answer becomes “it is economically rational to front node costs when you’re guaranteed X tokens after Y time”

So we have true incentive and token value arising from each facet of the reward system…

Creation reward = start a node
Rate lock = start now
KS = maintain scarcity of the token

You could even vary the creation rewards with minimum stake time
500K for 6months
1.2M for a year
3M for 2 years min stake time.

All of these promote continued node operation. And they all promote value to the network which gives value to the token beyond “scarcity”

I’ll work on expressing total node owner return mathematically and present later.

Currently at the 9-5.

1 Like

@StatusQuoKiller This is amazing.

I just updated this XIP. You’ve officially created XIP-4. :partying_face:

I’ll get this tweeted out to the community and have our devs review as well. I’ll also dive into it.


Thanks @scott !!
I’ve got some refinements and clarifications in mind. I will format in more of a white paper context and provide. Hopefully tonight or tomorrow morning.

Feel free to hold off socializing until I submit.

1 Like

Seriously impressed with this write-up from a community member.

Why not charge “rent” to the stake-only users piggybacking off someone else’s node? Some percentage of what the staker earns perhaps goes to the node owner? I would think the node owner would be incentivized to advertise their node and get the word out. Promote their own node and XYO at the same time.



My long term vision is to create a web site that let’s node owners advertise their rigs and reputations to solicit stakers. This is only reasonable when node owners benefit from increased stake on their nodes.


@StatusQuoKiller sure, not knocking your ideas, it’s seriously impressive. Just wondering if an automated way to send part of the proceeds of a stake payout to the node owner is another way for them to benefit. You could even just charge every staker “rent”, but if you are staking your own node that rent just comes back to you. I don’t know if that would make implementation harder or easier, just an idea.

One other idea (may not belong in this XIP) is the idea of a small amount of every generated reward coming back to a community pool… NAVCoin has something like this… they use it to incentivize projects that grow that coin:

Again, super impressed you wrote this up. I look forward to following this XIP.


I like your example. Makes me wish I could afford to run a node!

1 Like

Thanks @_ryan! I’m glad someone is reading this Haha.

My comment was in line with yours. I mean to say that were on the same page. The rate lock is essentially what your proposing here. It’s a percentage of the staked rewards as they are earned - basically rent as you put it.

I’m going to refine and clarify these ideas more formally tonight. Thanks for joining the conversation :slight_smile: helps me convince myself I’m not crazy for thinking so much about this stuff Haha.


Very cool keep going forward God Bless Scott your a true visonary …

1 Like

what sort of cost are we talking about to run a node? I have a node on the WAVES platform that I have someone running for me. Been like 2-3 years now. I’m iterested


Team, I’m hosting my revision of XIP4 at the link below.

XIP 4 - Node Incentive Framework

It was necessary to move to a portable document format to support equations, tables, general organization, etc. I also find this format more shareable than the forum post lends itself to.

Thanks all for the input so far - looking forward to more conversation.

@scott @pizzamind @_ryan @silk35