Variable jToken Incentivization by MultiSig

It is already currently planned to provide some amount of BOND token reward to incentivize jToken acquisition and holding. This proposal suggests that we should implement a variable incentive (e.g. total BOND reward per week can vary between x and y), rather than a flat incentive (e.g. total BOND reward per week is x every week).

A MultiSig team (suggestion 3 of 5), will be empowered to adjust the jToken incentive. They can adjust it up or down depending on market demand. The DAO will elect this team, as well as the maximum amount of BOND reward that can be distributed to jToken stakers. The MultiSig team will only be able to affect the rate of BOND token reward distribution (e.g. the amount of BOND distributed on a weekly basis).

jToken incentive must be sufficient to ensure liquidity for sBOND creation. Depending on sBOND demand, it may be necessary to drive further jToken liquidity at short notice. An increase of jToken BOND reward via the DAO will be a longer process than what can be accomplished by a MultiSig team. Additionally, we do not want jToken incentivization to “steal” too much liquidity from Pool 2, which provides Uniswap BOND token liquidity.

Technical details
The MultiSig team would form a SquadDAO and conduct private and public meetings as necessary to determine when an increase or decrease to the weekly jToken incentive is necessary. The initial jToken BOND incentive would be established by the DAO.

Useful Links

Quickly adjust jToken incentive
Ensure balance of jToken reward with other market factors

MultiSig team could go rogue and mismanage funds
Variable incentive is unnecessary complexity
Confusion or frustration from jToken stakers due to fluctuating BOND reward

DAO Vote


I like this idea in theory but couldn’t we use something like Balancer that does this algorithmically without needing to take on additional risk of the multi-sig rugging? If we elect them I think it reduces that but we could actually have variable function like this without needing to use the multi-sig approach.


I suppose I’m not familiar enough with how Balancer could manage this for us. If there’s an easy way to control this algorithmically then I definitely support that.

1 Like

I like the idea of fluctuation, but would prefer to see this as a vote by all like 1INCH does it, as opposed to giving it to few.

This is interesting. I couldn’t find where 1inch explains how the voting works, but it looks like stakers can vote for the reward percentage (I assume with the ability to vote again at intervals). Main problem I see with this is that on chain voting could be cost prohibitive for many stakers. My primary focus is ensuring rapid adjustment of jToken liquidity incentive as necessary and I’m not convinced overall DAO voting is fast enough.

I think the incentivization of jTokens will be an important tool in getting quick traction / keeping momentum going so I appreciate you getting a head start on thinking through this @Seseo17. Personally, I really like the algorithmic solution to this. That said and I’m not sufficiently technical to know how quickly that could be built out, but I suspect we would want it sooner rather than later. Until something like that could be put into place, I think a multi-sig team of 5 (quorum of 3 required) could manage this without adding too much risk.

Another important piece of this that we need to think through would be the metrics we would require the algorithm or multi-sig team to evaluate when managing the incentive rewards flow. Obviously liquidity as it relates to sBOND will be important, but overall BOND liqudity in P2 will be something we need metrics around to provide balance.

This would require smart contract work just so everyone is clear. The rewards are just pools and we would need to rewrite the contracts for this. These are not variables.

It’s interesting but more complicated that it sounds. Just off the top of my head and I can think of a couple edge cases that would be hard to mitigate.

I think it’s important to remember WHY we have rewards. The rewards were a way to reward early users of the protocol so they could control it, it wasn’t to pay people. This is simply a decentralizing mechanism.

Hmm, that’s unfortunate. I was under the impression that any value/contract could be modified by the DAO. For example, it was my understanding that the DAO could adjust the DAO staking reward rate with from 12,200 per week to 10,000 or 15,000 with a successful BBIP. Once these contracts are created, they cannot be changed, not even by the DAO? Or are you saying that the DAO cannot delegate this authority for a specific contract? (or perhaps a smart contract can only be replaced, not updated?) If smart contract work is required, it may be worthwhile to consider taking the effort to do it, but implementing an algorithmic control like @lordtylerward suggested.

I have to partially disagree with your second point regarding the purpose of rewards. I certainly agree that they aren’t to simply pay people, but rewards absolutely serve to incentivize use of the protocol. Insufficient jToken users could grind the whole protocol to a halt (not enough liquidity for sBOND minting). To me, it is imperative that we ensure adequate jToken interest/investment.

DAO staking reward contract is different from the pool reward contracts. The pool reward contracts are really simple and very set it and forget it. Once you load them up that’s it. You can add to them but you can’t launch a new contract and remove what is in that pool. The current contracts can’t do what you are talking about on the level of customization you guys want. You can upgrade the system though but that’s what I meant is there is smart contract work and edge cases.

I’m not saying don’t do it, but it’s complicated.

So what happens when we run out of BOND? The minting function was turned off so we can’t inflate it. We could take fees and buy more on the open market but PERSONALLY I like the to set it and forget and if people aren’t gonna use the products without outside incentives then I think it’s kind of a dumb product. People are incentivized to use the junior tranches because you are getting more. With that said, I’m not in control so I can’t stop you but that’s just what I think. Also, having conversations with people there is definitely interest on both sides so I think it’s not gonna be a problem.

1 Like

Thanks for the detailed response. It’s unfortunately that a variable reward is complicated to implement. I don’t want to divert resources from launching the products.

A new product needs a reason to be used. With so much Alpha available right now, I think it’s quite advisable to further incentivize jTokens with sufficient extra yield from BOND rewards to get people using the protocol. It’s basically a marketing strategy. We shouldn’t need to offer these rewards forever, but offering them early drives early adoption and understanding of the benefits of using jTokens. Fortunately, doing so also doubles as a decentralization method. And I do think it makes sense as a long term strategy to have a buy-back or similar program so the treasury always has BOND available for new initiatives.

EDIT: I want to be clear that I appreciate your perspective. I can certainly be wrong and do not speak for the whole community. It’s quite possible your perspective is more generally accepted than mine.

1 Like

No worries…I could be wrong on some of that. This is me spit balling with you and I try and look for edge cases cause it’s really easy to get lost in the weeds. I would like to double check some of that with a dev, cause maybe we can do it easier than that. Like if you can remove the rewards that are in the pool it makes it a lot easier, but having a variable rate that can be modified by a set group is kind of risky too.

I see where you are going with it.

I don’t want you to think my perspective is higher than anyone else’s we are all in this together and I appreciate everyone’s opinion on these things.


I think this is spot on as I see bootstrapping products as one of the primary uses of treasury assets. Assuming the project has already been sufficiently decentralized, building out products and incentivizing governance are the other primary treasury uses in my mind (there are others, but those are big ones to me).

That said, I agree that we need to prioritize building and releasing products over building a complicated feature that subsidizes a product’s use case. Taking a step back, it’s funny we are having this conversation because I think we all fully expect Smart Yield to be a massive success and stand on it’s own without additional incentives.

I do think it is prudent to have a contingency plan in place in the event we need more traction early on. In that instance it would be important to have variable rewards as we don’t want users to get addicted to overly inflated rewards and miss out on the true value of the product. I agree that looking into the complexity of variable rate incentives is valuable because we could potentially benefit from that approach in the future with other products even if it doesn’t make sense for Smart Yield.

Maybe it’s just me, but I love seeing the governance mature because I think that is going to be what differentiates the best projects in the future.