Awesome yes this would prevent this from happening!
Two more notes I have on TransferStake:
- There are still large fleets out that are staked horizontally 15k fleet. Post PIP-22 and PUP-21, they will be doing 4x the amount of RPC work for same amount of rewards as a 60K node fleet. Not Ideal because RPC work should be the basis of costs (consumes memory/cpu). I suppose the reason behind not unstaking is that the 21 wait period is too penalizing for them to consider unstaking. TransferStake will allow nodes to consolidate.
- To my understanding, with non custodial staking, users can stake the operators node as long as it has their public key. This is new information to me. If true, we are already setting this precedence and the potential attack vector in the proposal may not uphold (theres also a large montenary incentive to NOT do this). So multisig may not be required. I will verify after activation.
- After verification, I will be posting a final specification and looking to push it to vote. So sometime between Sept 1 to Sept 5.
2 Likes
I find this paragraph to be self-contradictor in that it posits that not taking action results in undue placement of validator responsibility in the hands of small node runners while simultaneously claiming that the result of the proposal will be diversifying validator responsibility into the hand of small node runners.
More importantly, the posited expected behavior from passing this proposal is 100% opposite to what I expect to be the result of the proposal. As an investor in the āsmall-to-medium node runnerā category (I run one node that competes for a validator slot plus have some additional tokens in a fractional pool) this proposal provides me and others like me zero relief in case of getting outbid for a validator slot (we have no other node to slush into while waiting to accumulate enough tokens to open a second node) while providing near-frictionless slush optimization to large node runners. The resulting differential in friction between small and large node runners will cause the lost-opportunity risk for small node runners to be much higher than for large node runners, resulting in large node runners being willing to risk more to compete for a validator slot than small node runners (since the large node runner can quickly slush into an alternative wallet if they miss out, and the small node runner cannot). This will result in small node runners all but being priced out of validator slots and therefore validation being further concentrated into the hands of a few big node runners or custodial node providers.
The above is especially true if sub-MinStake TransferStake is enabled. If the lower bound of TransferStake is set to MinStake, as in the original proposal, then there is no friction differential in the sub-MinStake zone since it is not allowed. Friction differential is not as pronounced in the super-MinStake zone, since in this case even the small node-runner by definition has sufficient excess tokens in the one node to at least open a second 15k node.
For this reason I recommend that the original version setting min TransferStake to MinStake be what gets placed into final draft language of this proposal for putting to a vote. I will be dropping a separate complimentary PIP shortly that will deal with the sub-MinStake zone in a manner that has no friction differential between small and large node runners.
The original motivation put forth in this proposal is fulfilled by enabling TransferStake between nodes owned/controlled by a single node runner (including those in the custody of a custodial node provider). I am in favor of this use case (with the caveat of keeping the original lower-bound MinStake as originally proposed for reasons stated above). I am not in favor of the use cases that have been suggested sine then, such as enabling quick switch to an alternate provider that is promising a better return or better fee structure. Such switches, IMO, should be subjected to the same rules that apply to other unstaking purposes (currently 21 days, though i am separately open to making this lower for all use cases).
The first question is: is there an implementation that can accomplish the original use case while prohibiting the other suggested use cases. Ie., double-signing to prove ownership of both the send and receive wallet as I think came up in discussion or otherwise? If so, can that be spelled out.
Second: Are you willing to draft the language of this proposal so that this proposal only covers the use case of proved ownership of both send and receive wallet? A perfectly fine draft language (and my preferred in order to be as efficient as possible in dev work) would be to propose building in the code to allow cross-owner transfers but that for the purpose of this proposal a new paramater (eg EnableNonSignedTransfer) would by default be set to prohibit this behavior and that it would take a separate PUP to enable this feature.
When I refer to small to medium node runners, I am also referring to those who stake with custodial node providers and delegate their coins to them as well. There are a significant amount of them, and validator delegation is definitely a plausible scenario in the future. The situation is also dynamic based off how awarding (or even not awarding at all!) the block proposer rewards are - and such, this approach allows for flexibility for all.
The intention was to allow out bidded validators to transfer their stake to horizontally scaled servicers, i.e if they were previously a validator (outbidded) & staked ~62000. The other ~2000 pocket is left in without providing value. That being said, I guess they could always up their stake to 75k, then transfer stake. Doesnāt seem ideal. Given the concerns and ever so changing dynamics, Iāll consider a DAO controlled parameter for this as well potentially
This proposal does not have this in scope. In order to get TransferStake across the finish line in a realistic time manner (keep in mind, engineering is still on rather the bandwidth constrained side and focus is V1), one of the design principles in mind is definitely KISS (Keep it simple stupid). I would suggest that node providers set their own ātransfer stakeā guidelines instead of delegating this to the protocol.
I understand small node runners includes those staked with custodial providersā¦ as does large node runners. I also understand the flexibility being provided to large node runners. I am not seeing the flexibility provided to small node runners (meaning sub-MinStake). Are you saying this proposal provides a mechanism for the small node runner to TransferStake from the missed-validator node directly, eg., to a fractional pool provider? He would have no visibility into node addresses etc to make this even possible.
Separate question: For a couple weeks in August, it seemed like this kind of mechanism may be a pressing system need as validator cutoff was moving daily. But cutoff seems to have settled into a ānew normalā with little movement for the last week or so. Given that, how pressing is it to add this capability to pre-v1 work flow?
1 Like
It can happen, yes. The public key / node addresses are public. I think my point was more so that fractional pool providers are unlikely to enter the validator system given the monetary inefficiency / underlying implications of being outbidded.
Are you referring to implementing TransferStake into V1 protocol? To be honest, I donāt think it will be a problem and rather trivial assuming the specifications are outlined clearly in V0. But itās not something V1 would have to tackle right off the bat, as thereās much more pressing / important details to take care of right now.
I really want to highlight this is another reason why I think TransferStake is needed. What if the DAO decides 5% is too low, letās raise it to 20%? Or being devils advocate, the DAO considers that the validator set in terms of value is inflated, letās lower it back to 1%? Both drives the action of node runners unstaking just to reconsolidate again. I think these are all socially and economically driven decisions and opening up TransferStake allows for more levers to pull in the future.
Agreed.
No, I meant to ask, how pressing is it to add this to v0 as opposed to waiting for v1
I also like this proposal. It would be useful for noderunners like myself that wish to consolidate. Couldnāt we add a passphrase requirement to prevent unauthorized people from staking to your node? We already have passphrases for staking.
Unstake command already prompts the user for the <fromAddr> account passphrase. It would be a logical extension from this to prompts the user for the <receiver_output_address> account passphrase since this address becomes the new (I think?)
Per our offline conversation to prevent some pingponging:
- Enabling multi signature will not prevent two parties from transferstake since both parties can just sign it.
- MSA brings up a great point about the unknown factors of enabling such operational effiency and I propose two things to make this more seamless and giving the controls back to the DAO if we ever need to use them - which are disabling TransferStake (curious if we can just do this via feature flags) and providing a customizable
MinTransferStakeamount that the DAO can control set atMinStake.
I will need some more time to create the final spec (maybe next week instead of Sept 1-5)ā¦ but look forward to all the conversation in the mean time.
Thanks. Sounds good to me. I look forward to seeing final spec
I agree with the premise of the idea. Iāve also been thinking about how to solve these issues. I echo some of the security concerns of others.
I think we can agree on the outcomes of something like TransferStake:
- Enables greater competition (leading to lower prices) among large node runners by allowing for easy movement across nodes
- Pocketās economics will continue to change in the near to medium term, and the ability to easily move POKT to other nodes allows for much relief in this landscape
Thinking about solving this from first principles Iād like to offer a thought experiment:
What if we had DAO treasury be the counter party for a loan to transfer anyoneās stake among node runners?
You would need a neutral facilitator and/or a safe, open market for this to work.
The DAO could do this for a nominal flat fee or a % of the yield generated during the unstaking period. This fee could either be earned by the DAO, burned, or kept by the facilitator.
The foundation would be a good neutral facilitator, but I hesitate to delegate more to the foundation. I wonder if there was a multisig managed by members of the community that was topped up monthly and whether that reduce some of the burden (this may be risky due to not having threshold signatures native to Pocket yet).
It makes sense for the DAO to be a counter party due to rates likely being being infeasible with others being the counter party (e.g. staking yield would exceed this lending yield). The DAO would be the ideal candidate to facilitate with minimal rent extraction for the benefit of the ecosystem.
Just some thoughts to try to solve this from a different angle. A lot of the concerns would be alleviated by some neutral committee or software with agreed upon checks related to some of the concerns raised. Not saying this shouldnāt be done on-chain via TransferStake, but looking to take things off-chain to keep the protocolās risk and bloat minimal is worth exploring.
1 Like
It is an interesting thought experiment. Iām not sure I would want to see the DAO/DAO Treasury get in the middle of provider competition. Seems to open too many doors for possible - or at least perceived - bias, preferential treatment or favoritism. And also opens to at least the perception of diversion of DAO energy from its primary purpose which may cause a dent in investor faith in POKT;
Pushing this to various degrees of āarms lengthā from DAO via a āfacilitatorā may resolve the above concerns , but the more arms-length you make it the more risk of non-repayment or graft is opened up due to reliance on a ātrustedā 3rd party. Iām not at all saying its not doableā¦ just the risk needs to be managed.
That being said, your thought experiment does open up two broader areas for discussion: (1) there is nothing that says that the fee for all on-chain services must be 0.01 POKT. If on-chain "bloat"as you put it is allowed to give functionality to a certain group that another group will never have occasion to use, and especially is offered as a convenience, rather than a necessity, then it is fair that the users of the service pay a premium for its usage. What if you take whatever flat fee or % you had in mind and bake it into the onchain fee of TransferStake. (e.g., FEE = 0.2% or 10 $POKT , which ever is greater)?
Second, a broader discussion of capital management of the DAO treasury is needed. There may be various useful ways to put the funds to work to earn a return and/or facilitate a new burn sink. This bears exploring in the future.
1 Like
Thinking about it furtherā¦ anyone (including DAO Treasury could set up an unstake-loan-as-a service if the mechanism were in place (which Iām not sure it is) to have the unstake amount sent to the service-providers address. No questions asked as to purpose of the unstaking. If it is to switch providers, thatās the owners private busiess) (Analaogy: tax refund loan by tax prep rpoviders)
Another thought that I had been floating around w some others is to do something similar on chainā¦ differential fees for standard and expidited unstaking (Analogy: UPS or FexEx shipping rates). eg FEE (providing a new sink for the token):
- standard 21 day delivery: 0.01 $POKT
- 14 day delivery : greater of 1 $POKT or 0.1%
- 7 day delivery : greater of 3 $POKT or 0.3%
- 3 day delivery : greater of 10 $POKT or 1 %
- 1 day delivery: greater of 50 $POKT or 5 %
Historically, fees have generally been for spam protection. I am not sure how I feel about changing the definition of this. It can result in arbitrary āPOKTā sinks depending on our token economics and can result in a carrot and stick dynamic. Not sure if that is ideal. Iād like to see this built upon more, but perhaps in a future proposal.
Absolutely! I did not mean to imply to add it the scope of this proposalā¦ I was just continuing the thought experiment that @o_rourke started, Items to explore in the future.
I like this proposal. It will be very useful, We wonāt have to wait 21 days to unstake our nodes if we wanted to consolidate or break a higher stake node to smaller ones.