Concept for Stake & Make Staking Pool

Sharing this idea to encourage discussion about whether it is something worth investigating and pursuing.

Stake & Make - Provides a mechanism for ZRX stakers to earn rewards from both staking and making to amplify yield

Assumptions:

  1. Most ZRX stakers are not professional market makers.
  2. ZRX staking for non-market makers is a mostly passive endeavor.
  3. Most ZRX stakers also hold and/or trade other crypto assets.
  4. Liquidity pools such as Uniswap, Curve, and Balancer are popular automated market makers that compete with 0x for trades.

Hypothesis:

  1. There is a substantial number of ZRX stakers who would be interested in a way to more actively and predictably earn ZRX staking rewards.
  2. It is technically possible to create or connect to a Uniswap or Balancer-like liquidity pool that publishes to or transacts via 0x API/Mesh, enabling ZRX stakers to deposit crypto assets and function as market makers in aggregate.
  3. This capability would attract ZRX stakers by enabling them to earn ZRX liquidity rewards as both market makers and stakers.
  4. Pricing would be competitive enough to attract non-ZRX stakers as traders.
  5. This could potentially be connected with matcha (but doesn’t have to be).

Benefits:

  1. Benefits 0x ecosystem by increasing trading volume on 0x API/Mesh via additional liquidity source with more invested stakers.
  2. Benefits stakers by enabling them to more directly affect their own staking rewards with higher rewards for all (via protocol fee generation).

1 Like

This idea is modeled on yield farming but with the goal of compensating and rewarding ZRX stakers providing liquidity to the ecosystem vs the goal of initial/early token distribution, which is how most yield farming programs are set up and operating right now.

Great overall concept, but there are some challenges around making this efficient and practical from a market maker’s perspective. I’ve considered doing something similar to this but ended up not going through with it because of this one main limitation -> No ideal way to trustlessly integrate centralized exchanges.

One of the main benefits of using a contract here, which you highlighted, is that you can enable others to deposit crypto and share in the profits. My question for you then is, how do you practically enable centralized exchange integration into the mix?

One of the key advantages 0x market making has over AMM formula-driven liquidity pools, like Uniswap/Curve/Balancer, is the centralized exchange factor. For a market maker to function optimally, they would like the ability to move assets from the proposed contract to centralized exchanges in order to rebalance and re-stock assets once they’ve been bought out of them. The market maker would ideally also need to be in full control of the assets in order to make the most of them, which completely takes away from the decentralization aspect of the proposed contract. At that point, the contract is just accounting for a fraction of the assets in the system and a means to deposit for stakers.

Thanks for sharing your thoughts @VolleyFire! Interestingly, your comments are a good lead in to my other idea (not shared here yet) where stakers would lend their assets to a market maker for them to trade with and then get a share of the earnings (spread and liquidity rewards). I have no idea if the amount that stakers could or would contribute would be meaningful volume-wise. There are elements of this approach that are present in the Set Protocol social trading model. But that said, I do acknowlege that it introduces centralization. I guess I was thinking that market-making was becoming more automated and would function somewhat autonomously depending on how it is programmed. So basically you would be depositing your assets into a pool that would be traded by the market-maker’s programmed bot. Obviously, there would need to be some kind of upfront tests and performance verifications to ensure that there is a good probability of consistent, successful trades before stakers would feel confident enough to make a well-informed risk assessment before participating.

Do you think the concept would work better for highly correlated assets that have proven to be a good fit for AMMs, such as a stablecoin pool, where rebalancing on a CEX is less important?

That’s definitely the case, and could be a good place to start.

But if you’re going to pool stablecoins into a contract, why bother signing with 0x when you could just have the assets offered up via trading logic like Curve? If you’re going to assume 1 DAI = 1 USDC = 1 USDT, you don’t need a signed order at all.

I agree that this is a great concept, though I don’t necessarily see this as a way to benefit 0x market makers or to improve liquidity on 0x in the near term. The main immediate benefit would be to increase returns for stakers across the board, thus making ZRX staking more competitive and capital efficient.

Staking rates are currently competing with borrowing/lending protocols, AMMs, and any yield farming opportunities that involve ZRX. Many of these activities should be able to be used simultaneously with staking without incurring much extra risk.

One way of doing this would be to allow arbitrary tokens to be staked in the system, as long as they are voted in. In practice these would be different variants of ZRX such as cZRX, aZRX, or potentially LP tokens in different ZRX AMM pools. Each token would have different weightings that are used for calculating staking rewards and voting. Something like cZRX would probably have a pretty high weight (where regular ZRX is 100%), while something like an LP token in Uniswap would probably have a fairly low weight (because it represents less ZRX ownership).

This pattern could eventually be used to create arbitrarily complex incentives. For example, stakers could pool ZRX and delegate credit to market makers by using Aave. They would receive a token in return which can then be staked with its own incentives.

Another practical benefit of this is that the staking contracts could convert to/from these tokens in aggregate once per epoch, which would save a lot of gas vs individual users converting tokens themselves. Lending to Compound can easily cost $10-40 depending on gas prices, for example.

2 Likes

Interesting proposal @abandeali1
I have a couple of questions

I’m not sure I follow the as long as they are voted in requirement? You mean that the community would select these, or that the wrapped token would need to be used in a ZEIP vote :thinking:?

Interesting adding weights too, as it would help to introduce flexibility - and failsafe mechanics against potential perverse incentives introduced by new lending/pooling protocols. But I wonder what would be the strawman rationale in your mind to assign cZRX a higher weight to a LP Uniswap token.

I’m not sure I follow the as long as they are voted in requirement?

I mean that each different wrapped ZRX variant would have to be voted on in order to be supported within the staking system. Each one would have slightly different parameters.

But I wonder what would be the strawman rationale in your mind to assign cZRX a higher weight to a LP Uniswap token.

cZRX is simply less volatile than a Uniswap LP token. Ideally voting power would be completely static for each epoch, so the voting weight of a volatile LP token would have to be discounted. Otherwise we can end up in a situation where the price moves by a lot, and an LP token has higher voting power than the amount of ZRX actually included in that pool.

Got it, thanks. Would the weights need frequent updates then? Should that be made part of the finalization processm, for example fetching Compound’s interests and calculating the ZRX voting power and ZRX equivalent?

The price rate of cZRX/ZRX could be locked in during finalization for efficiency purposes. But the weight, which would be used for voting and reward calculations, would most likely not need to be updated frequently.