Steem Improvement Proposal: Allow STEEM donations to the DAO
Currently, donations to the DAO (aka SPS and @steem.dao) are allowed in the following forms:
- Transfers of SBD
- Beneficiaries which pay out as STEEM/SP or SBD; those which pay out in STEEM or SP are instantly converted to SBD at the current median feed price.
This proposal is to add "3. Transfers of STEEM, which are instantly converted to SBD at the current median feed price"
This was not allowed in the original design of the DAO because of concerns that sending large amounts of STEEM and allowing them to be instantly converted to SBD could destabilize the supply of SBD, resulting in SBD dropping off the peg and imposing a haircut on SBD holders.
While the above concern is theoretically valid, I now believe this restriction is overly cautious and should be removed for the following reasons.
- Any large donation to the DAO is itself a clear and immediate benefit to Steem. While there may be some downsides, the fact that someone is donating, say $100000 or $1 million or more to fund SPS proposals is itself going to be enough system-wide benefit to offset any resulting disruption. Who would not like to see large amounts of additional funds available for development, marketing, etc.? Surely Steem could use it.
- The DAO has shown itself capable of self-repair when it comes to SBD oversupply. The @sbdpotato proposal is currently in the process of ramping up to convert much of the excess SBD in circulation into STEEM, reducing the oversupply and haircut, and restoring the value of SBD to $1. In the case where a very, very large donation were made which created a large amount of SBD, a proposal could be created and funded which: a) converts this SBD into STEEM, b) uses that STEEM to buy SBD, c) converts that SBD back into STEEM, and finally d) donates that STEEM back to the DAO (which converts it back to SBD). The net effect of this process is to remove the excess supply of SBD from circulation while returning approximately the entire value of the large donation to the DAO (small losses, or gains, might occur due to slippage or conversion price changes)
Key benefit: a vastly improved SBD peg
The biggest deficiency of the SBD peg, going all the way back to the original white paper, is its inability to deal with any sort of overvaluation or "pump". The white paper essentially throws up its hands and declares that nothing can be done, asserting that allowing converting STEEM into SBD would be too open to "market manipulation" (an assertion which has been heavily debated, but with this new approach, we can set that debate aside and leverage the DAO as a safer approach with fewer untested assumptions).
With the ability to donate STEEM to the DAO, we gain a safe way to convert STEEM into SBD as follows:
- Fund a proposal which pays out SBD (similar to the current @sbdpotato).
- The recipient of the proposal payout is charged with selling that SBD for STEEM.
- The recipient of the proposal payout is charged with immediately sending ("donating") that STEEM back to the DAO.
- The donation would then be converted by the blockchain code into SBD at the current feed price (essentially, 1 SBD for every $1 worth of STEEM).
In the case where SBD is overvalued (meaning the market is demanding a higher supply of SBD in order to maintain the peg), the result of this process is:
- More SBD has been provided to the market (step 2 above), helping to reduce the market price and satisfy demand
- The DAO treasury receives back more SBD than it started with (steps 3 and 4 above).
To see how this works, consider the example of SBD trading at $2 and the proposal being funded for 1 SBD. In this case, step 2 above would sell the 1 SBD for $2 worth of STEEM, the $2 worth of STEEM would be sent back to the DAO, and then the $2 worth of STEEM would be converted into 2 SBD added to the DAO treasury.
Why is this important
Many of us believe that a stable value asset is an extremely valuable service to provide, which not only allows Steem community members to save money with some degree of protection from highly-volatile crypto markets, but also allows businesses and services to be built which rely on having a degree of stability. The SPS itself was built around SBD as a result of various real world experiences with other cryptocurrency-based funding systems which suffered greatly from native token volatility. In fact, much of the broader cryptocurrency ecosystem has shifted toward greater support of pegged and stabilized asset such as USDT and DAI.
Second, previous SBD pegging issues have caused a lot of problems for Steem. In addition to reputational damage ("Even their dollar isn't worth a dollar; what a failed project"), the pumps encouraged hoarding and led to a build up of supply which in turn flooded the market later. Overall we would be far better served with an SBD that is actually more stable, in my view.
Finally, we have never seen how well SBD could perform with an upper peg. It is possible to could turn out to be very stable and effective, ultimately gaining the trust of the market and even becoming positive black swan for Steem. The potential market for a successful and trustworthy stable cryptocoin that is fully-decentralized is enormous, already in the billions and perhaps someday into the trillions.
Of course, not everyone even agrees that SBD is valuable to Steem at all. In fact, some have argued for its removal altogether. I do not believe there is consensus for its removal, but the purpose of this proposal isn't to debate that issue. As long as SBD exists on Steem, we ought to at least make it work as well as we possibly can, to at least avoid or minimize its dysfunction hurting Steem. This proposal offers a sensible path forward to an upper peg which would protect SBD from pumps and also transmit the benefits of increasing SBD demand to the broader Steem community (via increased DAO funding).
Resistant to Abuse
This method of improving the DAO and SBD peg is highly resistant to abuse. Let's consider some possible "attacks"
Attack 1: Attacker donates hundreds of thousands or millions of dollars worth of STEEM to the DAO in order to destabilize SBD. Mitigations: As noted above, Steem gains large amounts of valuable funding to be used to improve the platform, excellent compensation for any potential disruption, and the disruption can be still be quickly self-cured through the DAO using an @sbdpotato -like proposal. Not a serious problem
Attack 2: Attacker pumps the price of SBD and/or STEEM and "somehow" attempts to leverage the ability to convert STEEM to SBD via DAO donations as well as a some sort of self-paying proposal to recover the resulting SBD in a manner similar to the "market manipulation" scenario in the white paper. Mitigations: a) the DAO has shown excellent resistance to frivolous proposals since many stakeholders support the "return" proposal as a defense; such an attacker would have a hard time getting their donation back via any sort of payout. b) Payouts from the DAO are limited to 1% of the treasury per day, which means in the case of a very large donation, even if somehow the attacker could manage to get their proposal approved, they would be limited in the rate they could possibly recover their donation, greatly limiting the effect of any market manipulation (the market would need to be manipulated for weeks or months for this to really work). Not a serious problem
Attack 3: DAO proposals which serve to help maintain the peg (by either increasing or decreasing the supply of SBD, as discussed above) involve large amounts of DAO-owned treasury funds being sent to a contractor on the expectation that they will be returned (in one form or another). A dishonest or incompetent contractor could steal or lose the funds. Mitigation: DAO proposals pay out gradually over a period of time. The rate of payout can be set so as to maintain the risk of loss at an acceptable level far below the total amount of funds. The processes as described require the contractor to return the funds promptly, and funding can be stopped at any time if the contractor is not returning earlier payouts. If market conditions are such that a high rate of disbursement is required, multiple contractors can be used, or alternately a multisig account can be set up to serve as the contractor. Not a serious problem
While this probably does not enumerate every conceivable method of attack, overall it should be clear that the existing limits inherent in the DAO (the 1% daily aggregate payout as well as the willingness of many stakeholders to vote for "return" and stop abusive proposals from getting funded) make any sort of exploitation very, very difficult and unlikely.
When can we get this done?
Whether this could be included in the next upcoming hard fork is debatable. From a code perspective, it is probably not very complicated; the code to convert STEEM to SBD already exists for beneficiaries and would need to be repurposed for donations, as well as removing the existing code which explicitly blocks those donations. That's not a huge change, but also not completely trivial
If it were up to me, I would push to include it because: a) the coding changes while not trivial, are still relatively simple; and b) the existing design of SBD is pretty much a ticking time bomb when it comes to more SBD pumps, which could once again cause a lot of disruption to the community and platform, as well as reducing the credibility and market opportunity for SBD going forward. Gaining the ability to stop these pumps and instead use SBD demand to boost funding for the DAO sooner rather than later is a big advantage.
However, I wish to make clear that the purpose of this proposal is not to advocate for including this change in the next hard fork, but to encourage discussion of including it in any future hard fork.
In my view, the balance of risks strongly favors allowing STEEM donations to the DAO, which in turn allows us to greatly improve the SBD peg in a manner that was not possible prior to the introduction of the DAO.
100% of author rewards from this post will be donated to @steem.dao (I forgot to set the beneficiary so I will do the conversion and transfer manually after payout)