pUSD

[xlc]

Polkadot native stablecoin on Asset Hub

rendered

[ggwpez]

Pollar :D? Or too similar to Hollar maybe.

[PolkadotDom]

@xlc Thank you for getting this discussion going. In general it feels a bit difficult to wrangle and perhaps would benefit from a few sub issues in the repo (protocol design, financial governance, etc). Perhaps some links as well-- to the honzon protocol documentation and such.

I was hoping you could speak to the trade offs between the honzon and hollar protocols / any other prominent designs in the ecosystem and why you eventually decided on honzon.

I'd also be curious to get your thoughts on some form of nationalization of a previous protocol as opposed to starting fresh on AssetHub.

[xlc]

I didn't link to existing honzon docs because while a good chunk of the code will be reused, they will be adapted specifically for this. e.g. no more multi collateral. So a lot of information will be incorrect and I fear it only introduce more confusion.

Also it wasn't me decided on honzon, it was Gav's idea. He might be able to share more insights.

From a cost perspective, develop a new protocol based on existing open source code is very low cost. No need to R&D, PoC, write all the code etc. How much do you want to pay to acquire an existing protocol? I bet that will be significantly more expensive compare to develop a new one and bootstrap it.

[PolkadotDom]

From a cost perspective, develop a new protocol based on existing open source code is very low cost. No need to R&D, PoC, write all the code etc. How much do you want to pay to acquire an existing protocol? I bet that will be significantly more expensive compare to develop a new one and bootstrap it.

In general I agree with your sentiment, but I'll Steelman a bit. It may be that there's a much lower threshold than 100% federal control that will satisfy our authority requirements. For instance, perhaps we only need to purchase 20% of the target's governance tokens before we feel we have sufficient federal control over the protocol's future direction. It may also be that a protocol is willing to give a significant portion of this free of charge, as it signals an ossified position in the ecosystem at large.

[xlc]

Yeah it is possible someone could negotiate a good deal. We can discuss it when that happens.

[jak-pan]

I am sorry but this seems super rushed without considering other options and consulting biggest DeFi protocol in the ecosystem.

We would like to propose competing RFC that would cost close to nothing and could be used from... this Monday.

We are launching Hollar next week, which is based on AAVE GHO (Battle tested) with stability mechanism and more security baked in. Having all of the necessary scaffolding around it already built, (Oracles, money market, liquidation engine, security measures) it's audited and tested. It already has liquidity and it is being used by polkadot treasury cross chain without any problems. We could easily bake in features that are required by polkadot asset hub.

[gavofyork]

The code which this stable utilizes is mature and the point of having this RFC process is to avoid "rushed" decisions. That said, I am of the well-considered opinion that Polkadot needs a fully-collateralised decentralised stablecoin, that it needs it ASAP and that it is of strategic importance.

This is a proposal for a DOT native stable, which resides on Hub and for which issuing liquidity would not result in HDX holders getting a windfall. Hollar, at least, does not fulfil the last point.

I appreciate that you (and perhaps some others) would desire your own products to have a monopoly within this ecosystem, but I'm afraid I, at least, consider that unacceptable for a strategic service of the Polkadot network.

I have no problem with utilizing Hollar in due course but absolutely would not bet a central pillar of what I consider Polkadot's future on a third-party team. Given that Hollar isn't even launched yet I don't think that any kind of buyout/merger would be in Polkadot's overall interest.

[jak-pan]

Having spoken with @gavofyork at length on this matter, we will not be proposing an alternative for pUSD - we will continue our focus on collaboration and driving liquidity into the Polkadot ecosystem.

[PolkadotDom]

we will not be proposing an alternative for pUSD

@jak-pan I'd be curious to get your reasoning here. Are the HSM & other requisite infrastructure not suitable for AH?

[jak-pan]

we will not be proposing an alternative for pUSD

@jak-pan I'd be curious to get your reasoning here. Are the HSM & other requisite infrastructure not suitable for AH?

Some of the hard requirements were to have this on the Hub governed by Polkadot governance, with launch date before there will be contracts on the Hub. As such, it's not possible to deploy even modified Hollar version until then. HSM requires oracles, stablepool implementation and of course liquidity which is also non-present on the Hub.

This simpler mechanism is more suitable for fast launch of DOT-collaterized stablecoin as envisioned.

[sourabhniyogi]

Mmm, 9/11. I seriously doubt there can be a repeat of whatever happened to aUSD in pUSD, but:
(1) people never really got a great post-mortem on aUSD, and without it will be super suspicious of pUSD. I think its useful to exorcise the ghost of aUSD so pUSD can quickly get as much community love as Hydration enjoys right now. This might even require framing =)
(2) This is a serious political issue. I think DOT tokenholders should weigh on this, so I posted OpenGov #1761 with this RFC verbatim with the title "Should Polkadot Hub have NATIVE pUSD based on the Honzon Protocol?" People should know at least the basics of Honzon vs Aave vs whatever else might be reasonable?
(3) Let us accept the past, learn from it and make it better!

[bkchr]

I think its useful to exorcise the ghost of aUSD so pUSD can quickly get as much community love as Hydration enjoys right now. This might even require propaganda =): "Who controls the past controls the future. Who controls the present controls the past." means ... if you erase or alter what people know about what has already happened, you can steer what they expect and accept in the future.

Maybe you can keep these kind of comments away from here. We are not here to "change the past" or try to erase the minds of people. Accept the past, learn from it and make it better.

[JayChrawnna]

Excuse this non-tech interruption but might we call it something that sounds better than pUSD?

Maybe something that sounds STRONG & stable like USDOT?

[sourabhniyogi]

Maybe you can keep these kind of comments away from here. We are not here to "change the past" or try to erase the minds of people. Accept the past, learn from it and make it better.

I changed it for you -- I think people would trust and learn the most from your post-mortem. In the Fellowship we trust.

[olanod]

After this launches on Polkadot I can already see people asking, should Kusama have its own KSM backed stablecoin a la Polkadot? I'd say no, Kusama can specialize in a lot of things but DeFi protocols in need of deep liquidity aren't likely to take off in the time being, however KSM holders that more often that not are also DOT holders with similarly aligned interests deserve a similar instrument that allows them to bet on their token.
So I would like to ask for this RFC to consider KSM as collateral besides DOT, collateralization can be different and even adjust automatically based on some DOT/KSM index.

[sourabhniyogi]

The code which this stable utilizes is mature and the point of having this RFC process is to avoid "rushed" decisions.

We're at the halfway mark in OpenGov 1761. Oddly, not many people have commented here but commented there.

Concretely, I believe addressing these questions from Polkadot Poland DAO would be useful to socialize this better:

• What specific changes have been made to the protocol to prevent similar misconfigurations or incidents?
• Who will operate it, how will collateral be secured, and what measures will address DOT's price volatility?
• Additionally, why the haste in implementation when alternatives like Aave v3 took about a year to launch safely?

Also from more than a few others:

• Can you change the pUSD name to USDOT?

I believe these to be fair, representative and rational.

Abstractly, I have constitutional questions of how checks-and-balances works between OpenGov voters vs Fellowship decisioning:

1. Does a NAY from OpenGov WFC signal to the fellowship that this RFC should not be considered? Or does it cancel consideration of this RFC altogether?
2. If an upgrade to Asset Hub to include a Honzon pallet goes through "Whitelisted caller" track despite a solid NAY, what does it imply about OpenGov voters vs Fellowship decisioning?

Could one of you address these questions?

[xlc]

We already made a number of changes to limit the blast radius of misconfigurations. This PR limits max % a config change can be made. AcalaNetwork/Acala#2345. e.g. if the minimal collateral ratio is %150 with max change of 20%, a governance proposal reduces the minimal collateral ratio to %100 will not be able to execute.
But obviously if the governance insistent to propose a some unsafe parameter (e.g. minimal collateral ratio of %100), it can be done with multiple proposals and there is nothing the protocol can prevent. So we need the governance to guard the protocol by validating and evaluating any proposals. In the end, it is up to the governance to own the protocol, no the guy make proposals. People can always submit a bad runtime upgrade proposal, there is nothing the protocol can prevent that from happening.

The RFC already propose to create a Financial Fellowship and it will be the main entity to operate the protocol. It is up to the government to decide the seeding members. IMO it should have economists from W3F and some high rank fellowship members. We could also have members from other parachains such as Hydration to ensure the protocol alignments if that's approved by the governance.

We want to get this out ASAP but obviously that actually means we want to get a fully audited version out ASAP. Fellowship isn't going to approve a runtime upgrade to Polkadot (and its system parachain) containing unsafe code under all circumstances. If we can't get it ready by some deadline, well, it won't be out by then. If anyone can provide solid justification of why the protocol still have high risk and should not be released, please make an issue and we will address it. This is just the usual process.

pUSD is still a placeholder name and I don't want to keep changing it. In the end, the name is the last thing we need to decide. The runtime code will simply refer it as "stables" and the frontend/docs can simply search & replace once a name is decided. We can for example have few concurrent WFC proposal to formally let governance pick the final name.

For last two questions, it is more about if there are conflicts between the fellowship and general governance, which I don't know the answer. Maybe other higher rank members can chip in.

[sourabhniyogi]

We already made a number of changes to limit the blast radius of misconfigurations. This PR limits max % a config change can be made. AcalaNetwork/Acala#2345. e.g. if the minimal collateral ratio is %150 with max change of 20%, a governance proposal reduces the minimal collateral ratio to %100 will not be able to execute. But obviously if the governance insistent to propose a some unsafe parameter (e.g. minimal collateral ratio of %100), it can be done with multiple proposals and there is nothing the protocol can prevent. So we need the governance to guard the protocol by validating and evaluating any proposals. In the end, it is up to the governance to own the protocol, no the guy make proposals. People can always submit a bad runtime upgrade proposal, there is nothing the protocol can prevent that from happening.

Can we get a post-mortem like this from you and someone else and how these changes were made in the acala honzon code which Substrate devs can dive into?

If there is a Asset Hub stablecoins pallet version that has even newer changes, given the "ASAP" nature, having a totally code complete pallet that is ready to go onto on Westend / Paseo => Kusama Hub as kUSD would make this super concrete. What is the aggressive vs conservative timeline for this exactly?

The RFC already propose to create a Financial Fellowship and it will be the main entity to operate the protocol. It is up to the government to decide the seeding members. IMO it should have economists from W3F and some high rank fellowship members. We could also have members from other parachains such as Hydration to ensure the protocol alignments if that's approved by the governance.

While I would think the same people who built the honzon pallet can competently manage the stables pallet and deployment rather than, say, economists, it seems many OpenGov voters [not me] would rather have a totally new slate of Substrate developers (meaning not from Acala) have total control over the stables pallet code. For better or worse, its about "clean room" optics, not engineering. Can you envision a way to do this?

It appears the underlying assumption is the way to deliver the honzon protocol onto Asset Hub is a stables pallet derived from the Acala honzon pallet -- is this correct? But surely there is another way forward that uses the revive pallet instead which is already on Westend / Kusama Asset Hub, so that the honzon implementation code on Acala is used by one or more teams to deploy with revive-compatible contracts. Yes, more smart contract engineering, but no protocol engineering and no pallet deployment months. If something is missing, like "how does OpenGov control this revive-deployed contract", then there is a useful key product feature to deliver. What are the features that necessitate a honzon pallet rather than honzon contracts?

If there is no actual reason to have a honzon pallet, then you could have "clean room" by not-from-Acala implementation of this. Is that possible?
Given how Polkadot Hub is primed to have revive pallet this year, this would seem to a way to address voter concerns, eliminate the pallet deployment months, and have a maybe faster "clean room" execution faster?

We want to get this out ASAP but obviously that actually means we want to get a fully audited version out ASAP. Fellowship isn't going to approve a runtime upgrade to Polkadot (and its system parachain) containing unsafe code under all circumstances. If we can't get it ready by some deadline, well, it won't be out by then. If anyone can provide solid justification of why the protocol still have high risk and should not be released, please make an issue and we will address it. This is just the usual process.

pUSD is still a placeholder name and I don't want to keep changing it. In the end, the name is the last thing we need to decide. The runtime code will simply refer it as "stables" and the frontend/docs can simply search & replace once a name is decided. We can for example have few concurrent WFC proposal to formally let governance pick the final name.

Ok, its worth doing that name polling.

For last two questions, it is more about if there are conflicts between the fellowship and general governance, which I don't know the answer. Maybe other higher rank members can chip in.

[xlc]

Keep in mind that the status of current code does not matter at all. There are many fundamental changes (e.g. single collateral instead of multi collateral) so only little code is actually shared. ALL the code needs to be reviewed & audited as fresh code anyway. The only thing that is preserved is the high level design of the code, which is based on MakerDAO, that is battle tested.

All the code are managed by the Core Fellowship. All the code must be reviewed by 2+ reviewers. For the code in polkadot-sdk, reviewers must be from Parity. For the code in the runtime repo, reviewers needs to be rank 3 or above. Again, the standard practice applies. The process is designed to ensure the code are high quality and safe. If the process failed to do that or people do not trust the process, well, please make a new RFC to improve that.

revive is not an option (some reason stated by @jak-pan above). It is technically infeasible to code a lot of low level logic with revivie. e.g. cross chain oracle, staking integration etc. We will have to code a log of precompiles and have good chunk of Rust and glue code (I will say > 70%).

[sourabhniyogi]

OpenGov weighed in on Ref 1761 with a NAY.

Everyone here can read the comments for themselves. What does this mean to the Fellowship?

The WFC process was envisioned as a way for OpenGov voters to signal that the Fellowship should make some key change (e.g. fix 2.1B total supply), for which the Fellowship would be expected to implement if the result was an AYE. Though its technically non-binding, the expectations are that only security concerns should halt the implementation.

Here, the WFC process is a signal from OpenGov voters to signal the Fellowship to not make some key change (ie use the Honzon protocol for pUSD). Though its technically non-binding, here the voters are concerned about security as well.

If the signal is ignored, it implies something about the veracity of statements of the form:

That is not for { ... } to decide, it is ultimately up to the OpenGov voter.

This is a test of OpenGov vs Fellowship decisioning processes.