scrtlabs / EthereumBridgeFrontend

Frontend for the Ethereum<>Secret Network bridge
Other
9 stars 22 forks source link

wSCRT bridge improvements #51

Open uxt-exe opened 3 years ago

uxt-exe commented 3 years ago

I've had the pleasure of messing with the early wSCRT bridge on Rinkeby/Holodeck, and wanted to share some areas that could be improved.

The most significant feedback is that wSCRT should ideally wrap and unwrap from SCRT, not sSCRT. This is important because a major use case for wSCRT is independently obtaining the ability to call contracts and send transactions.

This, of course, requires SCRT, so the user is stuck trying to find at least 0.05 SCRT somewhere. It's further compounded by the fact that sSCRT makes for a confusing user experience. The funds appear missing. Without understanding the subtle distinction (and procuring some SCRT), they will think there are problems and get frustrated.

Additionally, I think the bridge UI could be improved. As a developer I'm well aware that wSCRT is an ERC-20, but I think most users will mentally consider wSCRT, sSCRT, and SCRT to be one collection. They will also largely use these three conversions more often than any other arrangement.

Rather than try to be pedantic, we should focus on immediate usability - I'd like to see a special area of the page, or tab, specifically devoted to conversion between these three types in an elegant, straightforward way. Similar to Opensea's wETH station and the special tab that can be found in Keplr for sSCRT, with some warnings against spending all your SCRT and some other simple explanations built in.

uxt-exe commented 3 years ago

@cankisagun

cankisagun commented 3 years ago

SCRT <-> wSCRT is hard b/c the bridge is built between SNIP20 and ERC20s.

Good feedback re SCRT - wSCRT - secretSCRT - thanks!

baedrik commented 3 years ago

SCRT <-> wSCRT is hard b/c the bridge is built between SNIP20 and ERC20s.

Good feedback re SCRT - wSCRT - secretSCRT - thanks!

I would agree that the bridge should be between wSCRT and SCRT instead of sSCRT.

The wSCRT<->SCRT bridge should already have to process differently than the ETH<->sETH bridge, because the ETH-> bridge locks tokens on the ethereum side and does minting and burning of SNIP20s on the SN side.

The SCRT-> bridge should be locking SCRT on the SN side and minting and burning wSCRT on the ethereum side. Since there won't be minting/burning on the SN side, it would be much better to lock SCRT than sSCRT so that the bridge wouldn't have to send dust, and people wouldn't have to beg for secret-pizza

Of course if the plan is to just use sSCRT for v1 if that can get it out the door quicker I can understand that. But v2 should definitely be with native SCRT. There really shouldn't be a need to bleed out dust forever.

mohammedpatla commented 3 years ago

Agree with @baedrik and @uxt-exe . I think this is important, as its not possible to use the Secret Network withot SCRT.

Unless we have a 3rd-party integration that can convert cash/fiat to SCRT instantly and globally (so it's not region locked)

cankisagun commented 3 years ago

The community is more than welcomed to contribute to this effort. We need to prioritize AMM development efforts

There's a faucet for each new address created on SN that gives out 1 SCRT. While the UX is not the best, that's more than enough to pay for most TXs