[Proposal: 26] Emergency registering StellaSwap’s stDOT Controller as derivative account for index 5 (Seeking for whitelisted fast track)

This proposal is to seek whitelist fast track for registering Stellaswap’s stDOT controller ( 0x002D34d6a1b4A8E665fEc43Fd5D923F4d7Cd254f ) on xcmTransactor pallet for index 5.

*We are seeking assistance from the technical committee to whitelist the pre-image so that the whitelist track can be used to accelerate this proposal.

The rationale to apply for technical committee whitelist is to allow StellaSwap to launch a liquid staking derivative for DOT (native to Moonbeam) to align with the much anticipated major event for DOT on October 24 will see ~100M DOT being unlocked from parachain crowd loans. With a nominal value of ~$365M, this represents a huge chunk of DOT that could bring in capital inflows towards Moonbeam.

Parachain DOT Return Date
Moonbeam 35,759,931 October 24, 2023
Acala 32,515,980 October 24, 2023
Parallel Finance 10,751,519 October 24, 2023
Astar 10,333,552 October 24, 2023
Clover Finance 9,752,487 October 24, 2023
Total 99,113,469

As the largest DEX on Polkadot with the highest trading volume, we have created a strong brand across the ecosystem and we’re confident of capturing a share of the soon-to-be-unlocked DOT. Capturing 10% of DOT unlocks will bring in approximately $36M to the Moonbeam ecosystem, which would almost double Moonbeam’s TVL.

The stDOT codebase is a fork of open source code from the Mixbytes team for sunsetted stDOT.

Technicalities

To stake DOT on Polkadot Relay Chain the xcDOT on Moonbeam needs to be sent over to a SS58 address on Relay Chain. To avoid any centralization risk or hacks we want to utilize the Multilocation derivative account functionality to allow us to derive and control relay chain addresses from our controller smart contract.

You may read more about it here: XCM: Remote account converter by mustermeiszer · Pull Request #6662 · paritytech/polkadot · GitHub

The derivation will be based off of Moonbeam’s sovereign account on Relay Chain ( 5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN )

The accounts sequence will look like:

//5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN//5//1
//5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN//5//2
//5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN//5//.
//5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN//5//.
//5Ec4AhPVjsshXjh8ynp6MwaJTJBnen3pkHiiyDhHfie5VWkN//5//n

The registration of derivative indexes is a sudo function and requires governance thus we’re asking for whitelist approach to meet the unlock date of Oct 24, 2023.

Extrinsic Link:

https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmoonbeam.api.onfinality.io%2Fpublic-ws#/extrinsics/decode/0x6b00002d34d6a1b4a8e665fec43fd5d923f4d7cd254f0500

Function:

xcmTransactor.register()

who: 0x002D34d6a1b4A8E665fEc43Fd5D923F4d7Cd254f

Id: 5

Preimage Hash:

0x4b00cc07e2bcd32ee578cd0d6177dce04d20ddb2091ba708f4e963ce2aa75670

Registered at: Subscan | Aggregate Substrate ecological network high-precision Web3 explorer

10 Likes

Community members are encouraged to provide feedback to Stella’s proposal here.

In the meantime, a proposal to whitelist the call has been created for the Technical Committee’s consideration.

Technical Committee members are individually deliberating the matter and have been asked to put in their vote of either Aye or Nay within the next 24 hours.

A reply will be posted following the close of the vote tomorrow indicating whether the call was whitelisted or not.

2 Likes

As noted in the BiFrost proposal fully in favor of this getting moved to hit the DOT unlock, it only happens once so Moonbeam needs as much of the DOT as it can get.
Did Lido give you this code?
Where is the code base?
Was it audited in the past?
Has your instance been audited at all?
Are there zero changes to what Lido had deployed?

Want as many places for this DOT to go but need to avoid a black eye if something is wrong with the code or has been changed.

3 Likes

Thanks for submitting this proposal @jj_Stella .

I have the same questions as @prison_mike - the benefits of a native DOT staking solution on Moonbeam are obvious, especially given the proximity of the DOT unlock, but I’m also aware that Stella Swap had to put this solution together under time duress.

Can you expand on what was done to make sure this solution is safe? To what extend was it modified from the Lido/Mixbytes solution? What precautions are being taken to ensure that there’s no risk due to an accidental misconfiguration or deployment error? Are there any audits that were performed and when was the last one? Etc.

Thanks.

1 Like

Thanks @prison_mike for taking time to review the proposal and supporting it.

Following are the answers to your questions:

Did Lido give you this code?:

The code was opensourced by Mixbytes the team that developed stDOT for Lido. The code is under MIT license.

Where is the code base?:

The official Lido’s stDOT codebase is here: GitHub - mixbytes/lido-dot-ksm: Lido KSM/DOT liquid staking

The team opensourced it by removing the Lido branding here: GitHub - NimbusTA/contracts

Was it audited in the past?

Yes it was audited by independent team at MixBytes than the team that created it. The audit report is here: https://github.com/mixbytes/audits_public/tree/master/Lido/Lido%20KSM

Has your instance been audited at all?

We haven’t performed audit on our instance given it’ll be exact fork. We’ve performed extensive difference checking and static analysis between Lido’s live codebase for stDOT along with code that’s audited and code that’s open-sourced and we didn’t find any redflags.

Are there zero changes to what Lido had deployed?

The open-sourced code has replaced Lido’s branding in code base to Nimbus.
For example modifier like onlyLido() is renamed to onlyNimbus().
Additionally we had to change RelayerEncoder’s Precompile interface to support the latest one that’s deployed on Moonbase and Moonbeam. The codebase performs read-only operations on Precompile.

Again we’ve made sure that any such change hasn’t modified any business logic on smart contracts.

We here at StellaSwap take security very seriously any incident can effects ecosystem, the protocol’s reputation and us morally. Our team has background in Information security and perform internal audits on smart contracts to make sure they’re solid before even sending out to auditors and for that reason the project audits rarely get any Critical or High Risk findings.

2 Likes

Thanks @sicco-moonbeam for taking time to review the proposal and understanding the benefits on native DOT staking solution for Moonbeam.

StellaSwap’s team has been looking into deploying this solution since last 1 month. As I mentioned in my reply to @prison_mike 's questions we’ve performed various things to ensure the codebase is safe including checking codebase against stDOT’s live codebase. Checking code against audited commit-hash of stDOT’s github code base. Ensure code-coverage on unit tests and static code analysis.

The modifications are mostly around branding of Lido in codebase to Nimbus along with change to support the latest RelayerEncoder precompile.

The misconfiguration risk is there given the fact that it uses XCM to transfer DOT and perform bonding, un-bonding and nominating using Multilocation derivative account. We’ve made sure the configuration scripts generate the right configuration by running tests on our Zombienet deployment. We’ve been conducting same tests on Moonbase Alpha with Aplhanet Relay Chain.

We’re currently performing tests using Acala’s Chopsticks to pass this proposal and then identify the behaviour on our deployment.

The audits were performed on Lido’s codebase by MixBytes and can be found here: https://github.com/mixbytes/audits_public/tree/master/Lido/Lido%20KSM

1 Like

I’m not a tech expert, but I think that the Moonbeam ecosystem can benefit greatly from this proposal. Acquiring more DOT and attracting more users can help Moonbeam grow and become even stronger. But, as mentioned earlier, it’s important to ensure the absence of risks.

3 Likes

I think it’s a great idea) it will be good if it turns out to be realized as planned.

2 Likes

I definitely think it would be a valuable idea. It will ensure that investors who care about Polkadot remain in the Polkadot ecosystem.

3 Likes

and not just stay, but nurture her growth. :+1:

2 Likes

Ok., thanks for clarifying @jj_Stella

2 Likes

Hi everyone,

The OpenGov tech committee has decided to whitelist this proposal to fast track it - a majority of the TC was in support and voted accordingly.

1 Like

Hello everyone,

The referenda is up for voting: https://moonbeam.polkassembly.network/referenda/26

2 Likes

Hey, sorry for late response, Totally agree, hope Moonbeam will get good Value and TVL from this

2 Likes

Totally support the idea. It could work for the benefit of the Moonbeam Network and the whole Polkadot ecosystem

2 Likes

I am sorry for late response , fully support !

1 Like

Take my full support also

1 Like

@jj_Stella, could you please edit the title of the on-chain proposal and also add a description for the proposal?