Project status + ideas

[doonte]

@noot @dimalinux What is the current status of this project?

Fees are high on mainnet. I could see this being used more on L2s like Optimism or Arbitrum or Base.

Ideas for revival, maybe in a separate project:

• Rewrite so that everything is done from a front-end interface and have the user make transactions from their native wallet instead of a monero daemon loaded with funds (more prone to missed windows if the user does not pay attention, but be clear with this to users)
• Use i2p for finding peers, no IP leaks
• Native eth L2 support high priority

[dimalinux]

@doonte I'd say the project right now is on maintenance mode. If something breaks, I'll fix it. Moving the project away from Ganache, which is no longer supported, is still on my TODO list, since we'll need the switch for continued testing. I would have already added support for L2s, but my concern is we that don't want to put too much effort into a technology that probably won't take off even with a 1st class GUI. If you have reason to believe otherwise, chime in. My thought is that systems that use liquidity pools will always provide a better user experience and better liquidity. I've started learning Rust so I can get my hands dirty with Serai or tooling around Serai.

[doonte]

Thank you for your response. I agree that liquidity pools will probably always be a better user experience. I see that Serai suggests it will use its own coin (SRI) for fees - it's a little disappointing to me that it doesn't make use of a more established coin or the coins provided as liquidity instead.

[kayabaNerve]

I see that Serai suggests it will use its own coin (SRI) for fees

That's not the use of SRI.

SRI is used as one side of every pool for efficient routing (we don't fragment ETH liquidity as ETH-BTC and ETH-XMR). We could use XMR as one side, yet then we don't have a value oracle for BTC/ETH/XMR in terms of SRI. We need a value oracle in terms of SRI to ensure economic security (the SRI stake necessary to misbehave with revenue has greater value than the revenue which would be gained). If we used XMR as stake, then using XMR for every pool would establish a value oracle in XMR terms and that'd be fine.

The issue is we can't use XMR as stake. It'd only be slashable assuming an honest multisignature, yet we need economic security to hold upon a dishonest multisig. We need a coin: 1) We can program the conditions on for partial failures 2) Is subject to market forces upon complete system failure

For more context on the latter, please read https://github.com/kayabaNerve/notes/blob/main/EconomicSecurity.pdf.