This is just the spec, is there implementation?
NVM, found impl on higher level of codebase
Economics question: as implemented, it seems like all the basket coins are assumed to have the same cost? (ConvertCoin2 and NormalizeCoin seem like they’re just for sigfig conversion) – doesn’t that plus the ‘highest basket fraction takes whole withdrawal’ design lead to some pretty harsh bank running incentives on underlying pegbreak? why is the highest basket fraction taking the whole withdrawal rather than a proportional split? (Or is it? My go isn’t terrific)
Another one, spectral token
Easy yes from me.
Stablecoins are a cornerstone of defi with proven demand to justify significant network-level commitment.
Additionally, I believe a ‘safety-first’ stablecoin could achieve significant adoption. For example, dYdX only settles and margins perpetual contracts in USDC on the basis that it believes it to be the safest.
Although I too generally find USDC to be safe, we recently saw that Tornado Cash sanctions were enforced by USDC but not USDT, so I think a blended stable could indeed be the end-game for defi.
My only ask would be dynamic weightings for the stablecoin pool in relation to some proxy for market demand such as capitalization.
Without some dynamic mechanism, the protocol would likely get bled dry constantly incentivizing rebalancing of the pool to a proportion that doesn’t reflect natural market demand.
As it stands, this is a “No” from me. At a minimum, I would want the following questions answered aside from the others that I see asked:
- Why does this need to be a part of the SCRT codebase? Why can’t it be a d’app the way Shade Protocol is?
- How will the underlying assets (IE the USDC, USDT, DAI, etc) be custodied? What will be the transparency around that?
- There is no mention of privacy in the litepaper other than the brief mention in the OP. What kind of privacy functions will be utilized for this? Why build on SCRT if privacy doesn’t seem to be a central tenant of the project?
The fact that it is collateralized with centralized stablecoins is a big risk, and the fact that it is not addressed up front and instead framed as a plus for security is a bit of a red flag for me. There is no way that including centralized stablecoins isn’t a risk, even if it is a necessary one. If one of those addresses is blacklisted/frozen, you immediately lose 25% of your backing at a minimum. I think there needs to be a solid plan in place in the event something like that happens. FWIW, if this was just a d’app, I’d have no issue with it as long as they weren’t asking for exorbitant funding or something. It just seems to early of an idea/not fleshed out enough to be included as a part of the code base. I’m happy to be shown otherwise though.
This proposal was one of the topics in today’s governance call, we tried to get a sense of the community’s questions and concerns with the hope you would be able to answer them here on the forums. We would also gladly welcome you next week Wednesday at 14h00 UTC to the next governance call on chat.scrt.network.
The main questions that came up are listed below (in no particular order). Comments and concerns can be found in the full notes: Gov Agenda/Notes 2022/09/07 - Google Docs
Community Questions
- Where can we view the audit report?
- Where can we view the code base? (already answered above)
- What are the team’s reasons for creating this stable coin as a module?
- How does adding this as a module affect your legal risks? Does it increase the legal risks of the chain, it’s validators, and core team?
- What happens if at some point in the future the community would like to remove this module?
- What parameters will be governed by SCRT stakers and what will be governed by Spectral holders?
- Is there a halt function for SCRT Governance?
- What are the tokenomics of Spectral?
- Will Spectral be a coin or a token?
- Are you aiming to have validators add USC as a gas option?
- How will a bank run be prevented?
- How does the withdrawal work? Will you get a single token, or a mix of tokens?
- Will there be a signal proposal on whether to add this to the upgrade or not?
Yeah, I have concerns about this at first glance. Answers to specific questions regarding risks have been handwaved, the project is collateralized with centralized stablecoins, and there are questions over the extent of the control that SCRT holders will have over the project’s governance, despite their being exposed to the risks (which, again, have been talked down/handwaved). No from me, fwiw.
The code (for v1 - this includes USC but not the governance token Spectral yet) is ready and has been audited by Halborn. No critical vuls were found.
-
Can we find out exactly what was audited… was it an original codebase that was forked and then developed further, was it a codebase created from the ground up, or is the report based on final codebase after development?
-
Is Halborns retention schedule being used so that additional developments from team USC are included in further audits?
-
As part of their service, Halborn provide both a private and a public report, do we know where the public report is?
-
What is the the audit completion date, so that we can try and locate it in the public repo ?
-
Maybe, the report does not fall under the name USC, is there another name for project USC used by Halborn?
In a nutshell, Holborn post their public reports in the following link, oddly, can’t find USC …
Thanks.
Since USC does not completely remove any of the risks inherent in any stables (for example a blacklist), then it may be helpful to require a high 200-400% collateral deposit.
Assume there are 4000 units of stablecoins backing 1000 units of USC. Even if 25% of the stablecoins gets blacklisted, the remaining 3000 units of stablecoin cover the 1000 units of USC issued to users.
Otherwise, USC effectively only guarantees you’ll get 75% of what you expect if 25% of the stables can’t be redeemed (and even less if users can exit with a chosen stable, leading last to exit with the 25% remaining blacklisted stables). If an enforced blended stablecoin exit, then it’s a race to swap out which is fairly risk neutral compared to single coin holding.
Users also should be aware that reducing single coin risk now exposes them to risks of multiple coins. So each problem of any collateral can “depeg” USC’s desired stability unless remaining collateral is sufficient. Are the plans to reward replacement collateral sufficient to bring in additional providers?
Is it good for the ecosystem to have a “single” coin that can be paired against? Sure that is useful to reduce slippage/reduce single coin risk. Is that what users want? Might need a marketing plan.
Even though we are not against USC, we are not sold on the idea that a USC-like-coin must be implemented as a module. Granted the code is already written as such, however if the risk/reward isn’t clear to the network/validators, it may be a case where permissionless deployment fits better.
In regards to the ability to upgrade contracts, adding the ability to declare and check that a contract is locked or upgradable would address that need for any relevant project more directly.
Why would anybody want to use a stablecoin where they have to provide 4x stablecoin to get 1x stablecoin that serves entirely the same function?
Assume there are 4000 units of stablecoins backing 1000 units of USC. Even if 25% of the stablecoins gets blacklisted, the remaining 3000 units of stablecoin cover the 1000 units of USC issued to users.
A reduced amount of collateral is fine as well until users are no longer comfortable with the risks.
But there has to be someone that is willing to give up their $4 to get $1 to use.
Depending on the project structure, some projects are comfortable with fractional reserves.
1:1 reserves are also okay until a stablecoin gets blacklisted, then everyone must instantly be comfortable with fractional reserves.
Some things to consider:
Do fractional reserves lead to an UST style bank run?
How much overcollateralization is required to prevent fractional reserves after collateral loses value?
How to you entice collateral to be lent to a system?
Is there value to a governance coin after a bank run has started?
How important is it to prevent the start of a bank run?
This is the best option for a native stable coin that needs to serve the Cosmos eco system
You can see the report here
Not sure about that, need to consult with Secret team.
After all, the module can’t damage the Secret network in any way, but would you put your USDC as a collateral in a system that can be paused?
What will happen to all the USC in the eco system?
Those are things to talk about, I am not the guy to take that decision as its more political than tech, we will do it the way things are done in other modules / coins I guess, not my decision.
Personally, I am against this, skeptical about any stable coin but they are always needed but in general of course but that is why general ones exist and Shade Protocol.
Also, will this not be a competitor for the $SILK stable coin on the network? I understand the collaboration process but one for now one would be enough and see how it goes first.
- This the the right choice for a coin that need to be transferred all over cosmos using ibc
- Sure, in a balanced pool
- It can be wrapped on secret to get privacy (much easier with a coin then token)
If you want it to be a stable over Cosmos than this is the best way to do it, it has no risks for the network, and 25% is better than 100%, while you can recover from it using dao funds and over collateral approach, all can be voted.
We are talking disasters here, may I remind you want happed to UST value during the collapse.
Most ppl will not hold dai, they will hold bridged usdc, usdt etc… much riskier.