SIP-0057: Add Ordinal Doge Token ($oDOGE) to Sovryn AMM Pools

TLDR: Do the promoters of this SIP have a good plan on how they will execute it?
If the answer is yes, I am in favor.
If the answer is no, I am strongly opposed.

On Bitocracy as Guardian and Free Markets as Protector
One of the duties I think Bitocracy has is to shepard the Sovryn ecosystem as a home for sound economics and finance. We should create an environment with safeguards against systemic risk and outright fraud.
While I do not consider meme tokens to be sound finance, I also think the fact that they are so transparently pointless is all the protection people should need. If people want to trade these things, cool, then that’s on them.
Overall, unless there are clear systemic risks or fraud, I think the best protection is the free market.

On SIPs as Executables
SIPs can have direct power of the protocol. The genius of “code is law” is that in the case of an executable SIP, the very passage of the vote is also its execution.

This is not the case with this SIP. This SIP has no executable component. As a result it requires someone to take action in the future to action it.

over the last couple of weeks I have been trying to find devs who are available and interested in introducing the smart contract changes, changes to UI and changes to the subgraphs that could make this SIP executable. However, because so much is going on, I haven’t managed on this count.

I would like to ask the promoters of this SIP if they have a team ready to execute this SIP, should it pass? Or is their plan to see if it passes and then look for a team?
I hope it it not the later.

It would be very unfortunate for a SIP to be approved and then not be executed on. In cases where that seems to be likely a highly likely outcome, I think we should vote against by default.

Therefore, my questions to the promoters of the SIP:

  • What is you plan to deploy the code changes required for this SIP?
  • How do you intend to make sure the code changes are safe and secure?
  • Why have you not specified that plan (as far as I can see)?
4 Likes

I would like to know more about the nature of the code changes required to have this SIP executed - or any other project which would like to be present on Sovryn DEX.

1 Like

In case the required steps are indeed too cumbersome to get a coin listed through a SIP, the technical procedure to get a coin listed is a crucial issue to be improved soon. It doesn’t make sense to repeatedly impose the same effort to the supports any token, to be possibly listed on Sovryn.
Even if we don’t move to permissionless listing, the technical procedure itself should not be more complicated than on Uniswap.
Of course, bridging a token to the RSK network has to be accomplished. However, for ERC20 tokens it should be possible to implement a straightforward procedure facilitating this process.

1 Like

I don’t have a strong opinion one way or the other about this project. But I want to make sure the community has full and accurate information before voting.

My understanding is that the Sovryn trading/AMM contracts were forked from bZx. bZx has the ability for users to create their own pool. So unless Sovryn actually deleted this capability in the code, the basic infrastructure should be there to quickly and easily spin up a new pool pair. Also, I haven’t looked at the FE code, but it’s hard to imagine that adding a new asset is much more than editing a few text files and dropping in an icon.

Regarding the ability to find devs, my understanding of a SIP passing Bitocracy is that it expresses the priorities of the stakeholders in the project. If this passes, it says that current priorities need to be rearranged. That is, devs should be made available for this task at the expense of existing projects. Devs should not be allowed to pocket-veto a SIP because they’re not “interested” or it’s not their current personal priority.

Maybe @Ororo could respond to this with an estimate of the dev effort required to execute this SIP.

8 Likes

It was not forked from bZx but bancor. The smart contracts allow anyone to add a pool to the network. There is a script for it in our repository. It’s called addConverter.js. Anyone can use it to add a new pool, but it’s not self-explanatory. While adding pools to the AMM is permissionless, adding them to the FE is not. A PR for adding the pair to the FE is therefore also required. Probably also un update to the Graph. Please also consider that the FE might have issues if the second trading pair is not RBTC. I therefore advise to anyone to only add RBTC pools if you intend for the pool to be supported by the Sovryn dapp UI.

While these changes are relatively simple, they are not effortless and require coordination for a successful launch. Therefore the sprint plans of all sub-teams need to be synched, which would lead to a delay. (If the Sovryn core team would do it)

What I’m missing on the SIP description is how it is going to be bridged. Multichain? Or is it supposed to be bridged by the Sovryn token bridge? The latter would add extra effort.

There’s also the question of the initial liquidity provision. It is suggested that the oDoge team adds it. Are they supposed to do this programmatically? Or using a graphical user interface? If the latter, there will be extra effort if that interface should be open only for them (so that no-one else provides the liquidity and therefore sets the price first).

8 Likes

The way the current AMM mechanism work will it allow for lockup liquidity?
The current assets that exist to trade, have they had a way to lockup liquidity or indeed oDoge will be the first asset that will need a lockup thing?

About the bridge, we will need to approach BabelFish about it.

1 Like

my biggest surprise is that only now, when its up to voting Yago and Ororo shows up to give any feedback or additional information.

are you surprised this actually got all the way to a SIP and voting?

if this was said earlier, we could have had a proper discussion.

2 Likes

Thanks for the details and clarification.

Regarding bZx, what aspect of Sovryn was forked from it? According to the wiki, some code from bZx was forked for Sovryn, and bZx audits are listed:

https://wiki.sovryn.com/en/technical-documents/audits

1 Like

bruh, only now has some shit got off theirt plate. not sure if you noticed but a whole bunch of stuff have just been released.

3 Likes

I’m not completely sure what you mean with “lockup liquidity” but assume that you mean a way to allow them to add liquidity before anyone else can do anything on that contract. We never had that case before because it was always us adding the initial liquidity (and removing it later when it was no longer required). When launching a pool for a different team (like MoC), they sent us their tokens, we provided the liquidity and afterwards sent them the pool tokens so they have the ownership.

Regarding the bridge: It is not maintained by Babelfish, but by Sovryn. Babelfish is just very tightly integrated and required for the XUSD bridging.

the lending pools and margin trading

Some more additional information: We had an interface for permissionless pool-creations on the roadmap in the past, but it got deprioritized. Instead, we focused on Zero and DLLR first.

I know that there are many cool and helpful tools and features we could build, but we cannot do everything at once.

Join the community calls to get insights into what’s planned and to discuss any pain points and / or what features you’d like to see on the dapp. It is difficult to develop new things AND stay on top of everything which is discussed in the forum. Replying late on a forum thread does not mean that I am not interested in your opinions.

15 Likes

As you may see from my comment, I didn’t feel like I had a lot to contribute to the discussion. Only questions. And given everything else that was going on, I put it off. My bad.

1 Like

I agree, we should make adding tokens as easy as possible to increase dapp volume, collaboration with other projects, and increasing excitement around sovryn’s ecosystem.

2 Likes

I love this thought process and has shown to be the right decision. However, moving forward, would it be in sovryn’s best interest as an ecosystem to allow an easy way for new projects to add to Sovryn’s AMM? This would more than likely increase collaboration with other projects and help offload some of the work from our devs and incentivize other projects to work with us or build their own features that may benefit us as well? Thank you for all your hard work.

1 Like

I agree on most of this, however this would be the first AMM not requiring funds from exchequer but rather outside teams/projects, this would increase trading pairs at no cost to us and increase trading and rewards to the protocol and allow for speculation and collaboration with this project and future projects. There is very little downside and little to no risk of implementing this other than speculating on the token and the price goes down. Open to be proven wrong on this, this is just my speculation.

the AMM should be open to everyone. The centralized control is precisely the reason why the project has not been as successful so far as it could have been.

It is not either open to everyone, or else centralized control. It can be under decentralized control through Bitocracy governance, project per project. I was suggesting that, when the community does this well, this could make listing and providing liquidity more interesting to external parties, as it is a bit of marketing, they get to be discussed, read into, and when they pass, it indicates quality. When the AMM is entirely open, it is only interesting to quality projects when Sovryn already has the trading volume, not before.

Uniswap is so successful for a reason.

The reason is far more complex than just being an open AMM. For one, Uniswap was a first mover. People seem to think that listing tokens will magically create trading volume (as if there are not a zillion CEXes/DEXes that list anything that you can throw at them but which hardly generate volume…).

This SIP will fail because the team will block it out of dictatorial spite

No, I’m a community member, not part of the team, and voting against this, and there are many others. I find the oDoge framing really misleading. Some people think that a trading telegram group where the more degen-inclined community members come together is somehow representative of the wider community. That’s pretty silly. I even saw polls being held there… This wouldn’t be so bad if it didn’t cause the mistaken idea that if it’s voted down this goes against ‘the community’ or is due to the core team. It’s not, it just has less community support than some expected, that’s all.

this should not stop us from asking for more power for the community and for a truly decentralized and permissionless Sovryn project instead of the centralized project

That is a fair concern, but then that’s a discussion about the upgradeability of the contracts and about when it is time to give Bitocracy more direct un-mediated control. I wish something like SIP46 had the sort of support that this memecoin is getting (which isn’t a true memecoin; it pretends to give ownership over some ordinal, while it doesn’t, and so misleadingly pretends to give you some value, as opposed to e.g. Doge which doesn’t pretend to be or give you anything).

3 Likes

@theberni - why do you think the “SIP will fail because the team will block it out of dictatorial spite”?

The “team” is not a cohesive unit. Do you refer to those with founder tokens? They do not have a majority. And, if you look at the addresses that voted, it seems they mostly abstained from this particular vote.

But putting all that aside - where does this idea of “dictatorial spite” come from? What actions have been taken, and by whom, that hint at such dictatorial impulse?

3 Likes