Stake-based Liquidity Incentives

[hysz]

ZEIP-31 introduces a stake-based liquidity incentive to the 0x protocol. This draft outlines the design principles and constraints of the incentive mechanism, along with guidelines for its implementation. We encourage relayers, market makers, and developers working on complementary Ethereum projects to help us shape these ideas into a formal specification.

Feel welcome to leave comments below or in this google doc.

See the 0x Staking Specification for the most up-to-date information on architecture, implementation and usage.

1 Overview

1.1 Motivation

1. Encourage user ownership among market makers.
2. Reward market makers that stake ZRX tokens.
3. Align all market participants with the long-term mission and objectives of 0x.
4. Redirect proceeds from arbitrage-driven gas auctions back to market makers.

1.2 Principles

1. Incentivize liquidity providers to invest in the long-term success of the protocol
2. Create a level playing field across all types of assets and classes market makers
3. Minimize overhead and cost, both in terms of gas and effort to participate

1.3 Specification

1. Participate in governance and liquidity incentive programs by staking ZRX (section 2.1)
2. Delegate stake to liquidity providers (section 2.2)
3. Funding self-sustaining development with protocol fees (section 2.3)
4. Earn liquidity rewards on trading (section 2.4)
5. Vote on 0x protocol proposals (section 2.5)
6. Scheduling process for claiming rewards (section 2.6)
7. Setting up liquidity rewards for market makers (section 2.7)

2 Specification

2.1 Staking ZRX

2.1.1 Utility

• Vote on proposals and the allocation of community funds
• Market makers earn liquidity rewards proportional to their trade volume and amount of stake
• Anyone can delegate stake to a market maker and earn a portion of their liquidity reward

2.1.2 Depositing Stake

• Anyone can stake by depositing ZRX into the 0x staking contract
• Stake can be deposited at any time
• ZRX remains staked until withdrawn by the staker

2.1.3 Withdrawing Stake

• Stake is locked up for a period of time before it can be withdrawn
• Funds are frozen and cannot be used to vote or earn liquidity rewards during this lockup period
• The length of this lock up is to be determined
• Stake can be withdrawn immediately so long as it is not delegated
• A lockup period may be implemented in the future to handle edge cases in on-chain governance

2.2 Delegating Stake

2.2.1 Overview

• Market makers can contribute stake on their own behalf
• Third parties can delegate stake to market makers
• Delegated stake can be used in the same ways as regular stake
• Stake contributed by market makers receives additional weight when computing rewards
• A delegator transfers a portion of his voting rights to the market maker (section 2.5)

2.2.2 Incentives

• Market makers can sign a profit-sharing contract that enables them to benefit from delegated stake
• The contract specifies a fixed percentage of future liquidity rewards to be shared among their delegators
• Via delegation market makers can obtain liquidity rewards and voting power without locking up capital in ZRX

2.2.3 Weight of Stake

• Regular stake is always weighted more heavily than delegated stake
• Market makers obtain rewards more cost effectively when staking on their own behalf

2.2.4 Delegating Stake

• ZRX must be staked before it can be delegated
• Anyone can delegate their stake to a market maker at anytime
• Delegating stake comes into affect on the next epoch
• Stake remains delegated until withdrawn by the delegator
• The portion of a market maker's liquidity rewards allocated to delegators is held in a Delegated Reward Pool
• Each delegator owns a percentage of the reward pool
• When a new delegator joins a pool, it would dilute rewards held by incumbent pool members
• Delegators must therefore “buy into the pool” by locking a small amount of ether along with their delegated stake

2.2.6 Motivation for Reward Pool Buy-ins

• Reward pool buy-ins reduce the gas cost of joining a delegation pool
• Absent a buy-in, we would have to record when a delegator joins and leaves a pool to compute their rewards

Note: Reward Pool buy-ins have been eliminated.

2.2.5 Buying Into a Reward Pool

• The buy-in equation is eᵢ = (eₜ / dₜ) dᵢ
  • Where eᵢ is the amount of ether to deposit when delegating dᵢ stake
  • There already exists dₜ delegated stake and eₜ liquidity rewards already in the pool
• The capital requirements of a buy-in will be very low relative to the ZRX stake needed to earn a reward
• Anyone can call a function to payout all delegators and liquidate the reward pool

Note: Reward Pool buy-ins have been eliminated.

2.2.7 Exiting a Reward Pool

• Stake remains delegated until the end of the epoch
• A delegator's share of the reward pool is withdrawn immediately upon exit
• See section 2.1.3 for lockup rules related to withdrawing stake

2.3 Fees

2.3.1 Charging Fees

• Each fill on the 0x Exchange contract incurs a static fee
• The fee associated with a fill operation scales linearly with the gas price of the transaction
• The fee is denominated in ETH and paid by setting msg.value
• The fee is paid by whoever submits the transaction
  • This is the taker in an open orderbook relayer model
  • This is the relayer in a matching / closed orderbook model
  • This is an arbitrary third-party when using contract-fillable liquidity (meta-transactions)

2.3.2 Motivation for Fee Mechanics

• Making the fee proportional to the transaction gas price protects market makers from arbitrage
• A portion of fees currently paid to miners are recycled back into the 0x ecosystem

2.3.3 Accumulating Fees

• The 0x Exchange contract deposits fees into a vault managed by the staking contract
• The fee is associated with the originating market maker and acts as a measure of their trade volume
• At the end of each epoch the accumulated fees are distributed as liquidity rewards

2.4 Liquidity Rewards

2.4.1 Earning Liquidity Rewards

• Liquidity rewards are generated by protocol fees
• Liquidity rewards are paid out at the end of each epoch
• Liquidity rewards are divided between market makers, delegators, and the 0x Ecosystem Fund

2.4.2 Liquidity Rewards for Market Makers

• A market maker's liquidity reward is a function of:
  • The total fees collected across all market makers
  • The amount of stake held by the market maker
  • The amount of stake delegated to the market maker
  • The fees attributed to the market maker
  • A variable subsidy that we add or remove to influence liquidity provision
• 1 Staked ZRX = 1 Reward Credit
• 1 Delegated ZRX = 0.9 Reward Credits

2.4.3 Liquidity Rewards for Delegators

• Delegators receive a portion of the reward for each market maker they have delegated to
• This portion is set once by the market maker when creating the delegation pool
• Each delegate earns a reward proportional to the amount they delegated

2.4.4 Liquidity Rewards for the Ecosystem Fund

• The 0x Ecosystem Fund is a pool of ETH collectively managed by ZRX holders
• A small fixed percentage of the total fees collected are allocated to the fund
• Until the 0x Ecosystem Fund has been created all fees will be paid to market makers and their delegators

2.5 Governance

2.5.1 Voting on Proposals

• Anyone can vote on a proposal using their stake, the stake they delegate, or using stake delegated to them
• 1 Staked ZRX = 1 Vote
• 1 Delegated ZRX = 0.5 Votes for the delegator and 0.5 Votes for the delegate
• Only stake and delegated stake that have not been flagged for withdrawal can be used to vote

2.6 Epochs

2.6.1 Scheduling

• All processes are segmented into time intervals called epochs
• Fees accumulate over an epoch and are paid out at the end of the epoch
• Time-locks for withdrawing stake (and exiting reward pools) are measured in epochs
• All epochs last a fixed minimum time
• The duration of an epoch is to be determined, but will likely be 2-4 weeks
• The duration of an epoch is 10 days

2.6.2 Epoch Finalization

• Epoch T must be finalized before Epoch T+1 can start
• Anyone can finalize an epoch by calling a function in the staking contract that:
  • Computes liquidity reward allocations across market makers
  • Pays market makers and escrows the portion allocated to their delegators (section 2.2)
  • Pays a portion of the liquidity rewards to the 0x Ecosystem Fund
  • Increments the epoch
• Stake and delegated stake automatically carry over to the next epoch

2.7 Setting Up Liquidity Rewards for Market Makers

2.7.1 Registering as a Market Maker

• A market maker calls the staking contract to generate a unique id and associate it with their trading addresses
• The market maker must call into the contract with each of their trading addresses
• For EOA's the market maker signs a message and submits it to the staking contract
• For contract accounts the market maker must implement a simple signature validation function

[satosheth]

My biggest concern is with the community fee in regards to NFT marketplaces. Is increasing the cost of each transaction by $.10 on average (using the historical average) going to encourage relayers to continue to use 0x or turn to another technology where the total gas costs are closer to what the function costs to run on the blockchain? I understand the overall desire for fees, but is there a reason that a value that roughly doubles the gas cost was chosen? Could a smaller fee be used to properly incentive the 0x ecosystem while still not making small-value trades too expensive to perform?

[L-Kov]

Fascinating proposal. I was wondering if you could elaborate around how maker rebates are intended to work in the case of settlement using matchOrders? Specifically in the following case.

Suppose there exists an order, let us call it orderA which was created and signed by userA. UserB intends to take this order, but, instead of becoming the direct counter-party to orderA, calls matchOrders including orderB which they privately created and signed. In this construction we will also assume both users have a staking intensity of 1 (maximizing their potential fee collection). UserB is thus required to pay the fee equivalent to their gas expenditure X, but also earns a rebate Y. Let's assume both users are credited with 50% of the fee share and thus entitled to the same maximum rebate, Y (where 2*Y <= X). Of course there is a net loss for userB, but depending upon the specifics of the implementation userB might be able to claim some proportion of the fee share that, in a the case of direct usage of fillOrder, would be completely associated with userA.

My question then is: How are fee shares calculated in the case of fills via matchOrders?

Edit: The above construction fails to state the key insight that the matchOrders function requires substantially more gas than the fillOrder function (>=2x?). Perhaps this alone negates any special case.

[willwarren89]

@dwbauschlicher Almost all of the historical 0x trades used in our protocol fee analysis were trades on liquid erc20 markets where trade settlement is more time sensitive than the typical NFT trade. I imagine the distribution of protocol fees for NFT trades has a lower average/median value. Will see if I can pull this data and provide a more definitive answer. We'll have a smaller data set to work with given the lower frequency of NFT trades on 0x.

[benjiqq]

@hysz could you elaborate what this means in practise for Market-making on 0x? I think any proposal should highlight the benefits for Market-makers very clearly as opposed to other platforms i.e. central exchanges. A google doc or PR to comment on would be helpful.

"Encourage user ownership among market makers." user ownership?
"Reward market makers that stake ZRX tokens." what's the relationship with MM and holding ZRX?
"Reward Pool Buy-ins" what are reward pools?
"2.6 Epochs" what does this refer to?
"2.7.1 Registering as a Market Maker" what is the benefit?

More explanation from practical MM perspective (in my view at least):
https://forum.0x.org/t/marketmaker-incentives/341

[hysz]

@benjyZ that's a good idea, I’ve added a link to a google doc for future comments. See below for your questions; also check out this blog post for more information on the incentive mechanism in relation to market makers.

"Encourage user ownership among market makers." user ownership?

We want development of the 0x protocol to be governed by the ZRX token holders, so that users of 0x have ownership of the underlying protocol. This ZEIP specifically aims to incentivize the class of users who bring liquidity - market makers.

"Reward market makers that stake ZRX tokens." what's the relationship with MM and holding ZRX?

We want market makers to have a vested interest in the 0x protocol, by staking ZRX and participating in governance. A market maker who has staked ZRX receives a portion of the fees generated from trades on the protocol (liquidity rewards); which is proportional to their trade volume and amount of ZRX they have staked or been delegated.

"Reward Pool Buy-ins" what are reward pools?

A portion of a maker’s liquidity reward goes to their delegators, which accumulates in the delegators' reward pool.

"2.6 Epochs" what for?

A maker’s liquidity reward is a portion of all fees collected by 0x over a period of time (epoch). The reward is given at the end of each epoch to make our contracts more efficient.

"2.7.1 Registering as a Market Maker" what is the benefit

This perhaps sounds more formal than it is. A maker may stake their ZRX from one address and use any number of additional addresses to trade. By registering, a maker associates these addresses with a single identifier.

[benjiqq]

@hysz thanks, will add comments there.

"We want market makers to have a vested interest in the 0x protocol, by staking ZRX and participating in governance."

It makes sense to reward MM who are active in 0x. Parts of the incentives should go to cover development cost and making MM more open. I think MM are mostly not going to be public. So development for making MM generally more available is what I have been working on. That part ideally is exchange and chain agnostic. Integration into MM backend systems is a lot harder than just writing a client against some central server.

"A portion of a maker’s liquidity reward goes to their delegators, which accumulates in the delegators' reward pool."

Although coupling MM with 0x stake can make sense to some degree, it might add complexity and risk. MM has already a lot to deal with so maybe point 1.1.1 and 1.1.2 could be expanded upon. Many people who might want to stake MM strategies might not fully understand them.

[hysz]

@L-Kov that's a good question that sparked a good amount of internal discussion. There are certainly several edge cases, especially with respect to order matching. We just published ZEIP 42 to define the fees for the Exchange contract. These are by no means set in stone at this point and we'll be diving more into this during our dev call next week. Feel welcome to join and share your thoughts!