Name: Continuous payment of fees Category: Protocol Status: Draft - Rejected Scope: Allow Darknode operators to collect fees second-by-second without needing to submit Ethereum transactions.
Overview
This proposal introduces the Operator Fee Token (OFT). This token is automatically paid to operators per-Darknode per-block. For example, if an operator owns 10 Darknodes, then the operator will receive 10 OFT tokens per block. OFT tokens can be burned for a proportional share of redeemable fees. For example, burning 1% of the OFT supply entitles you to 1% of the redeemable fees.
Fees are paid to a non-redeemable pool. Every block, 0.0002865% of the non-redeemable pool is moved to the redeemable pool. Assuming Ethereum blocks are ~10 seconds, this equals a total payout of ~50% per epoch (the same as it is right now). At any point, Darknode operators are able to burn some or all of their OFT and redeem their share of the redeemable pool.
Background
Right now, Darknode operators collect fees in discrete intervals through a process called “claiming”. Fees are paid to the Darknode Payment contract on Ethereum and at the end of the epoch 50% of the fees in that contract can be claimed by Darknode operators. However, for the claim to happen, each Darknode must explicitly submit an Ethereum transaction to call the claim function on the Darknode Payment contract.
There are several drawbacks to this approach:
Darknode operators must wait until the end of the epoch before fees are accessible. This creates opportunity loss, where Darknode operators are unable to utilise fees for an entire epoch.
Darknode operators are bound to receive the fees. This means that the operators are unable to delegate fee collection to other addresses (for example, one could imagine that it would be desirable for an operator to automatically delegate their collected fees to a contract).
Darknode operators must spend ETH so that their Darknodes are able to call the claim function. In the latest epoch, each Darknode had to spend just under $7 USD to claim. This essentially doubles the operating costs of a Darknode, and requires regular attention from the operator.
In the future, we want to be able to compute fees on RenVM instead of on the minting chain (e.g. Ethereum). The use of an explicit Darknode Payment contract, bound to pay fees to an exact address (the operator), does not make for a smooth transition away from Ethereum.
Darknodes need to claim fees every epoch. This puts restrictions on how often epochs can happen. Having 24 hour epochs would cause Darknode operators to spend $6 per day per node (which is clearly unacceptable). See RFC-000-001: Continuous payment of fees.
Details
The OFT will be an ERC20 with some unique implementation details:
No explicit mint function.
OFT has a special balance_of implementation that deviates from the norm:
This will result in the balance_of function returning different values even when no transfer are made. However, this will only be observed for operator addresses. All other addresses remain unaffected, because num_nodes[addr] would be zero.
OFT transfers must do balance[addr] = balance_of(addr) before running the usual transfer logic, for both the sender and receiver, and must set updated_at[addr] to the current block for both the sender and receive.
Darknode being de/registered must update num_nodes[addr] where addr is the address of the operator. The same transaction must also set balance[addr] = balance_of(addr) and set updated_at[addr] to the current block.
The FeePool will be the contract that receive all fees from the Gateways (all Gateways for all renTokens will send their fees to the same FeePool contract).
There will be a redeem function that burns the OFT out of existence in exchange for a share of the redeemable fees. This function also updates the redeemable fee amounts. Some pseudo code:
def redeem(amount, to):
OFT.transferFrom(msg.sender, this, amount)
for token in renTokens:
redeemable[token] += (token.balance_of(this) - redeemable[token]) * pow(1 + rate, now - updated_at)
update_at = now
for token in renTokens:
token.transfer(to, redeemable[token] * amount / OFT.total_supply())
The rate variable in the FeePool should be subject to governance by RenVM. Initially, the value will be set to 0.0002865% per block so that the payout rate of the FeePool matches the current payment mechanism (50% every 4 weeks).
As is seen in the pseudo-code for the FeePool redeem function; gas is spent withdrawing every token every time OFT is burned. While this approach might be an acceptable overhead, an alternative is to have a different OFT for every available token that fees can be earned in. See RFC-000-001: Continuous payment of fees.
Implementation
Develop, test, and audit the OFT contract.
Develop, test, and audit the FeePool contract.
Upgrade the Gateway contract to mint fees to the FeePool.
This is a well written proposal, however I am concerned that this is being discussed as from a priority perspective this should be quite far down the list. Optimizing how users can withdraw darknode fees only makes sense if the fees are meaningful. I think I speak for everyone here who would much rather you focus on integrating further chains/use cases than this.
I’m a huge a fan of what you guys are doing but this feels kinda off topic at the moment given the cratering REN token price.
As far as I understand, this RFC is only intended to reduce additional GAS costs? If that’s the case, then it might be less importance now. Darkode earns >$250 per month, up to 20% of monthly expenses from rewards - this is acceptable. Another question is that after moving to Zero stage, the node’s computing power (hardware) requirements may change? Right? But even in this case, the cost of gas is not significant. Perhaps there are adding reasons for creating an OFT token?
I will support any suggestion from Team, but I really would like to see new chains and new integrations right now. And I would also like not to stay long at Sub-Zero stage.
Thanks for the post. I think this is a good idea! While I do agree with other users that this may not be of top priority, I think it’s important to realize that any changes made to help the overall darknode experience is worthwhile! We obviously want to see more sign ups and we want to keep as many darknodes from leaving.
Although I agree with the general sentiment that this does not seem high priority, I do see that there could be 2nd and 3rd order effects of this capability that may not be immediately obvious. I’m curious what Ren’s rationale is for putting this as the first RFC; I’d bet this is only part of a bigger picture.
Personally, I’m supportive of this kind of functionality for the following reasons:
Most obviously, increased security by reducing total withdrawable rewards on a constant basis rather than at the end of each epoch (because operators can continuously withdraw)
Biggest impact, increased smooth flow of transactions and reduced gas costs for everyone especially those operating multiple nodes (computing fees occurring on RenVM would aggregate transactions to the VM rather than across multiple chains… these savings will be multiplied as RenTokens are put on multiple chains)
It seems we’d be able to split rewards between multiple stakers** in one node allowing partial stakers that do not have the minimum 100k $Ren tokens (because rewards are represented in fractional tokens)
Potentially, we can have daily registrations and de-registrations (because rewards aren’t locked on a 28 day basis) but there must be appropriate disincentives to deregister and incentives appropriately lower than operating a whole node yourself
Speculatively, there could be potential to stake OFTs in a yield bearing pool in the future (because it will be its own erc20)
However in terms of risk, I’m curious how timing of claims (after large mint/burns or holding OFTs and withdrawing in the future when total available rewards are higher) would impact rewards, to @noah’s point. I’d hope that this functionality does not cause node operators to compete against each other to time their rewards.
how difficult would this change be to implement from a technical standpoint. I am mostly an amateur with computer coding. As long as any changes are simple enough to follow as they are with the dark-node instructions.
Adding new chains is definitely a higher priority, but this is already being worked on and should be coming out reasonably soon. A few things are worth pointing out that apply in general:
Prioritisation of the implementation of proposals only happens after the RIP process has been passed through successfully. An RFC is not the place for prioritisation discussion unless there are dependencies involved (e.g. implementing one RFC would be harder/easier based on whether another RFC has been implemented).
The discussion and development of one feature does not mean that development of other features must halt. It is important to do these things in parallel, because the team is able to work on multiple things simultaneously, so having a pipeline where we can be discussing and designing features while implementing other features is important.
With respect to this RFC specifically, it is actually quite important to understand how fees work when thinking about supporting new chains. From the RFC itself:
In the future, we want to be able to compute fees on RenVM instead of on the minting chain (e.g. Ethereum). The use of an explicit Darknode Payment contract, bound to pay fees to an exact address (the operator), does not make for a smooth transition away from Ethereum.
This is an important point. What happens when we support BTC to Acala? Neither network has anything to do with Ethereum, so how will fees aggregate into an Ethereum contract? In the case of this RFC, this problem is not solved, but the addition of OFT definitely makes this problem easier to solve in the future (for example, you could keep fees in RenVM but still listen to OFT burn events, or you could allow OFTs to move between chains and be burnt where relevant, etc.). That is out-of-scope for now, but this RFC certainly opens up new possibilities thanks to the flexibility of tokens.
Good question! The implementation should be relatively straight-forward. OFT itself is not a huge departure from an “off-the-shelf” ERC20 implementation. FeePool only has a single function, which in practice wouldn’t be much more complicated than the pseudo-code posted in the RFC.
An operator’s withdrawable fees could start decreasing if there’s an influx of new darknodes that isn’t paired with an increase of network usage.
This is true, however, I actually think that this is a good thing. New nodes joining the network are still participating in keeping previously locked-up funds safe. This means that it is important to incentivise them, even when new minting/burning is not happening. In the current system, this happens because of the 50% payout per epoch. Although there is still a 50% payout per epoch in this RFC, without distributing OFT to new nodes, there is no way for them to get a share of this payout.
Also, one drawback is that operators can’t selectively redeem tokens. Right now, a lot of operators are withdrawing BTC fees each epoch, leaving ZEC and BCH fees to accumulate.
This is a good point, and definitely one that puts a bit of ergonomic stress on node operators. In the short-term, this is definitely an issue (there is gas overhead from the for loop during redemption), but not a deal-breaker. I think having an OFT for each asset is probably the best long-term solution (given that there is no gas costs for letting redeemable fees accrue using this OFT model).
It seems we’d be able to split rewards between multiple stakers** in one node allowing partial stakers that do not have the minimum 100k $Ren tokens (because rewards are represented in fractional tokens)
This is not a direct motivation, however, it is an indirect motivation. Using tokens as an abstraction over “rights to redeem fees” is a more flexible and powerful abstraction than the one that we are currently using. It does lend itself to this purpose, but also many other purposes. I would not be surprised to see all kinds of interesting uses of OFT and supporting multiple stakers may well end up being one of them. Right now, these kinds of options are not available to developers, but with OFT they would be.
Potentially, we can have daily registrations and de-registrations (because rewards aren’t locked on a 28 day basis) but there must be appropriate disincentives to deregister and incentives appropriately lower than operating a whole node yourself
This is a direct motivation for this RFC (and perhaps I should have added a Motivation section to the RFC itself). By not having to claim fees (i.e. spend gas) every epoch, we can dramatically reduce the epoch time (and we want to eventually drop it to 24 hours). You can then allow new Darknodes to come online every day (which helps with security and stability of the network). This will not affect de-registration times, which can be modified independently of registration times.
I’d hope that this functionality does not cause node operators to compete against each other to time their rewards.
Note: this is only an issue when new nodes sign-up. Assuming the number of nodes stays constant, when you redeem your OFT does not matter. Next, remember that the payout is still only 50% per 4 weeks at the proposed rate of 0.0002865% per block. If a big mint happens, and the network suddenly sees $1M of fees, this would potentially encourage a lot of new nodes to sign-up to capture those fees. To get their share 50% of those fees (and 25% of the previous months fees, 12.5% of the previous two months fees, etc.), these new nodes would still need to hang around and secure the network for one month. EDIT: I think we should simulate various scenarios and double-check that this cannot be gamed somehow. It is important that the introduction of OFT will not create “Darknode arbitrage” where profit-seekers try to optimally time de/registering; this could cause instability in Darknode numbers.
It seems like this also introduces a change to the periods in which Darknodes can earn fees. Setting updated_at[addr] to the current blocktime appears to let balances accrue during pending registration and between the start of an epoch and the blocktime in which a Darknode gets deregistered; both periods of time that Darknodes do not currently earn fees.
If I’m not mistaken, setting updated_at[addr] to currentEpoch.blocktime + minimumEpochInterval for registration may prevent accruing a balance during pending registration. Deregistration is trickier because an operator could claim fees for most of an epoch before deregistering in the last few blocks of the same epoch, but deregistrationInterval may be at your disposal to work around that.
The OFT mechanism also opens up the system to allow for any REN holder to stake and receive a portion of fees.
If we were to add a system where any REN holder could contribute to network security and receive an APY that’s still fair to darknode operators, then:
the total notional amount of REN as part of TVB could increase
the market pricing of REN could more accurately reflect the profitability of the network
We would not allow balance accrual during pending registration (all functions on the OFT/FeePool can easily check the registration status of a Darknode before proceeding). However, pending deregistration times would be able to drop to 24 hours max.
The main benefit here seems to be lower redemption fees and increased payment speeds, which I think most node holders would see a benefit too. Couple questions come up in the OFT pools and token.
As more chains come online, a variety of native tokens fees will be collected, and assumably added to the OFT pool, I am unclear on how OFT Pool might account for this. Since the basket of assets would be forever changed from this point, and say an operator doesn’t redeem their fees and instead just collects OFT are they going to end up collecting less or more because of the new native token additions?
Would REN consider listing OFTs on exchanges?
If OFT pools are 1:1 in theory they should equal the value of the pool of assets underneath, however, we all know values in crypto are very volatile and in theory the pool could be subject to manipulation or market forces. I could see people getting excited about purchasing a bundle of assets represented by the underlying OFT, its like mini ETF. I personally like the idea of exposure to the underlying assets that are being minted/burned.
It was mentioned above that there should be an OFT token for every token supported by RenVM. This means that they wouldn’t mix (it makes redemption much easier to think about / implement too).
However, there is no reason we could not build an abstraction token that wraps different types of OFTs. This way node operators can simplify the management of their assets, and as you mentioned, it could be sold on external venues.
We would not explicitly pursue listing OFTs, but I’m sure the market would get around to it pretty quickly.
It was mentioned above that there should be an OFT token for every token supported by RenVM. This means that they wouldn’t mix (it makes redemption much easier to think about / implement too).
A Zapper integration would be terrific in this case, being able to burn your xOFT token to x and then trade x to your preferred asset in one transaction (using Uniswap on the backend).
I do not see the current fee redemption methodology as an issue right now. I do see some of the other benefits mentioned but I do not feel that they are worth the additional complexity. Keeping things very simple comes at some costs but huge benefits.
The benefit of the 28 day Epoch is that it prevents knee jerk de-registrations. A decision to de-register can be deferred to just before the end of the epoch - giving a time buffer to reconsider. The proposed 24hr process would mean this consideration time would be lost and I feel many might commit to de-register and later wish they had not.
I like the idea of a token but not for this purpose! I see potential for a token in dealing with continuous fees to cover custody over time as a way of keeping the 1:1 peg between BTC & renBTC and inflating the token instead. So I guess I feel it is just too early in the game to use up our “token” wild card.