Proposal to add OCT as a new ckERC20 token

Governance NNS Governance
1

Dear IC community, I hope you support the proposal to add OCT as a new ckERC20 token. This motion is valuable for Omnity and will also benefit other IC eco projects.

Some of you may have known that Omnity was rebranded from Octopus Network, a multi-chain network supported by NEAR Foundation, DCG, Electric Capital, and other crypto funds. The team has been working on the blockchain interoperability domain since 2019. As a grantee of Cosmos Interchain Foundation, we were credited with implementing the trustless interoperability protocol IBC in a heterogeneous context, including NEAR and Substrate. Last year, the team started building on ICP and found that Chain Fusion is exactly the tech stack we were looking for. With ICP, we can resolve some headaches that have bothered the cross-chain domain for years. This recognition eventually led to the birth of Omnity, a fully on-chain interoperability protocol with great UX and a sound level of decentralization. Please refer to the Omnity light paper for more information, or you can try the protocol directly.

In Q1 this year, the team decided to concentrate on Omnity and join the IC eco. So, Omnity is not only a protocol name but also the project’s new name.

Octopus Network’s utility and government token was OCT, an ERC20 token issued on Ethereum but mostly used on NEAR for share-security staking and governance. OCT has a 100M fixed supply and around 95% circulation rate. Please refer to CMC for more information about OCT.

We plan to issue the Omnity SNS token OT in Q4 of this year and convert all OCT into OT. OCT currently has $300K in liquidity on NEAR (Ref Finance) and $400K on Ethereum (Uniswap V2). Some IC ecosystem investors want to establish OCT holdings to obtain OT conversion rights. Transferring trading liquidity from NEAR to ICP can meet these needs and help Omnity build a closer economic connection with the IC community. Additionally, this liquidity migration plan will directly increase the TVL and trading volume of ICP DeFi protocols, benefiting the IC ecosystem in multiple ways.

Omnity is dedicated to establishing the safest, most convenient, and widely used cross-chain protocol on ICP. However, we are newcomers to the IC ecosystem, and our understanding of IC governance is still limited. If any shortcomings or aspects of our proposal do not align with community practices, we welcome your feedback and will strive to improve accordingly. I appreciate your support!

Louis
Founder of Omnity

9 Likes
2

Hey Louis. Thanks for posting this on the forum. We’ve been looking for a place to communicate our vote on your proposal 130405. The CodeGov team decided to vote NO on this proposal for several reasons. Please see our post in our OpenChat community to learn the details that lead us to this decision. You are welcome to reply in this linked thread if you have questions or comments to share, but you’ll need to join the community to comment. It would be nice to hear from your team if you want to discuss the proposal further.

1 Like
3

Are these the only reasons, or is there something more?

Rejected because the git_commit_hash looks like it was copy pasted from the ckUSDC proposal.

Rejected. Build is successful, but the proposer provided the wrong git_commit_hash in the upgrade args.

this proposal needs more discussion from the community before having any legitimacy.

I support the project, but I agree that the proposal needs to be ironed out.

@toliuyi In general, it’s better to post a topic before making a proposal, especially to catch and correct any minor mistakes beforehand.

4 Likes
4

Hi wpb!

I am the proposer of proposal 130405. I appreciate CodeGov team for carefully reviewing this proposal.

The git_commit_hash in the upgrade args refers to the commit hash used when compiling ic-icrc1-ledger-u256.wasm and ic-icrc1-index-ng-u256.wasm.

The upgrade operation will directly use these two compiled WASMs to deploy the new ckERC20 canister. Before the ledger suite orchestrator canister uses new ledger WASMs, any newly deployed canisters should ideally use the same git_commit_hash as ckUSDC(as in proposal 130405). I have confirmed this parameter with member of the Dfinity team.

However, the source code for the ledger WASMs is in the IC repo, so as long as there are no changes to the ledger-related code in the IC repo, any subsequent commit should successfully validate the WASMs(as in proposal 130395).

I believe that the approach in proposal 130405 is better, and future ckERC20 proposals should follow this rule. The advantage is that we can clearly know the ckERC20 canisters deployed within a certain period are all using the same ledger WASMs, rather than comparing various different git_commit_hash and diffing the source code to know they are using the same code.

I would appreciate knowing if the CodeGov team agrees with my approach.

4 Likes
5

Thank you for your support!

2 Likes
6

Incredible, I had the opportunity to work with the Octopus team in LATAM, welcome to the ecosystem :muscle:

3 Likes
7

Yes, we need to learn more about the IC gov best practices and follow them.

1 Like
8

Hi, thanks for the feedback. I’m glad to see that CodeGov is acting like a gatekeeper to protect the IC community, especially to serve the interests of the non-tech people.

As my teammate Julian has explained, the git_commit_hash issue is not a mistake but a new practice, and we discussed it with the Dfinity team before submission.

But we should post here before or simultaneously with the proposal. Then we can exchange opinions before your casting. Lesson learned; surely we will do better next time.

4 Likes
9

Hey @juliansun and @toliuyi. Thanks for posting additional details about the proposal. I admit I was in a rush from meeting to meeting earlier when I posted and didn’t have time to give more explanation. I also gave the wrong link to our reviews initially. Here is the correct link. My apologies.

I believe we voted to reject out of an abundance of caution. The technical reason used by most of the reviewers was that the wrong ‘git_commit_hash’ was provided in the upgrade args. It appears to be a copy/paste from the ckUSDC proposal. I recognize in your comments above that this was not a mistake and it was confirmed with DFINITY. Perhaps you are right. I need our reviewers to comment further on this detail, but it would also be nice to hear from DFINITY.

Less technical reasons to reject were that the proposal came out of the blue without notice and there were too many unknowns to be comfortable voting to adopt. We noticed that the proposer ID had never made a proposal previously, which implies it came from the community. There was no announcement anywhere that we could find (until this forum thread posted by @toliuyi earlier today). Personally, I didn’t realize that DFINITY has already intended for the community to submit these proposals. Last I heard is was supposed to be a slow roll out with DFINITY still guiding the public discussions about what to release via the forum.

Hence, given our policy of reviewing and voting within 48 hours of proposal submission and erring on the side of caution, each of our reviewers felt the best answer was to reject the proposal. If it turns out that we are wrong and DFINITY finds nothing wrong with the proposal, then they will vote to adopt and it will execute by absolute majority. In that case, hopefully we can agree no harm, no foul. If it is rejected, then I encourage you to address any deficiencies that are discovered and try again. The CodeGov team is not trying to stand in your way on this proposal. We are just trying to make the decisions we believe are best for the network with the information we have at the time.

Thank you for understanding and thank you for providing further explanation about the proposal and your prior consultations with DFINITY about the proper parameters to use in the proposal payload.

7 Likes
10

Care to share who more exactly ? Thank you.

1 Like
11

Hi @juliansun ! Firstly welcome to the IC community.

I personally voted to reject cause I assumed DFINITY preferred if git_commit_hash provided was also the one used for the LSO, judging by the ckLINK proposal.
Upon further inspection, I see the spec has no requirements for that and considering what the hash is used for I agree what you propose makes more sense.

I’m sorry for the inconvenience, we’ve just recently started reviewing system canister management proposals and ledger instantiations with the LSO are a new development, so there is a bit of uncertainty on how to validate them.

Anyway congrats for being the first one from the community to go through this process.

5 Likes
12

I worked with @toliuyi to review their proposal, and the git_commit_hash being different in the ckLINK proposal was our fault: we advised Omnity to use the old commit hash, and later realized that it would be better to use the newer commit hash, but did not inform Omnity.

What does this git_commit_hash in the args do exactly? The ledger suite orchestrator wasm contains wasms for the ledger and index canisters. Whenever the LSO is upgraded, it stores those contained wasms in stable memory, and uses git_commit_hash as a “name” for them, which you can see on the LSO dashboard. The fact that these wasms are stored allows exactly what the ckLINK proposal did, namely use an older index/ledger than the version contained in the LSO itself. This was proposed that way to make sure that the ckLINK ledger/index run at the same version as the ckUSDC ledger/index.

So the proposal as submitted would work, but it would lead to a confusing wasm store of the LSO, where some canisters are having an incorrect git commit hash attached to them.

Clearly how this proposal uses git commit hash is quite confusing, so one takeaway for dfinity is to improve this and perhaps getting rid of that git_commit_hash arg altogether.

For this proposal, I think the best path forward is to

  1. reject this proposal due to the limited time the community had to review and the suboptimal use of git_commit_hash (which again, was dfinity’s fault)
  2. update the proposal, share a draft here asap, give some days in which codegov and others can hopefully already review, and then submit an updated proposal which will hopefully be adopted.

Thanks Omnity for being the first (outside dfinity) to submit a proposal for adding a ckERC20, and to codegov for carefully reviewing!

18 Likes
13

Thank you for explaining the reasons for rejecting the proposal in detail.
I fully understand the CodeGov team’s decision.

1 Like
14

We submitted a draft in the DFINITY - Omnity slack channel, where Manu reviewed it and identified several errors in the proposal.

2 Likes
15

Thank you for agreeing with my reasons, but please see Manu’s post below for the latest guidance.

1 Like
16

Thank you for your explanation.

I think that knowing different people/teams have different opinions about this parameter is not a bad thing at all. This indicates that this parameter indeed has some ambiguities, and by reaching a consensus, future proposals won’t have this issue.

The Omnity team agrees to reject the proposal for now. I will soon submit a draft following the approach used in the ckLINK proposal for the community to review.

5 Likes
17

Yes,

Thanks for this explanation of the git_commit_hash Manu.

I understand the desire to “control versions”, but indeed this system needs some polish, because on ckLINK a new commit hash was given, but the wasm versions were same as the previous commit. And what if someone desires a more advanced Ledger with an older Index, should it be allowed?

If yes to all, then I suggest a simple composable_key is best, like {#ledgerWasm_#indexWasm}. The commit hash is confusing, because it’s also possible that a new git commit (like a ReadMe change) exists without actually changing the wasms of either. The wasm hashes should be the best possible key.

But the “criteria” I missed the most was, on the future who chooses how “relevant” a coin is to be worth added to the tracker? If someone (let’s say a DEX operator) wanted to spam 1000 ERC-20 tokens, how could this be decided?
Currently IC Token holders trust Dfinity and CodeGov for the System Canister Management topic, and it’s difficult for us to be “governance” judges (we prefer more the technical correctness).

What I miss (and am suggesting) is the requirement that for every new ERC-20 tracked by the NNS, should be pre-approved on a Motion proposal, or else I confess that I would still reject a non-top 20 coin (whose bridge is more obvious).

Could this be considered as a good practice for future proposals of new “ck” orchestrated by an NNS canister?

1 Like
18

We support this proposal. Let’s get more liquidity into IC! Keep up the good work @toliuyi and the Omnity team!

19

Why top 20 and not top 100 or 1000? When you can verify the contract addresses, symbols, and other data for all these tokens on CoinMarketCap, what’s the difference? If you believe you can only judge the technical correctness, that’s fine. Leave the business value judgment to others. There are plenty of perspectives and knowledge within the IC community.

1 Like
20

I think the reviewers of these type of proposals also need guidance on the possible attack vectors we should be looking at when reviewing. We need to know the extent of the damage that can be caused if a wasm is upgraded with malicious code. I am not saying this because of OCT but because we are opening up to the community and the auditing shouldn’t be done just by Dfinity, since you all have a lot on your plate as it is.

1 Like