How to measure the revenue of a staking based allocation mechanism?

[h4x3rotab]

Fee based payment is widely used. Typical protocols are Ethereum and Arweave. We can directly sum up all the fees together to track the total revenue. However, it's not the only way to allocate resources.

Another approach is staking. With a resource pool, the resource that a client can use is proportionally to the amount he staked. One example is EOS, where you stake some token in exchange to the CPU cycles within 24 hours. The Graph also requires the "curators" to stake tokens to projects, and the amount staked affects the income of the indexer. (Though there's the query fee on The Graph, but it seems less than the opportunity costs of staking. No to mention the query fee is only charged in the hosted service so far). There are more examples. The common part is the resource is allocated to the clients based on their stake.

How should we count the "revenue" for these projects? We want to address the actual usage of the network, and this can be typically measured by users' willingness to pay for the service. Hence the fee model is straightforward.

When resources are allocated by stake, it doesn't mean the demand end has zero cost. At least they have the opportunity costs, and it can be significant. When the demand grows, the user who doesn't have enough tokens to stake will start to lend from others, effectively creating a lending market as an alternative to the fee-market. It can map the staking mechanism back to the simple fee payment model, which is counted as the protocol revenue.

Staking impacts the system in various ways. First, staking increases the demand of the token in the market, and can potentially drive the price up, benefiting the token holders. Second, when the supply end gets the payments through inflation or subsidy (a preallocated pool to reward the supply end just like Ethereum block reward), the circulation supply increases, diluting the value of the stake. In a free market, the impact should be reflected by the interest rate of the lending market.

With the above argument, an approach is to project the stake (TVL) to the corresponding lending interest, or compare the TLV (by the demand end) between the staking based projects directly. It measures how much the clients are willing to pay for the service.

[SamuelHaefner]

In many protocols, you not only stake to consume services but you can also put down some stake for consensus provision. Typically, this gives you some staking reward, which you can take as the opportunity cost for consumption.

If that is not the case, then I agree that it is a good idea to look at lending market rates.

Another idea would be to explicitly distinguish between protocols having a staking-based payment and protocols having a fee-based payment, and to report total value staked for the former.

[h4x3rotab]

Another approach is to estimate the demand end payment from the reward to the supply end, assuming there's a equilibrium in the long run.

Among the existing projects, Pocket Network also adopts a staking based demand end resource allocation. According to Pocket's onboarding issue (#49):

Developers stake POKT once for a guaranteed amount of requests per session (4 blocks at ~15 mins per block) for the lifetime of that stake. The amount of POKT staked required is directly proportional to the number of relays required.

As of now, Pocket calculates the revenue based on the number of the relay * reward to validator per relay, as described in the issue:

However, unlike traditional block rewards, Pocket Network’s is dynamic; where POKT rewards are directly proportional to the number of relays and transactions fees in a given block. Nodes earn 0.0089 POKT per relay served and validated.

... and written in the code:

web3index-org/cmd/pocket.ts

Lines 139 to 141 in 3c2a83c

	revenue =
	(totalAppStakes / totalPOKTsupply) *
	(successfulRelays * relayToPOKTRatio * currentDayPrice);

[crisog]

Another approach is to estimate the demand end payment from the reward to the supply end, assuming there's a equilibrium in the long run.

Among the existing projects, Pocket Network also adopts a staking based demand end resource allocation. According to Pocket's onboarding issue (#49):

Developers stake POKT once for a guaranteed amount of requests per session (4 blocks at ~15 mins per block) for the lifetime of that stake. The amount of POKT staked required is directly proportional to the number of relays required.

As of now, Pocket calculates the revenue based on the number of the relay * reward to validator per relay, as described in the issue:

However, unlike traditional block rewards, Pocket Network’s is dynamic; where POKT rewards are directly proportional to the number of relays and transactions fees in a given block. Nodes earn 0.0089 POKT per relay served and validated.

... and written in the code:

web3index-org/cmd/pocket.ts

Lines 139 to 141 in 3c2a83c

	revenue =
	(totalAppStakes / totalPOKTsupply) *
	(successfulRelays * relayToPOKTRatio * currentDayPrice);

Hey @h4x3rotab, the reason why its different in code is because the issue is outdated. Actually, the difference is this part (totalAppStakes / totalPOKTsupply) which will always be a number under 1 because total staked cannot go over total POKT supply.

Why did we update the formula? Because Web3Index is only measuring the demand-side fees. In our staking model, users pay through dilution. So we are only taking in count revenue on that percent of POKT that has been staked, not the amount of relays alone. If the formula was exactly as written in the issue (as it was initially) our revenue would be even higher.