stacks-network / stacks-core

The Stacks blockchain implementation
https://docs.stacks.co
GNU General Public License v3.0
3.01k stars 667 forks source link

Node Commission Rate #4955

Open andrerserrano opened 3 months ago

andrerserrano commented 3 months ago

Is your feature request related to a problem? Please describe.

Currently, it is impossible for Stacks Signers to earn a fee commission on pooled assets in a non-custodial way. This creates legal and operational challenges for signers. In order to collect a fee for their services, they must take custody of the earned BTC and distribute the rewards pro rata, minus the fee, which is typically set to 5-10%. This means Stackers take counter party risk for their BTC rewards, entrusting the signer and smart contract to distribute the rewards. Since most signers are non-custodial by nature, this creates new challenges to support the Stacks network and scale the amount of STX stacked.

Describe the solution you'd like

In other ecosystems, it is possible to set a "Node Commission Rate" which defines the maximum commission that a validator can charge. This would simplify this process and reduce risk for both signers and stackers.

Describe alternatives you've considered I am not aware of any alternatives.

Additional context I understand this may be a non-trivial change since it requires an upgrade to the Stacks node. I would like to understand potential alternatives to reduce friction for signers and solve what is a currently a significant pain point. Appreciate any thoughts or perspectives!

jcnelson commented 3 months ago

Stackers are compensated for singing blocks via PoX rewards. If Stackers want to delegate that responsibility to a 3rd party, then it's up to that 3rd party to figure out compensation from the Stacker on their own.

jcnelson commented 3 months ago

On this particular point:

In order to collect a fee for their services, they must take custody of the earned BTC and distribute the rewards pro rata, minus the fee, which is typically set to 5-10%. This means Stackers take counter party risk for their BTC rewards, entrusting the signer and smart contract to distribute the rewards.

First, absolutely nothing is forcing Stackers to offload their signing responsibility to someone else. Each Stacker makes a choice: run a signer, or delegate it to someone else and deal with whatever economic and legal tasks that are required for that to happen.

Second, to speak specifically to delegated stacking, it is already possible (and has been possible since the beginning) to have the BTC accumulate to a Bitcoin address that is collectively controlled by the delegates. A naive n-of-n multisig address would work for up to 256 users. More elaborate schemes like FROST and WSTS are possible today, where BTC accumulates to a taproot address that can only be spent if a threshold of delegates collectively produce a signature (Stacks has supported this since 2.1, which introduced support for taproot PoX addresses). Even more elaborate options are possible with things like DLCs or BitVM, or multisigs that involve external legal entities like trust funds, LPs, LLCs, etc. My point is, there are many options for non-custodial and otherwise legally-flexible PoX reward accumulation and distribution on the table already. No one is or has ever been forcing a pool operator to be responsible for accumulating and disbursing PoX payouts manually and having to deal with the economic and legal tasks that go with it -- there have always been alternatives.

Unless I'm missing something, I don't see what the issue is here?

andrerserrano commented 3 months ago

First, absolutely nothing is forcing Stackers to offload their signing responsibility to someone else. Each Stacker makes a choice: run a signer, or delegate it to someone else and deal with whatever economic and legal tasks that are required for that to happen. This should not be surprising to anyone, since this is how the real world works -- if you want someone else to do something for you, it's up to you and that other person to work together to figure out an agreement for doing so.

I think this misses the point of what signers have to do in practice. Right now, we do have a robust ecosystem of signers and stacking pools, yet we are lacking some of the tooling and features for them to do their job well.

Let’s say you’re a signer that wants to create a new stacking pool. In order for this to be a viable business, you have to collect a fee somehow. But your business is non-custodial! There are legal and operational reasons why you don’t take custody of the stacked STX. The way the Stacks signer is setup today creates new hurdles for this end.

We are seeing this in practice:

This feature is well established in other ecosystems as we can see from Polygon, Cosmos, Polkadot. Furthermore, none of the alternatives proposed would present a viable solution to this problem today. Even if it's theoretically possible to overcome this challenge today, it comes with a lot of operational challenges and I would love to find a way to improve this for our signers.

jcnelson commented 3 months ago

Let’s say you’re a signer that wants to create a new stacking pool. In order for this to be a viable business, you have to collect a fee somehow. But your business is non-custodial! There are legal and operational reasons why you don’t take custody of the stacked STX. The way the Stacks signer is setup today creates new hurdles for this end.

If you are using delegated stacking, then you're not taking custody of your clients' STX. Their STX never leave their wallets; they are simply locked. So it sounds like this isn't a problem.

You are, however, accumulating BTC via PoX in proportion to the STX your clients delegated to you. Whether or not that creates legal legwork for you depends on what kind of a priori agreement you made with your clients when they delegated to you. In general, nothing requires you to disburse the accumulated BTC to your clients or perform any sort of custodial duties; that is only one business model of many, and one that a signer imposes on itself. For example, you could imagine an alternative non-custodial signer business where the signer simply rents the STX from its clients for an up-front USD payment and keeps the BTC for itself.

I'm not seeing how it's blockchain team's problem to help signers bypass the difficulties of a business model they imposed on themselves?

This feature is well established in other ecosystems as we can see from Polygon, Cosmos, Polkadot.

We did better -- we provided the tools to implement automatic BTC disbursement without nailing them to the consensus protocols. This way, signer businesses aren't limited by our imaginations today of how they can make money.

Furthermore, none of the alternatives you proposed would present a viable solution to this problem today.

Please elaborate. Have you tried any of them?

Even if it's theoretically possible to overcome this challenge today, it comes with a lot of operational challenges and I would love to find a way to improve this for our signers.

If by "operational challenges," you mean "someone has to do a bit of non-consensus, non-blockchain-related technical legwork to automate the disbursement of BTC accumulated to a client-controlled shared BTC address in order to reduce legal legwork on the operator's part," then sure. This is a workflow that, by design, would fall squarely on the shoulders of signer businesses -- it is exactly the kind of thing signers are incentivized to build in order to attract business from other signers.

I don't think this issue belongs on the blockchain repo. It's not our job to build signers' businesses for them. It's our job to give them the consensus-critical tools they need to build it themselves, in a way that maximizes signer flexibility.


The thing you're after -- a "node commission rate" -- can be built today without touching the blockchain code.

MattBlockdaemon commented 3 months ago

Blockdaemon is currently unable to allow our customers to Stack with us due to difficulties around taking commission fees in a non-custodial way. Doing it in the way proposed by @andrerserrano in this message is advantageous for the following reasons:

wileyj commented 3 months ago

Following up here - this came up on our daily call, and we're planning to discuss this week what options are available. The general consensus was that this shouldn't be a part of the core blockchain codebase, but there are some other options that will be discussed around the ideas raised here. @MattBlockdaemon We'll reply back once we have a chance to go over the various options raised this morning.