[PROPOSAL]: Integrating project USC/Spectral into Secret

why is a module the right choice rather than a snip20 + IBC?

Very good questions, I will try to do my best, some of them I asked and waiting for answers

  • Where can we view the audit report?
    USC_Audit_Report.pdf - Google Drive

  • Where can we view the code base? (already answered above)
    USC-Developers · GitHub

  • What are the team’s reasons for creating this stable coin as a module?
    Better for stable coin that will serve all cosmos zone, easier to add privacy in secret network, please read Guy proposal that explains this

  • 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?
    Good one, I don’t think more than any other coin and you are dealing with known stable coins as collateral

  • What happens if at some point in the future the community would like to remove this module?
    Not sure, what is happening with any other module? same

  • What parameters will be governed by SCRT stakers and what will be governed by Spectral holders?
    I don’t know, I will ask, spectral will be govern all decisions about USC

  • Is there a halt function for SCRT Governance?
    Not sure - need to check that

  • What are the tokenomics of Spectral?
    Not publish yet

  • Will Spectral be a coin or a token?
    Token

  • Are you aiming to have validators add USC as a gas option?
    No

  • How will a bank run be prevented?
    Vesting period, over collateral

  • How does the withdrawal work? Will you get a single token, or a mix of tokens?
    Single, but anything is possible

  • Will there be a signal proposal on whether to add this to the upgrade or not?
    Next week there is going to be a vote

Easier to wrap and use in Secret Dapps/add privacy
Better for transfer between zones

This is a better approach for a Cosmos wide coin

How does this prevent extraction where if one part of the basket depegs, the fastest 75% of people get all their collateral out in non-depegged assets (via some pretty simple attacks given the ‘highest collateral payout first’ model) and the last 25% are left with 0?

why though? what is actually easier about a module over a dapp/contract for this?

Also, as far as I can tell, per the codebase, while there is time-locked redemption per gaia/grpc_msg.go at a6128855271cd0e7eb1a8480a4fa26a3a2cc7813 · USC-Developers/gaia · GitHub,

the module as written isn’t overcollateralized per gaia/grpc_msg.go at a6128855271cd0e7eb1a8480a4fa26a3a2cc7813 · USC-Developers/gaia · GitHub and
// ConvertCollateralsToUSC converts collateral coins to USC coin in 1:1 relation.

1 Like

This is inherently wrong.

A snip-20 ref imp. contract token is wrapped by default. So user can skip the step of wrapping entirely if it was a token issued by a contract.

The reason we ask is because Guy’s opening post does not explain it. Guy’s opening post mostly describes why it would be good to have a stable coin on Secret Network. Even though he writes these reasons under his ‘header’ why module. A stable coin can be done with both a contract and a module. So please explain why you choose to go with a module over a contract.

2 Likes

Not sure about the low level details, that’s what the secret team advice was, read the proposal guy mention that

I wrote few times:

*Better for transfers over zones
*Easier to warp
*Secret team advised that

1 Like

I’m in support of the module.

I am partially convinced by the argument that secret stakers would ultimately gatekeep in regards to upgrades and removal. I think I’d be more convinced if what Ian said about being able to turn it off without halting a chain were a possibility too. I still have concerns on what this means for other projects and the implications of such a decision.

As for the merit of the project itself, I think there is a clear demand for usd stablecoins today. I’ll take this on Secret over a competitor. I don’t share the view that just because it’s not private by default that it’s not worth it. For starters, I really don’t see a fully private centralized stablecoin surviving in the long run. And if I happen to be wrong on this, a native public stablecoin that you can potentially wrap for privacy is a good intermediate step anyway.

I also don’t agree with the criticism that centralised stablecoins are inherently bad. People have different risk profiles, and offering the possibility is a plus for us. Don’t like it? don’t use it.

Assuming this proposal passed successfully, I find it imperative that the risks are disclosed clearly. From what was discussed, it looks like in its current format the design is subject to a bank run if any of the 4 stablecoins are censored (because the largest asset is the one always withdrawn for 100% of the funds, then 25% of users will withdraw the censored stablecoin if this were to happen). I understand that a phase 2 would deal with this, but people need to be clear of the risk until that is implemented.

I don’t think there’s a way where we will be left off in a worse place than we are today if this happened to fail in some way.

1 Like

I just want to point out that this is not a useful argument in this case. The issues with USC aren’t some moral or ideological dilemma, but questions around its core technical details. If we’re going to accept software as a cosmos module on the network, we need to be absolutely sure that it’s stable enough so it doesn’t crash the network, and that it’s sustainable enough to not be “dead weight” on the codebase in a year or five from now.

6 Likes

I disagree. Your point that we need to be sure that it’s stable enough it doesn’t crash the network is the absolute bare minimum. That is basically the same standard that is applied to any upgrade. To say that USC is the same as cosmwasm 1.0 however, or any other kind of upgrade, is to ignore the nuances in the implications of such decision IMO. In fact, if they were perceived as generally the same kind of upgrade, we wouldn’t be having this discussion in the first place. I think similar logic applies to the perception of sustainability.

The technical dilemma is very easy to answer, the product either sucks or doesn’t.

Some of the moral dilemmas in what it means to adopt software as a module, for example, are:

  • What it means for the value proposition of SCRT, where governance is one of its value proposals, and now we are introducing a core module that wouldn’t be governed by SCRT.

  • What it means for other people building a stablecoin, now or in the future, since software as a module implies it being perceived as an ‘official’/core solution/product. Is ‘picking winners’ good for growth?

Even a technical question might have a moral foil:

  • What is the implication of implementing a product in an MVP stage (technical, → possibility of bank-run until phase 2 is implemented)? What will be the impact on the reputation of the network if this happens considering the perception in the previous question (moral)?

tl;dr I still support, but to say the only concerns are technical is way simplistic IMO. The very own nature of the discussion in all channels shows the concerns aren’t just technical.

@adys

Could you expand on the degree of testing you’ve done with this?