DAPPCON 2025: Building Permissioned Dapps With Para - Matt Zimmerman

Transcript

There we go. Good afternoon. Uh, thanks for coming to building permissioned apps with Parah. Uh, I'm Matt. I, uh, been asked to sit. So, uh, I'm Matt. Um, I really do a little bit of everything at PAR. Uh, mostly focused on, um, BD uh, and partnerships. um but handle uh and support our customers through the entire customer journey um from top of funnel to uh bottomfunnel customers and helping them understand how they can use parah um to grow their apps. Um before we get too deep into uh the

technical conversation um I'm curious how many of you have used pass keys? Pass keys. Pass keys. Four for four. Nice. um then much of this should feel familiar to you. Um but I'll help explain how PAR uses pass keys um a little bit more uh in the presentation. Um PAR is the most comprehensive wallet and authentication suite for crypto applications. Um and I'll help break down what this means. Um we combine web 2 and web 3 authentication um with universal wallets. These universal wallets are uh secured using pass keys and MPC. Uh MPC is multi-party

computation um and helps us to uh ensure that the private key material is always secure and never uh stored or recombined or composed in one place where it might be subject to attack. Um we also support uh EVM really any EVM chain um in addition to Cosmos and Salana. Um I'm curious about the demographics uh in the room. Uh how many of you have used Salana? All right. Still we more more than I might have expected. Um h happy to hear that. I think um I'll share a little bit more about my thoughts on multi-chain um after we talk about O. Uh Oth has been around for a very long time. It's not uh

it's not new in any way to web 3. Um, and what have we learned over the 40 years of the internet? Um, I think one of my key takeaways is that people and apps prefer a single sign on experience. Um, we've had uh decades of web one and web two applications that have kind of brought us to this very familiar sign-in experience across all of the web. looks like sign in with Google or sign in with Apple, login with Facebook, uh or login with Discord. Uh there are obviously many other single sign on providers in web 2. Um but I think we've clean seen a clear preference um both for people who

are using apps and for builders who are building apps that it's easier on both sides to provide a single sign on experience uh that users are comfortable with and familiar with and trust. And in web 3 what have we learned uh from 500 plus wallets? Um, I was looking at a list yesterday and someone it was like 495 different wallets. Uh, so I think I'm pretty comfortable saying we have over 500 wallets now. Uh, I also think that this list is ever growing. Um, every new chain seems to have its own new wallet.

Uh, and then after they launch a wallet, someone decides that there's something that could be better about this wallet. So, let's let's launch one too. Um and this has resulted in this world where uh nobody's on only one chain. Um this is true with safe where original versions of safe were deployed on a single chain and if you wanted to deploy the same safe on another chain you might end up with a different contract address. There was not much interoperability uh between your safes. Um and now safe has unified this experience. So you can really have uh a great multi-IG experience um on any EVM chain that they support. Uh we've seen similar things

happen with MetaMask where I open MetaMask the other day and it said Solana on MetaMask and I'm not sure how I feel about this. I like gotten pretty comfortable with using Phantom or Soulflare for my Salana activity and MetaMask for my EVM. Um but it's clear that uh you you can't operate on one chain anymore and expect um to to to serve the broad community of users. Um and we've seen the same from Phantom. Kepler now supports EVM in addition to Cosmos. I think they're expanding to Bitcoin and Soul and and Starknet and some others. Um and uh wallets have really exploded into this this category

in and of itself in in web 3. Um, so let's talk a little bit more about about wallets. Um, it's really core to to to Parah's business. Um, and core to the uh web 3 experience. Um, and we often use a lot of words to describe wallets, um, describe how wallets are are secured, how the private key material is stored. Um, and all of these things can be very confusing. Um, I imagine most of you are familiar with with with what most of these terms mean, but I'll uh I'll help put this together in a way that makes sense and and gives you a better understanding of how we can combine these like really innovative pieces of

technology um to build apps that are accessible for consumers. It kind of all started with TLS um a secure and uh a secure connection between your browser and a website um where you can um store a private key or store private key material and use that to very easily sign transactions on some app. Uh I think one of the um key takeaways is that wallets started as apps. Um and these apps were really um simple in that they allowed users to securely store their private keys somewhere. Have confidence that those keys were not going to be leaked or exposed um to to hackers or to the apps

themselves. Um, and these wallets can intelligently and securely connect to apps and sign transactions uh at the user's request typically. Um, I think this is the kind of the most well understood uh uh category of wallets. Um, and one example that I think is kind of interesting to uh think back to is the burner wallet. Uh this is one of kind of the the first ways I experienced onchain apps where you could just like spin up a wallet in an application. Uh it was super easy to create. Uh typically the private key is stored in your browser. So, it's not particularly safe um and quite fragile where if you uh spin up a burner wallet and you might

deposit some accounts and uh use it to interact with an app, then many times if you refresh the refresh the page or clear your cash, you've lost your wallet, you've lost your funds, and uh they can't be recovered. Um so, this is really good for trying out apps and giving people uh an easy onboarding experience into web 3. um but not very scalable uh and not very um adaptive to increasing user needs and and and increasing the the requirement for recover recoverability and self- custody. Uh the the next evolution that we saw was adding OOTH on top of this. Um, and this goes back to

the like making it familiar for web two users who uh have gotten so comfortable with clicking signin with Google or signin with Apple um throughout their web two experience. Uh and this really enabled apps to become wallets where instead of apps relying on uh a library of 490 plus wallets to connect to their app and expecting users to self-discover which of those wallets were uh the best fit for them and their security preferences and their user experience needs. Um apps are now able to allow users to sign in which feels so much more familiar and so much easier. uh

eliminates a decision that the users need to make in order to sign up to your app. Um where they don't need to learn about a seed phrase. Instead of using a seed phrase, they can use a pass key. Um I think it's been I I asked about pass keys at the beginning here because I think it's been really fascinating to see how quickly they've become mainstream. uh a year ago or two years ago I think uh nobody used pass keys and now Amazon supports pass keys. Gemini recently told me uh I'm based in the US so I'm a Gemini I I have used Gemini exchange. Um they recently said you have to have a pass key in order to continue accessing

your accounts. Um, and pass keys have uh not only solved the problem of like easily hacked and easily guessed passwords. Um, but also make it much easier for uh cross device compatibility for users to have a pass key that's stored in their IC iCloud keychain or in their Google password manager that can be accessed from uh my iPhone or my iPad or my MacBook or even my Apple Watch. Um, and then I think the biggest uh user experience improvement from this transition of apps becoming wallets is that users can stay in the context of a single application um, and experience

all the features that that app enables without needing to switch into the context of a different app just to connect or to sign every transaction. Um, and this is especially important on mobile, um, where it's not a browser extension popping up and you're still staying on the app. It's like actually switching apps on your phone. And even with deep linking, um, it often feels like you're on a carousel, uh, switching between these apps to do simple transactions.

um especially in the world of EVM where we've gotten quite comfortable with this like token approval, token spending approval and then subsequent swap uh transaction signing paradigm. Um it's really important to be able to keep users in the app um and and see through what their intended uh intended transaction was, making sure that that gets executed. Um, I don't know how many of you might admit to this, but I will definitely admit that there have been multiple times where I thought that I made a transaction or I thought that I made a swap only to return later and realize like I must not have signed an additional message or it didn't make its way to my wallet and then somehow I

still managed to open my browser and it's like MetaMask always has the red notification bubble on it and I'm like not sure who's requesting to connect u not sure what I forgot to sign. Um, but this is the core uh a core piece of the friction of early web 3 that uh now we're evolving to a point where apps can build uh without needing to account for uh the constant switching between uh between app and wallet contexts. The next evolution um or this is kind of uh to to to again think back to where we were um a few years ago where the initial combination of uh OOTH with wallets was in what we kind of referred

to for a period of time there as web 2.5. Um I think nobody really talks about web 2.5 anymore. It was kind of a weird time for the industry where people were uh wanting to do things on chain but there it wasn't possible to do it easily enough. So instead of enabling users to own their own their wallet and own their assets they just take custody of the users's funds and manage private keys in a centralized database somewhere. Um, this enabled very easy sign in and sign up to uh crypto apps, block apps that were settling transactions on chain. um but

necessarily very centralized um because there wasn't there weren't mechanisms to in a decentralized way or in a permissionless way allow users to access onchain applications uh using an ooth method or one of these familiar signin uh signin with Google or Apple. These wallets were native um by design considerably less fragile um because the there's a centralized entity that's in control of the private key and in control of the security. Um they were often very recoverable so you could go through a similar forgot password flow and recover your blockchain account. Um which is a great improvement for users and the user experience. um and really

good for uh lowrisk um single application experiences. Uh this example is of course NBA Topsh Shot. I think one of one of my favorite early crypto apps um where it got me thinking about how cool it will be it will be when fantasy sports are on chain. Um, and the uh obvious implication for NBA Topshot is that you didn't have the ability to take your NFTts, your tokens, the things that you were owning and and buying and using in NBA Topshot. You weren't able to take them outside of that application and outside of that ecosystem. Um, and this is the uh the part of the challenge that

pass keys are helping to solve. um pass keys uh and the introduction of embedded wallets um enabled applications to really start offering wallets without needing to take on the risk of custody and managing private keys. Uh embedded wallets are easy to create, easy to log in, especially with pass keys that can be shared between devices. Um and much better for security. um eliminates the dependence on passwords and eliminates the uh possibility that um if my email's compromised now all of my crypto assets are gone. Um, so this is really good for

medium risk um but also typically very siloed into a single application experience uh where if you've used um apps with embedded wallets most times you sign into the app and you get a brand new wallet even though you may have already created a wallet elsewhere you don't have the option to bring that into uh a new application. So, incredible advantage. Apps can now spin up wallets without custody using uh familiar OOTH methods um without needing to take on the custody risk. Um but and and they're able to uh get provide

the apps with seamless control over the user experience. um where embedded wallets no longer require users to click on a transaction confirmation every time, no longer require a popup into a browser extension or switching context to another app on your phone. Uh you can simply uh present the user with a button to execute and they can tap and transact just how they're familiar uh and used to in in every other application they use every day.

The downside of of most embedded wallets is is that is that it fragments liquidity and fragments the user base. um where if a wallet can only be used in the context of one app um now you eliminate the pos possibility to share liquidity and you also introduce additional friction um into the onboarding flow where now the user feels like they need to onboard to web 3 every time um into every app that they want to use instead of feeling like you can onboard once and take that those assets and that reputation and that identity with you. Um, and ultimately if there's more friction in the user experience, uh, there will be more churn and more

drop off where users might not get through the flow. They might create an account but not on-ramp funds or create an account and then try to on-ramp funds and they realize they need to KYC and they're a little bit scared and decide not to. Um, more friction almost always results in more churn. Uh and this is what PA is using MPC to solve for where we can we offer universal embedded wallets where the embedded wallet can be linked or is linked to the user rather than the app.

So the user is always in control uh of their funds and they can bring that account with them anywhere they go in web 3. Um, typically this is slightly more involved from a creation perspective where uh you do need to set up a pass key in addition to signing into OOTH. Um, but the MPC is really entirely behind the hood um or under the hood where users don't uh need to feel any additional burden for a heightened level of security. Um, and this is really a good fit for any medium to high-risk applications and any ecosystems that want to provide a cohesive experience across all of their apps and allow users to uh create and

create a character on one app and write a story on another app and then sell that story on a third app. Um, or buy a token over here and supply liquidity here and take the earnings from that liquidity and stake them on a third app. um building these cohesive experience requires an interoperable and universal solution um that uh we offer using a combination of of ooth pass keys and MPC. Um and what this also enables is that users can try your app. Um, bringing back the the burner wallet example, um, this is something that we've drawn some inspiration from in order to allow users

to uh, onboard to Parah um, or onboard to Par's customers or onboard to your app. Um, by clicking continue as guest um, continue as guest spins up a wallet for the user that can be fully featured. uh they can uh receive funds, they can execute transactions, they can even refresh their browser window and it doesn't go away. Um but and then they can then link a web two account to this burner wallet or or effectively burner wallet in order to have progressive self-custody and graduate from being just a user who's maybe trying out an app for the first time and uh might

click around and uh take advantage of some sponsored gas transactions. Um, now they've might decided to on-ramp or deposit funds and now they can link their web two authentication method to this web 3 wallet. And then when they're ready uh to go a step further, add a adding a pass key to secure the wallet on their device and really take full self custody of this account. Um, this can be configured so that uh users only set up path keys when they've say on-ramped $100 or trying to transact um above some threshold uh maybe trying to uh bridge assets to

another chain. You can prompt the user to secure their account uh by adding a pass key. And then bringing this all together kind of in the in the the the next steps of the users users journey and also the developers journey uh with parah there are a lot of things you can do combining MPC and pass keys with account abstraction. Um account abstraction provides a lot of benefits that that uh EOAS uh currently don't support. Uh there's a lot of uh I think exciting developments around 7702 that allow us to bring many of these benefits closer to the EOA level. Um but this enables

you to take advantage of MPC based accounts with uh recovery um high levels of security, social authentication. Um and then you can combine this with sponsored gas, the options for multi-IGs and bundled transactions. Um, I think sponsored gas is kind of a a baseline like table stakes expectation for everyone building building apps today where gone are the days where we can reasonably expect users are going to um sign into our app and immediately on-ramp new funds and in many cases on-ramp two different tokens so that you can uh pay gas with one and then use the

other one. Uh and account abstraction brings this to life where you can uh now very easily um using using a variety of providers deploy contract accounts that make it easy for your app to look and feel like web 2. Um in that users don't need to know about network fees. Um and they don't need to know about seed phrases. They don't need to know about all of these things that may have felt quite daunting to them in the past. You can also add third factor for authentication um where users can um by default leverage OOTH plus pass keys. Um, but in some cases you might want a heightened

level of security um and a heightened level of permission so that you ask users to um set up SMS verification uh so that if they're transacting above uh a certain threshold um you can request um a third factor of authentication so that they can always feel confident um and trust that they're in control of their assets. And then we get to permissions. Uh with uh universal wallets that can be accessed on many apps, you can imagine that permissions is also a much more important topic than if uh a wallet's always in or than if an app is always in control of all of the wallets that their

users are using. Um so this is a an area that we're investing heavily in at Parah um in order to surface transaction uh permissions um between the app and the user so that when a user connects a wallet to a new app that may have been and this wallet may have been created in a completely different context instead of just assuming that that app can do any of the things um with any of the tokens um that app is going to have to request the user um to give them permission to to execute the transactions um that are relevant for the context of that app.

Um this can also be accomplished using account abstraction and and a smart smart wallet. Um, you can do this in an even more configurable way with session keys where session keys can be be created for each application context so that those applications have a very finite set of of transactions and oftentimes a very finite uh quantity of tokens that they can access as well. Um, I imagine this to be like similar to uh like a checking in a savings account where a user might want to do a completely different set of things with the funds that are in their savings account as opposed to the funds that are in their checking account. And now there can be um clear and delineated

permissions and purposes for these types of accounts um andor session keys. Customizing permissions I is is is of course uh also very a very important piece of this permissions puzzle. Um where some ideas uh that you can implement or some or to help you kind of think through how permissions might be structured. Um this is an example where hyperdrive wants to open a long position. You could also imagine there being uh permissions in place for an app that wants to execute on dollar cost averaging um deposit some funds or even permissionlessly connect and and and approve swapping those funds at a later

date. Uh similarly, stop-loss orders, uh limit orders, um things where the app where the user is expecting a transaction to happen at some point other than when I'm clicking this button sitting in front of my computer. I think in traditional finance today, uh a very small number of transactions are executed because someone's clicking clicking a button at their computer. Most of them are completed in an automated way. uh and I imagine this is uh going to this same convergence is going to happen uh onchain as well where to date really the majority of onchain transactions are happening because someone's at their computer clicking a

button um and in the future I imagine especially with AI everything is going to move um move onchain in a much more automated way and without a user needing to sit in the middle uh with at their wallet with their keys like ready to click approve. And then we can bring this all together with account profiles where we can give users privacy and control over their web 3 accounts linked to their web 2 profiles and linked to the profile of applications that they're connecting these to in web 3. So that apps can have very uh granular access to uh

permissions that users have granted which always gives users the maximum amount of control um and ensures that apps are providing users with the maximum amount of transparency as well. Um, we believe this is the best blend of uh user experience where users can still transact in an app and enable the app to transact for them uh in a very frictionless way but still ensuring that the user is always in full self-custody of their accounts, always in ownership of their assets and that they can take those assets with them uh anywhere in web 3.

Um so in summary, one account for all chains and all apps uh enables um liquidity to be unified and also enables a much better user experience where users can sign in with familiar au authentication methods with email, phone or with socials and enables them to onboard once and transact everywhere. uh unified liquidity unlocks rapid growth. um com combining this with instant onboarding really enables applications to focus on finding product market fit with a specific purpose rather than this paradigm that I think we've seen a lot of over the last few

years where applications feel like they applications and especially wallets feel like they need to incorporate all possible things that you can do on chain into a single app and fail to really find uh a hardcore niche where people are going to this app to do the same thing over and over and instead returning to this app to kind of discover where I might go and then they might uh go out into a different experience, download a second app um and lose the context of why I have this app on my phone and and what I'm using it for every day.

Um, privacy in a in a global wallet world looks much like this with with interoperab the interoperability benefits of web 3 uh where trust is minimized. The users are explicitly trusting every app that they connect to. Uh and we can look to the web two privacy model for a great um uh for a great um north star I think where people are very na very familiar now with the ability to sign into your Google account. You can revoke permissions. Every new one you sign into asks for a very clear set of permissions. And we can do the same thing in web 3. uh those permissions will look much different given that in web 3 you can move money

and most uh most accounts you're connecting Google to and web two are are not moving money for you. Um but we can bring very similar user experience paradigms to web 3 in order to enable uh product flywheels and enable rapid growth. Um where to next? Uh we have quite a bit of time time left here. Uh I'm happy to go through uh integration guides for parah. I'm happy to go through the examples hub which is more uh it's hosted on GitHub has code examples for a variety of things you can do uh with parah. Uh you can also scan these QR codes if you want to to do this on your

own. uh would love to hear from anyone in the audience on what you uh is there is there anything that I didn't cover that you were hoping to get from this session? All right, let's go to the examples hub. Uh, all right. So, this is our this is our examples hub. You can find this at github.comparaamples-hub.

[Music] Uh, you can also find it linked in our docs which are available at docs.getpara.com. um to orient to to orient on the examples hub. I I think there are call it four main categories of of examples that I would encourage you to orient yourself around. One being mobile, one being server, one being web and then specialized. Uh web is of course examples with uh parah combined with react um and other web frameworks.

Mobile includes React Native, Flutter, Swift. Um, Expo's in there too and server are server side use cases where you're signing transactions from your server. Um, one of the things I'll note about about the server is that there are two different ways you can use the server SDK with PAR. One is with the traditional ooth driven um authentication model where the user has either created or signed into an account and then um you can pass that session from your client to the server and then use the server SDK to sign transactions.

Um the other paradigm where you can use uh where you can use um the server SDK is in the context of pre-generated wallets. uh pre-generated wallets basically allow you to skip or preempt the O flow where you can generate a wallet using any unique identifier uh and then use the server SDK to sign transactions for that wallet um either before or in lie of the user claiming the account. So it uh you might perform some transactions and then at some point want to want the user to claim and there are examples for that as well.

Uh and then specialized include a variety of integrations between parah and um additional providers um like or other use cases like using parah in a chrome extension or with electronjs or using it in conjunction with the jupiter uh the jupiter dex API. Um, we recently released these new examples where you can use parah in conjunction with relay or with squid so that you can very easily um swap funds from one supported network to another token on another supported network.

And then telegram web apps uh as an example here. If you're building a telegram app and want to use uh want to use paralle wallets um the telegram web app uses the pre-generation method that I was referring to before where instead of needing the user to authenticate uh because in the context of telegram they're already authenticated uh it pre-generates a wallet stores it in the telegram's app storage or stores the user's key share in the telegram's app storage uh and then the user can use this to transact uh from Telegram either by interacting with a bot. We have a few API or a few um agent uh apps that are using par wallets um or via a mini app

in the like web web experience embedded in Telegram. Um what's everyone's favorite mobile uh mobile framework? Do we want Swift, React Native, Flutter? Uh I'm going to choose Swift because I'm an iOS guy. Uh and this is also the one where we have some the cool new features. Um so in the Swift SDK and this is generally true for most of these folders uh in the examples hub you can find a variety of uh of use cases. Um so the first thing that you probably want to do when you're building a mobile app is authenticate users have people sign up.

Uh and there are three different ways or kind of broadly three different ways you can do this with parah. Um and I think generally three different ways you could do this with any app. Um you can authenticate users with an email address, you can authenticate them with a phone number. Uh you can authenticate them with uh a wallet. Um so you can support um and I guess we'll lump oath in with email since it's pretty similar. Um so you'll see uh examples here where you can use ooth, you can use phone, um you can use uh email here and external wallets. Um external wallets are how we refer to uh MetaMask

and Phantom and Kepler and Leap and any of the um wallets that you're probably most familiar with given the web 3 native uh audience in the room. Um, but you can very easily deep link between um a Swift app built um with PAR and whatever external wallet app you want to connect to. Um, this is where I I'll take the chance to like share with you my personal opinion and I think it's like uh I'd be interested to know if anyone disagrees. Um, I I don't think that mobile apps should be built with the

option to connect to another mobile app. I think that if you are building for an audience that wants to use their wallet app, whether that's Phantom or Safe or MetaMask or uh anything else, then they should just use the web browser and use the web app uh and they can access it in the browser that they want to use and then they don't need to suffer from switching mobile apps on this carousel every time they need to authorize a transaction or connect. Um, and then that allows you to build on mobile uh in a much more clean interface uh that's

much better tailored to the users that you're looking to reach with your mobile app. Uh, I generally think that if you're looking to launch a mobile app, it's because you're looking to reach users that are probably not accessing your app through Phantom or MetaMask or Backpack or Ledger. Um, and you can offer an experience that feels much more native to them if it's just phone number or just email. Um, or you can, you know, support OOTH methods to the to the extent that's interesting um, in the context of your app. If you can pull some data from Google or pull some data from Apple or pull some data from X that might help you create verality or create

um, stickiness, then it makes sense. Um, but that's just that that that's that's a personal aside about my distaste for the switching app contexts constantly on mobile. Um, similarly uh within um after off you can um connect Cosmos wallets, you can connect EVM wallets, you can connect Salana wallets. Um you can really support any chain you need um with within the embedded context. You can even support multiple. We have uh a lot of apps that are building on multi-chain. Um I think it's important

to provide a cohesive experience for your users uh regardless of what chain they're used to operating on or think they want to operate on. My opinion again is that I don't think users should care. I don't think that they'll ever care. Um, so you should feel free to like spin up as many wallets as you need for these users to take advantage of and use in order to accomplish whatever it is that your app is bringing them access to. Um, let's see what else we have in here.

country codes, extensions. Um, that might be it for the uh for the Swift app. I didn't bring a cable or I might try to share the Swift app with you. Um, let's take a look at web. Web is where we have I think by far the most examples. Uh, most of our customers are are building on web. Um but you can clearly see that it's categorized by by by framework. Uh React with Nex.js I think is the most common uh commonly used example. And you can see similar functions and similar uh examples here where this top one uh is client off. So you're authenticating on the client and

then passing the session to the server and then you sign a transaction as the server. There are v a variety of ways I think where this could be helpful. Um particularly if you're expecting that many of your users have poor connectivity. Um it's going to be difficult for them to sign transactions on mobile. Uh so you might want to by default pass all of their sessions from a mobile client to the server and sign transactions server side especially if latency is a concern. Um other examples would be if you want to execute transactions after the lo user has left the uh application session. Um some of the examples I referred to earlier being

um dollar cost averaging, stop-loss orders, limit orders. um any ways that um you might expect a user to give you an intent to execute something at some point given some condition. Um you can now do this server side with a customizable session length. Um where you can make the sessions last as short as um a few minutes or as long as 30 days. Um PAR also has uh connectors with Rainbow Kit and WagMe available here. I can show you um an example of our our Rainbow Kit connector here in on the ENS app where you can see uh parah is one of

the options integrated into Rainbow Kit. So that applications who have gotten very comfortable and happy with the Rainbow Kit experience uh to support web 3 natives can easily add parah to support web 2 natives in the same experience with whatever authentication options they want. Um similar to what we saw in Swift, you can you can uh authenticate with email, you can authenticate with phone, you can authenticate with uh OOTH. Uh and these things can be customized uh to the extent you want a completely white labeled experience. Um that's entirely possible. Uh the paramodal is what you

can see anyone can go to check it out at demo.getpara.com. This is the uh default option for most teams building on web uh where it's the easiest way to customize the look and feel of this modal by dropping in your logo uh changing the fonts, changing the colors, uh and then selecting what authentication methods you want to support. Um I think it looks pretty nice if you go with something like this.

where you've got email or phone for the people who understand what connect wallet means. They're able to self- select that option and find the wallet or continue as guest. Um mentioned this a bit earlier uh but continue as guest allows me as a user to uh get a taste of the application before I sign up for anything. Now my wallet's been created and I'm free to uh explore the app, sign transactions, receive um before I even verify my email address.

And then we also have integrated on and off ramps uh that can be configured here with stripe ramp and moon. Um so this this is the web modal and this is what the the experience uh in the in the examples hub is is built on as well. Um and this with this modal you can generate code that you can then easily uh copy and paste into your app. Um so we have examples using the modal for Cosmos, using the modal for EVM, using the modal for multi-chain and using the modal for Salana.

Um and then pregen and claiming. Uh I mentioned pregen a little bit um about generating an account really preempting the user authentication. Uh and then the claiming process goes through the same uh authentication flow and enables the user to take ownership of that account by refreshing the keys and setting up a pass key. And then signer examples. You can sign with CosmJS if you're working on a Cosmos chain. Um you can sign with ethers. Uh you can sign Salana anchor programs. Salana web3JS. Um and VM uh VM is supported as well.

Um I'll pause there. Anyone have any questions? We talked about the specialized examples, server, again broken down by framework. You can do things with bun, demo, uh, node, but mostly the examples follow the same themes. You're creating wallets, uh, your signing or your authentication, your creat wallet creation, and transaction signing. Um, yes.

Absolutely. So, in our uh docs, we'll transition over to docs. You can find this custom chains link that walks you through using parah with custom EVM chains, SVM chains, Cosmos chains. Um, if you want to use a Salana Signer on an EVM layer 2 for example, it's an option available for you.

Um and support again support for ethers VM Wagmei Salana web3JS and Cosmos COSMJS. Any other questions? Yes. The question is uh about is parah open source and is there some trust on the

back end. Um, PAR is built on open- source MPC protocol. Um, our SDKs are are not open- source. Um, but you can gain access to uh PAR by going to developer.getpara.com and you'll obtain an API key. Um, so I can show you what that the developer portal looks like um and where you can get an API key to authenticate. All right. Thank you. So now I'm presenting my pass key and connecting to uh the parah developer portal.

And then once in um par our developer portal v2 is coming soon. So this is all uh soon to be changing. Um but once you have a project uh and you're signed in, you can just create an API key for that project and then you use this API key for authentication um on your app. And can I ask a question? So uh what kind of security um dependency does an app integrating with par has on the SDK or on the API?

um you authenticate with this API and this API can be like exposed publicly. You can control uh what domains can use this API using the um allowed origin setting in the developer portal so that only the origins you allow can use the API that you're providing. And then for server use cases, we actually recently launched a second secret API key where if you want to do any um server side verification of sessions and and managing sessions and things like this, you can use this secret API key server side as a second layer of authentication.

Um okay, so I'm going to apologize if I'm going to make a stupid question. Uh but uh in terms of uh the interaction with the user wallets and what kinds of things the users are going to be signing uh are they getting the how much of the things the user has to sign comes from the from parah maybe that's none of it none of it you're you're building the transaction logic and you're sending it to the RPC, you're just using parah to sign the transaction.

Uh, and how can the user easily verify that the transaction that it's getting on Spar is the same that the transaction that I'm sending to the user. So I'm just worried about uh you've seen this latest attack on the on the safe about spoofing signatures and so how can the users be secure and the protocols can be secure about this kinds of this is uh this is an area we've been spending a lot of time thinking about as well. Um and there's a configuration that's now available to users to show or available to developers to show the popups um for transaction confirmation. Um we

by default don't show any popups for users to uh confirm or review uh simply because that's what's most demanded from our customers and and from I think end users looking for a very frictionless experience. Um but we very much share the uh concern um and have recently enabled this so that now users or apps can force popups so that users can review the transaction information. Um of course that's still uh dependent on the applications providing this information. um but creates an additional layer of of complexity and

then you can add u or additional layer of transparency and then you can add an additional layer of verification on top so that when transaction popups are shown the user might need to either present their face ID again or present an OTP code from SMS in order to to authorize the transaction. I have made several questions already. I'm not sure if I can make another one but go ahead. We don't have too many people clamoring for the mic. So if you have a popup for a user uh for a transaction uh the content of the popup comes from the API from para or does it come from the local application? Uh we have kind of a mapping between what we expect uh the applications to send and what that

how that should appear to the users. Um if it's outside of this mapping then it does not appear nearly as as nice. Um but it looks something like this. So like hyperdrive has given us instructions on how we should interpret something as a open long position. Um similarly like close long position, short long position etc. Um so we're it is it is very dependent on like a manual exercise uh or an opportunity to automate it in the future but where our

applications are putting in effort in order to make sure that these things are clearly displayed to the users. Um, if you know of any solution for like automatically parsing this information and presenting it in a human readable way, I would love to hear about it. No, I do not. I'm looking looking forward to to to some magic like that. But great. Um, anyone else? All right, great. Well, if you have any other questions, uh, I'll probably be downstairs and grab