Efficacious Governance and Pool Design
Imagine a simple staking pool that gives out rewards in tokens T to liquidity providers (LPs) of pair L. Its goal is to distribute T while maximizing consistent liquidity in pair L. Here is the pedestrian routine: Fork the infamous Synthetix code for staking pools, set a static reward rate (or for a more sophisticated pool, a predetermined static rate function), send T to pool contract, and watch LPs claim T proportional to their share and time in the pool. But, what if the protocol running the staking pool had governance? How would the pool design change to make governance efficacious?
Here’s an idea: Allow governance to change the reward function that determines how the rewards are emitted so that governance can replace the function in reaction to LP behaviors. Function replacement might be too complicated for most governance structures, a fact reflected in the low threshold quorum for most DeFi protocols, even ones making relatively constrained decisions; it is also poor design from the contract security perspective. Each function changed would have to be re-audited. Moreover, realistically speaking, it’s probably not necessary to have the ability to replace the rewards function completely.
An alternate idea is to set the appropriate reward function beforehand but parameterize it to allow for governance control. This would allow governance to change the parameters to nudge LP behaviors and perhaps even the price action of T. This idea begs how the function should be chosen. To have efficacious governance, the function should be chosen not only to be appropriate to the task at hand, but it should also be flexible enough, so the parameters cover a wide range of outcomes. In this elementary example, perhaps a polynomial function of the following form will do:
reward_rate = k + mt^n
with k, m, t, and n being parameters, and with t (presumably) being time staked by LP in pool. Note: This could also mean governance can pause/resume rewards by setting the reward rate to zero/non-zero. These parameters alone allow governance to mediate the pool’s behavior to a larger extent than is possible otherwise. Such a design requires no forks to go from constant reward rate to linear or non-linear reward rates.
Debt coupons and governance
Moving on from this simple example to more serious matters, imagine that a governable, infinitely composable protocol like Debaseonomics decides to compose with a ‘stabilizer-pool’ that issues coupons for debt purchases during contraction at a premium, which can then be redeemed at expansion to work in tandem with the existing Stabilizer pool 1. There is no reason to believe that the pure reflexivity of this new pool alone will provide the ultimate solution for stablecoins. Still, since the protocol is infinitely composable, it’s an interesting possibility to at least consider.
Governance notices that in algorithmic stable-coins that incorporate the debt issuance/redemption design (call it xSD protcol and the token xSD), whales can and do coordinate to push the TWAP price of these stable-coins upwards well over the target peg and then redeem the coupons accumulated during contraction.
Likewise, they can and do suppress the price, to accumulate coupons and higher premiums during periods of down-regulation as shown in the tweet above. Perhaps, this is a necessary side effect of premium curves which are designed to mitigate cycles of down-regulation by rewarding heavy debt ratios with higher premiums. This system incentives whales to control the price of xSD through many expansion and contraction cycles by taking it far away from peg in both directions, since it’s profitable to do so. Perhaps the protocol can disincentivize such behaviors in the interest of stability but also minimize the possibility of debt cycle collapse.
How can a governable system choose a debt mechanism that is flexible enough to mitigate such manipulation (if deemed necessary as the situation unfolds)? One idea is to predefine flexible functions for both coupon issuance that allows governance of the control to nudge participants in the economy to behave differently. Let’s take designing the two main functions, coupon redemption, and coupon purchases, in isolation.
Redemption of coupons
As of now, the xSD protocol allows coupons to be redeemed to xSD in a 1:1 ratio; this means, if there was governance, it could not incentivize the ideal price at which most coupons are sold. A simple idea to parameterize this ratio would be by using the log-normal function defined the over positive deviation from the upper end of stability range (For e.g., TWAP price — 1.05):
n*LogNormal(m, v)+c_min
This setup would allow governance live control of both the mode (maximum token to coupon ratio) through n and c_min and the price at which the mode occurs though mean m and variance v, by changing the log normal and scaling parameters (see Fig. 1, for an example).
The log-normal is a good choice since, it allows for a wide range of redemption behaviors (Fig. 2; it has varying rates of decay after the peak value to set how fast participants in the economy should react in redeeming the coupons) and is defined over of the appropriate price deviation (0, +inf), even if they missed out on the peak.
The lognormal distribution also has a long tail and a relatively slow rate of decay, which is perhaps more appropriate for a growing, new space like crypto where actors do not much history to bank on and are making decisions on the fly (compare this with using a normal distribution (Fig. 3) which is much more exacting of the participants with its short tails, and fast rate of decay around the mean not affording participants in the economy time to react to the peak; moreover this function’s symmetry is not necessary for this context).
Ultimately, this setup allows governance to tightly mediate at what prices people redeem their coupons without predetermining what that price will be and disincentivizing whales pumping stable-coin price to arbitrary prices (arbitrary, with respect to the stability needs of the protocol.)
Coupon purchase
Calculating coupon premiums is not symmetric with the coupon redemption as unlike in the previous situation where the maximum number of coupons to be redeemed can be known at the start of the expansion, the only real upper limit for coupon purchase is the circulating supply of the stable-coin at any given time. Here, you want to incentivize coupon purchase at prices close to peg, but you have to balance it with providing incentives in case support at the said price doesn’t hold. Once again, the log-normal is flexible enough to account for this. Here’s a formula with two modes:
n1*LogNormal(m1, s1)+n2*LogNormal(m2,s2)+c1_min
This curve means even if support at first mode breaks, there is enough of an incentive at lower prices for support to be found (Fig. 4).
This coupon issuance function is described over one single contraction; what about coupon accumulation over multiple contractions? Governance sets an additional parameter, revoke percentage (r) that revokes, r pct of outstanding coupons across contractions. This parameters allows governance an additional lever to control coupon accumulation with a high value of r heavily disincentivizing accumulation (at the risk of down-regulation to go on unabated) and a low value of r allowing for some coupon accumulation (at the risk of opening incentivizing price suppression). If there is a balance to be found between the two risks, at least governance can fine-tune this lever to help participants in the economy to find it.
Building pools that are inherently designed to be governable does not only mean parameterization (in fact, an arbitrarily high number of parameters is neither necessary nor sufficient); it also means the appropriate choice of functions that would expand the scope of the parameterization by allowing for an appropriately wide range of outcomes that fits the goal of the pool. Therefore, it might make sense to choose functions that are more general in their behaviors, to make available the maximum possible number of appropriate options post-deployment. It should also be noted that making governance more powerful does not by any means guarantee that protocol goals are met. It is important for governance to decide which aspects of protocol to control and which aspects to leave to the free market; no doubt a non-trivial task.
The functions mentioned above are only a few of the levers in the design of Stabilizer Pool 2, which is intended to be composed with Debaseonomics protocol, but it illustrates the guiding principles of building pools to be governed. A full design overview with all the functions and parameters of SP2, as well as details about how it integrates with the existing SP1, will be available in time for the SP2 governance vote.
By anon18382, with inputs from jusTaPunkk
For more info:
debaseonomics.io
