@divine_economy: Why every crypto app should use Para embedded wallets

Submit
@divine_economy
@divine_economy

we spent nearly a full year evaluating embedded wallets as the space massively evolved—before deciding that the logical choice right now is @get_para. i want to explain why i firmly believe every crypto app should take this approach—when very few are. above all, *it’s worth waiting* if you can. most apps in crypto take the view that you need to start by building for *all* users, and that’s a take I think is egregiously wrong. the users for crypto apps right now are crypto natives. they understand how to use blockchains, they’re patient with the UX issues that arise from RPC and liveness failures, and they’re interested in using crypto products. one of the biggest mistakes you can make when first building an app is to try to capture all your potential users, instead of focusing on the power users that will give you feedback and share it excitedly with their friends. in crypto, those power users are crypto-native users, which is why there are almost no non-crypto users using apps today. it’s a bit silly to start off trying to target them when crypto as a whole is—compared to web2—very much in beta. and what wallets do these crypto-native users like to use? their own. @get_para stands out here. many embedded wallets require you to depend on them as your wallet kit provider for full feature support. this is a massive liability for apps and users alike, who are fully dependent on a wallet kit that can go out of business or quadruple its fees. it just recreates the problems faced by web2 apps with app stores that can take giant fees. by contrast, para makes it easy to integrate alongside any other wallet in an external wallet kit (in our case, rainbowkit). you don’t need to depend on them as your wallet kit. that means you can continue supporting users with their native wallets, just as you always have. but more importantly, it means your whole business isn’t dependent on them. if they 10x their fees, your entire flow isn’t dependent on them. you don’t have to lock users out of their accounts or give the embedded wallet your entire profit. and Para is especially helpful here, since it easily lets users recover their wallets if needed without complex configurations. this is important in terms of UX, business profits, and ideology all at once. users have always demanded self-custody to protect their coins in crypto. likewise, apps should insist on avoiding web2 app dependencies that have jeopardized good businesses for a decade. finally though, wallets themselves are changing rapidly. passkey authentication—which para enables—has opened a whole terrain in the last few months for smart wallets, which let people log-in in-browser without needing to download and switch out to a separate app. this is a massive, extremely exciting gamechanger for UX, led by @coinbasewallet. smart wallets are gud. as an app builder, you should try to prioritize them when you can since they remove the dependency risks of embedded wallets while supporting the same native UX. the beauty of para is that it both operates similarly to smart wallets while still letting you integrate smart wallets easily as well. it gives you and your users optionality to decide how they store their funds—which is better UX for crypto-native users, and better security for non-crypto users. and better business for apps.

Confetti (@confetti_win)

We love @get_para. And today we’re excited to integrate it as the first embedded wallet we’ve ever enabled. That means anyone can come to our site, pick Para as their wallet, and start playing in contests—no crypto experience required. Choosing Para was a no-brainer for us bec…

Tweet image
x.com

@divine_economy: Why every crypto app should use Para embedded wallets

AI summary of the linked article

The author, writing as @divine_economy, argues that every crypto app should use Para embedded wallets, and that builders should wait before committing if they can. The argument is that crypto apps currently serve crypto-native users, who prefer their own wallets, so building for all users first is a mistake. The post contends that Para can be integrated alongside an external wallet kit such as RainbowKit, so an app is not dependent on Para as its wallet kit provider, which would expose it to risks like fee increases. It also says Para supports passkey authentication, which enables smart wallets such as those led by @coinbasewallet, and that smart wallets are preferable where possible.

avatar
Can someone explain why Para has no vendor lock in? It seems this tweet doesn‘t outline it