Building Permissioned Dapps With Para

There we go. Good afternoon. Thanks for coming to Building Permissioned Apps with PARA. I'm Matt. I've been asked to sit.

I'm Matt. I really do a little bit of everything at PARA, mostly focused on BD and partnerships, but handle and support our customers through the entire customer journey, from top of funnel to bottom funnel customers and helping them understand how they can use PARA to grow their apps. Before we get too deep into the technical conversation, I'm curious how many of you have used passkeys? Passkeys? Passkeys?

Four for four? Nice. Then much of this should feel familiar to you, but I'll help explain how PARA uses passkeys a little bit more in the presentation. PARA is the most comprehensive wallet and authentication suite for crypto applications, and I'll help break down what this means. We combine Web 2.

0 and Web 3.0 authentication with universal wallets. These universal wallets are secured using passkeys and MPC. MPC is multi-party computation. It helps us to ensure that the private key material is always secure and never stored or recombined or composed in one place where it might be subject to attack.

We also support EVM, really any EVM chain, in addition to Cosmos and Solana. I'm curious about the demographics in the room. How many of you have used Solana? All right, more than I might have expected. Happy to hear that.

I think I'll share a little bit more about my thoughts on multi-chain after we talk about Auth. Auth has been around for a very long time. It's not new in any way to Web 3.0. And what have we learned over the 40 years of the Internet?

I think one of my key takeaways is that people and apps prefer a single sign-on experience. We've had decades of Web 1 and Web 2 applications that have kind of brought us to this very familiar sign-in experience across all of the Web. It looks like sign-in with Google or sign-in with Apple, log-in with Facebook or log-in with Discord. There are obviously many other single sign-on providers in Web 2. But I think we've seen a clear preference 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 that users are comfortable with and familiar with and trust.

And in Web 3.0, what have we learned from 500-plus wallets? I was looking at a list yesterday, and it was like 495 different wallets. So I think I'm pretty comfortable saying we have over 500 wallets now. I also think that this list is ever-growing.

Every new chain seems to have its own new wallet. And then after they launch a wallet, someone decides that there's something that could be better about this wallet. So let's launch one too. And this has resulted in this world where nobody's on only one chain. 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 between your Safe. And now Safe has unified this experience, so you can really have a great multi-SIG experience on any EVM chain that they support. We've seen similar things happen with MetaMask, where I opened MetaMask the other day, and it said Solana on MetaMask. And I'm not sure how I feel about this.

I've gotten pretty comfortable with using Phantom or Solflair for my Solana activity and MetaMask for my EVM. But it's clear that you can't operate on one chain anymore and expect to serve the broad community of users. And we've seen the same from Phantom. Kepler now supports EVM in addition to Cosmos. I think they're expanding to Bitcoin and StarkNet and some others.

And wallets have really exploded into this category in and of itself in Web3. So let's talk a little bit more about wallets. It's really core to Para's business and core to the Web3 experience. And we often use a lot of words to describe wallets, describe how wallets are secured, how the private key material is stored. And all of these things can be very confusing.

I imagine most of you are familiar with what most of these terms mean, but I'll help put this together in a way that makes sense and gives you a better understanding of how we can combine these really innovative pieces of technology to build apps that are accessible for consumers. It kind of all started with PLS, a secure connection between your browser and a website where you can store a private key or store private key material and use that to very easily sign transactions on some app. I think one of the key takeaways is that wallets started as apps, and these apps were really 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 to hackers or to the apps themselves. And these wallets can intelligently and securely connect to apps and sign transactions at the user's request, typically. I think this is kind of the most well-understood category of wallets.

And one example that I think is kind of interesting to think back to is the burner wallet. This is one of kind of the first ways I experienced on-chain apps where you could just like spin up a wallet in an application. It was super easy to create. Typically, the private key is stored in your browser, so it's not particularly safe and quite fragile, where if you spin up a burner wallet and you might deposit some accounts and use it to interact with an app, then many times if you refresh the page or clear your cache, you've lost your wallet, you've lost your funds, and they can't be recovered. This is really good for trying out apps and giving people an easy onboarding experience into Web3.

But not very scalable and not very adaptive to increasing user needs and increasing the requirement for recoverability and self-custody. The next evolution that we saw was adding OAuth on top of this. And this goes back to the like making it familiar for Web2 users who have gotten so comfortable with clicking sign in with Google or sign in with Apple throughout their Web2 experience. And this really enabled apps to become wallets, where instead of apps relying on a library of 490 plus wallets to connect to their app and expecting users to self-discover which of those wallets were the best fit for them and their security preferences and their user experience needs, apps are now able to allow users to sign in, which feels so much more familiar and so much easier, eliminates a decision that the users need to make in order to sign up to your app, where they don't need to learn about a seed phrase. Instead of using a seed phrase, they can use a passkey.

I think it's been – I asked about passkeys at the beginning here because I think it's been really fascinating to see how quickly they've become mainstream. A year ago or two years ago, I think nobody used passkeys, and now Amazon supports passkeys. Gemini recently told me – I'm based in the U.S., so I'm a Gemini.

I have used Gemini Exchange. They recently said you have to have a passkey in order to continue accessing your accounts. Passkeys have not only solved the problem of easily hacked and easily guessed passwords, but also make it much easier for cross-device compatibility for users to have a passkey that's stored in their iCloud keychain or in their Google Password Manager that can be accessed from my iPhone or my iPad or my MacBook or even my Apple Watch. Then I think the biggest user experience improvement from this transition of apps becoming wallets is that users can stay in the context of a single application and experience all of 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. It is especially important on mobile 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. Even with deep linking, it often feels like you're on a carousel, switching between these apps to do simple transactions. Especially in the world of EVM where we've gotten quite comfortable with this token spending approval and then subsequent swap transaction signing paradigm, it's really important to be able to keep users in the app and see through what their intended transaction was, making sure that that gets executed. 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 I must not have signed an additional message or it didn't make its way to my wallet. Then somehow I still managed to open my browser and it's like MetaMask always has the red notification bubble on it.

I'm not sure who's requesting to connect, not sure what I forgot to sign, but this is a core piece of the friction of early Web 3 that now we're evolving to a point where apps can build without needing to account for the constant switching between app and wallet contexts. The next evolution, or this is to again think back to where we were a few years ago, where the initial combination of OAuth with wallets was in what we referred to for a period of time there as Web 2.5. I think nobody really talks about Web 2.5 anymore.

It was a weird time for the industry where people were wanting to do things on chain, but it wasn't possible to do it easily enough. Instead of enabling users to own their wallet and own their assets, they just take custody of the user's funds and manage private keys in a centralized database somewhere. This enabled very easy sign-in and sign-up to crypto apps, block apps that were settling transactions on chain, but necessarily very centralized because there weren't mechanisms to, in a decentralized way or in a permissionless way, allow users to access on-chain applications using an OAuth method or one of these familiar sign-in with Google or Apple. These wallets were native by design, considerably less fragile because there's a centralized entity that's in control of the private key and in control of the security. They were often very recoverable, so you could go through a similar forgot password flow and recover your blockchain account, which is a great improvement for users and the user experience and really good for low-risk, single-application experiences.

This example is, of course, NBA Top Shot. I think one of my favorite early crypto apps where it got me thinking about how cool it will be when fantasy sports are on-chain. And the obvious implication for NBA Top Shot is that you didn't have the ability to take your NFTs, your tokens, the things that you were owning and buying and using in NBA Top Shot, you weren't able to take them outside of that application and outside of that ecosystem. And this is part of the challenge that PaaS keys are helping to solve. PaaS keys and the introduction of embedded wallets enabled applications to really start offering wallets without needing to take on the risk of custody and managing private keys.

Embedded wallets are easy to create, easy to log in, especially with PaaS keys that can be shared between devices and much better for security. It eliminates the dependence on passwords and eliminates the possibility that if my email is compromised, now all of my crypto assets are gone. So this is really good for medium risk but also typically very siloed into a single application experience where if you've used 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 a new application. So incredible advantage, apps can now spin up wallets without custody using familiar OAuth methods, without needing to take on the custody risk, and they're able to provide the apps with seamless control over the user experience where embedded wallets no longer require users to click on a transaction confirmation every time, no longer require a pop-up into a browser extension or switch in context to another app on your phone. You can simply present the user with a button to execute and they can tap and transact just how they're familiar and used to in every other application they use every day.

The downside of most embedded wallets is that it fragments liquidity and fragments the user base where if a wallet can only be used in the context of one app, now you eliminate the possibility to share liquidity and you also introduce additional friction into the onboarding flow where now the user feels like they need to onboard to Web3 every time into every app that they want to use instead of feeling like you can onboard once and take those assets and that reputation and that identity with you. And ultimately, if there's more friction in the user experience, there will be more churn, 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. More friction almost always results in more churn. And this is what Para is using MPC to solve for where 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 of their funds and they can bring that account with them anywhere they go in Web3.

Typically, this is slightly more involved from a creation perspective where you do need to set up a passkey in addition to signing into OAuth, but the MPC is really entirely behind the hood or under the hood where users don't need to feel any additional burden for a heightened level of security. 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 create a character on one app and write a story on another app and then sell that story on a third app or buy a token over here and supply liquidity here and take the earnings from that liquidity and stake them on a third app. Building these cohesive experience requires an interoperable and universal solution that we offer using a combination of OAuth passkeys and MPC. And what this also enables is that users can try your app. Bringing back the burner wallet example, this is something that we've drawn some inspiration from in order to allow users to onboard to Para or onboard to Para's customers or onboard to your app by clicking continue as guest.

Continue as guest spins up a wallet for the user that can be fully featured They can receive funds. They can execute transactions. They can even refresh their browser window and it doesn't go away. And then they can then link a Web2 account to this burner wallet 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 might click around and take advantage of some sponsored gas transactions. Now they've decided to on-ramp or deposit funds and now they can link their Web2 authentication method to this Web3 wallet.

And then when they're ready to go a step further, adding a passkey to secure the wallet on their device and really take full self-custody of this account. This can be configured so that users only set up passkeys when they say on-ramp $100 or trying to transact above some threshold, maybe trying to bridge assets to another chain. You can prompt the user to secure their account by adding a passkey. And then bringing this all together kind of in the next steps of the users, user's journey and also the developer's journey with Para. There are a lot of things you can do combining MPC and passkeys with account abstraction.

Account abstraction provides a lot of benefits that EOAs currently don't support. There's a lot of, I think, exciting developments around 7702 that allow us to bring many of these benefits closer to the EOA level. But this enables you to take advantage of MPC-based accounts with recovery, high levels of security, social authentication. And then you can combine this with Sponsored Gas. You have options for multi-sigs and bundled transactions.

I think Sponsored Gas is kind of a baseline, like table stakes expectation for everyone building apps today where gone are the days where we can reasonably expect users are going to sign into our app and immediately on-ramp new funds and in many cases on-ramp two different tokens so that you can pay gas with one and then use the other one. And account abstraction brings this to life where you can now very easily, using a variety of providers, deploy contract accounts that make it easy for your app to look and feel like Web 2 in that users don't need to know about network fees 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 where users can, by default, leverage OAuth plus pass keys. But in some cases, you might want a heightened level of security and a heightened level of permission so that you ask users to set up SMS verification so that if they're transacting above a certain threshold, you can request a third factor of authentication so that they can always feel confident and trust that they're in control of their assets.

And then we get to permissions. With universal wallets that can be accessed on many apps, you can imagine that permissions is also a much more important topic than if an app is always in control of all of the wallets that their users are using. So this is an area that we're investing heavily in at Para in order to surface transaction permissions 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 with any of the tokens, that app is going to have to request the user to give them permission to execute the transactions that are relevant for the context of that app. This can also be accomplished using account abstraction and a smart wallet. You can do this in an even more configurable way with session keys where session keys can be created for each application context so that those applications have a very finite set of transactions and oftentimes a very finite quantity of tokens that they can access as well.

I imagine this to be similar to 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 clear and delineated permissions and purposes for these types of accounts and or session keys. Customizing permissions is, of course, also a very important piece of this permissions puzzle where some ideas that you can implement or to help you kind of think through how permissions might be structured. This is an example where HyperDrive wants to open a long position. You could also imagine there being permissions in place for an app that wants to execute on dollar cost averaging, deposit some funds, or even permissionlessly connect and approve swapping those funds at a later date.

Similarly, stop loss orders, limit orders, things 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, a very small number of transactions are executed because someone is clicking a button at their computer. Most of them are completed in an automated way. And I imagine this same convergence is going to happen on-chain as well, where today really the majority of on-chain transactions are happening because someone's at their computer clicking a button. And in the future, I imagine, especially with AI, everything is going to move on-chain in a much more automated way and without a user needing to sit in the middle at their wallet with their keys, ready to click approve.

And then we can bring this all together with account profiles, where we can give users privacy and control. control over their Web3 accounts linked to their Web2 profiles and linked to the profile of applications that they're connecting these to in Web3 so that apps can have very granular access to permissions that users have granted, which always gives users the maximum amount of control and ensures that apps are providing users with the maximum amount of transparency as well. We believe this is the best blend of user experience where users can still transact in an app and enable the app to transact for them 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 anywhere in Web3. So in summary, one account for all chains and all apps enables liquidity to be unified and also enables a much better user experience where users can sign in with familiar authentication methods with email, phone, or with socials, and enables them to onboard once and transact everywhere. Unified liquidity unlocks rapid growth.

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 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 go out into a different experience, download a second app, and lose the context of why I have this app on my phone and what I'm using it for every day. Privacy in a global wallet world looks much like this with the interoperability benefits of Web3 where trust is minimized. The users are explicitly trusting every app that they and we can look to the Web2 privacy model for a great North Star, I think, where people are 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 Web3.

Those permissions will look much different given that in Web3 you can move money and most accounts you're connecting Google to and Web2 are not moving money for you, but we can bring very similar user experience paradigms to Web3 in order to enable product flywheels and enable rapid growth. Where to next? We have quite a bit of time left here. I'm happy to go through integration guides for Para. I'm happy to go through the examples hub, which is hosted on GitHub and has code examples for a variety of things you can do with Para.

You can also scan these QR codes if you want to do this on your own. We'd love to hear from anyone in the audience on what you... 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.

All right. This is our examples hub. You can find this at GitHub.com slash get Para slash examples dash hub. You can also find it linked in our docs, which are available at docs.

getpara.com. To orient on the examples hub, I think there are, call it four main categories of examples that I would encourage you to orient yourself around, one being mobile, one being server, one being web, and then specialized. Web is, of course, examples with Para combined with React and other web frameworks. Mobile includes React Native, Flutter, Swift, Expo's in there too.

And server are server side use cases where you're signing transactions from your server. One of the things I'll note about the server is that there are two different ways you can use the server SDK with Para. One is with the traditional OAuth driven authentication model where the user has either created or signed into an account and then you can pass that session from your client to the server and then use the server SDK to sign transactions. The other paradigm where you can use the server SDK is in the context of pre-generated wallets. Pre-generated wallets basically allow you to skip or preempt the OAuth flow where you can generate a wallet using any unique identifier and then use the server SDK to sign transactions for that wallet either before or in lieu of the user claiming the account.

So you might perform some transactions and then at some point want the user to claim, and there are examples for that as well. And then specialized include a variety of integrations between Para and additional providers or other use cases like using Para in a Chrome extension or with ElectronJS or using it in conjunction with the JupyterDEX API. We recently released these new examples where you can use Para in conjunction with Relay or with Squid so that you can very easily swap funds from one supportive network to another token on another supportive network. And then Telegram web apps. There's an example here if you're building a Telegram app and want to use Para wallets.

The Telegram web app uses the pre-generation method that I was referring to before where instead of needing the user to authenticate because in the context of Telegram they're already authenticated, 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, and then the user can use this to transact from Telegram either by interacting with a bot. We have a few API or a few agent apps that are using Para wallets or via a mini app in the web experience embedded in Telegram. What's everyone's favorite mobile framework? Do we want Swift, React Native, Flutter? I'm going to choose Swift because I'm an iOS guy and this is also the one where we have some cool new features.

So in the Swift SDK, and this is generally true for most of these samples hub, you can find a variety of use cases. So the first thing that you probably want to do when you're building a mobile app is authenticate users, have people sign up. And there are three different ways or kind of broadly three different ways you can do this with Para. And I think generally three different ways you could do this with any app. You can authenticate users with an email address.

You can authenticate them with a phone number. You can authenticate them with a wallet. So you can support, and I guess we'll lump OAuth in with email since it's pretty similar. So you'll see examples here where you can use OAuth, you can use phone, you can use email here, and external wallets. External wallets are how we refer to MetaMask and Phantom and Kepler and Leap and any of the wallets that you're probably most familiar with given the Web3 Native audience in the room.

But you can very easily deep link between a Swift app built with Para and whatever external wallet app you want to connect to. This is where I'll take the chance to share with you my personal opinion. And I think it's like, I'd be interested to know if anyone disagrees. 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 anything else, then they should just use the web browser and use the web app.

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. And then that allows you to build on mobile in a much more clean interface that's much better tailored to the users that you're looking to reach with your mobile app. 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. And you can offer an experience that feels much more native to them if it's just phone number or just email.

Or you can support OAuth methods to the extent that's interesting 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 virality or create stickiness, then it makes sense. But that's a personal aside about my distaste for the switching app context constantly on mobile. Similarly, within AfterAuth, you can connect Cosmos wallets, you can connect EVM wallets, you can connect with within the embedded context. You can even support multiple.

We have a lot of apps that are building on multi-chain. I think it's important to provide a cohesive experience for your users 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. So you should feel free to 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.

Let's see what else we have in here. Country codes, extensions. That might be it for the Swift app. I didn't bring a cable or I might try to share the Swift app with you. Let's take a look at web.

Web is where we have, I think, by far the most examples. Most of our customers are building on web, but you can clearly see that it's categorized by framework. React with Next.js, I think, is the most commonly used example, and you can see similar functions and similar examples here where this top one is client-off. So you're authenticating on the client and then passing the session to the server, and then you a transaction as the server.

There are a variety of ways, I think, where this could be helpful, particularly if you're expecting that many of your users have poor connectivity. It's going to be difficult for them to sign transactions on mobile, 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. Other examples would be if you want to execute transactions after the user has left the application session. Some of the examples I referred to earlier being dollar-cost averaging, stop-loss orders, limit orders, any ways that you might expect a user to give you an intent to execute something at some point given some condition, you can now do this server-side with a customizable session length where you can make the sessions last as short as a few minutes or as long as 30 days. Para also has connectors with RainbowKit and Wagme available here.

I can show you an example of our RainbowKit connector here on the ENS app where you can see Para is one of the options integrated into RainbowKit so that applications who have gotten very comfortable and happy with the RainbowKit experience to support Web3 natives can easily add Para to support Web2 natives in the same experience with whatever authentication options they want. Similar to what we saw in Swift, you can authenticate with email, you can authenticate with phone, you can authenticate with OAuth, and these things can be customized to the extent you want a completely white-labeled experience. That's entirely possible. The Para modal is what you can see. Anyone can go to check it out at demo.

getpara.com. This is the default option for most teams building on web where it's the easiest way to customize the look and feel of this modal by dropping in your logo, changing the fonts, changing the colors, and then selecting what authentication methods you want to support. 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.

I mentioned this a bit earlier, but continue as guest allows me as a user to get a taste of the application before I sign up for anything. Now my wallet's been created and I'm free to explore the app, sign transactions, receive before I even verify my email address. Then we also have integrated on and off ramps that can be configured here with Stripe, Ramp, and Moonpay. This is the web modal and this is what the experience in the examples hub is built on as well. With this modal, you can generate code that you can then easily copy and paste into your app.

We have examples using the modal for Cosmos, using the modal for AVM, using the modal for multi-chain, and using the modal for Solana. Then pre-gen and claiming. I mentioned pre-gen a little bit about generating an account, really preempting the user authentication. Then the claiming process goes through the same authentication flow and enables the user to take ownership of that account by refreshing the keys and setting up a passkey. Then signer examples.

You can sign with Cosm.js if you're working on a Cosmos chain. You can sign with Ethers. You can sign in Solana Anchor Programs, Solana WebSuite.js, and AVM is supported as well.

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 Bund, Deno, Node, but most of the examples follow the same themes. You're creating wallets, you're authentication, you're wallet creation, and transaction signing.

Yes. Absolutely. In our docs, we'll transition over to docs. You can find this custom chain link that walks you through using Para with custom EVM chains, SVM chains, Cosmos chains. If you want to use a Solana signer on an EVM layer 2, for example, it's an option available for you.

Again, support for Ethers, VM, Wagme, Solana Web3.js, and Cosmos, Cosm.js. Any other questions? Yes.

So, is everything we need to integrate Para all on the front end, or is there some kind of incentive open source, or there's some kind that is some sort that we have to work with? The question is about is Para open source, and is there some trust on the back end? Para is built on open source MPC protocol. Our SDKs are not open source, but you can gain access to Para by going to developer.getpara.

com, and you'll obtain an API key. So, I can show you what the developer portal looks like, and where you can get an API key to authenticate. All right. Thank you. So, now I'm presenting my passkey and connecting to the Para developer portal, and then once in, our developer portal v2 is coming soon, so this is all soon to be changing, but once you have a project and you're signed in, you can just create an API key for that project, and then you use this API key for authentication on your app.

Can I ask a question? So, what kind of security dependency does an app integrating with Para has on the SDK or on the API? You authenticate with this API, and this API can be exposed publicly. You can control what domains can use this API using the 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 server side verification of sessions and managing sessions and things like this, you can use this secret API key server side as a second layer of authentication.

Okay. So, I'm going to apologize if I'm going to make a stupid question, but in terms of the interaction with the user wallets and what kinds of things the users are going to be signing, how much of the things the user has to sign comes from Para? None of it. None of it. You're building the transaction logic, and you're sending it to the RPC.

You're just using Para to sign the transaction. Okay. And how can the user easily verify that the transaction that it's getting on Para is the same that the transaction that I'm sending to the user? So, I'm just worried about seeing the latest attack on the safe about spoofing signatures, and so how can the users be secure and the protocols can be secure about these kinds of things? This is an area we've been spending a lot of time thinking about as well, and there's a configuration that's now available to developers to show the pop-ups for a transaction confirmation.

We, by default, don't show any pop-ups for users to confirm or review simply because that's what's most demanded from our customers and from, I think, end users looking for a very frictionless experience. But we very much share the concern and have recently enabled this so that now users or apps can force pop-ups so that users can review the transaction information. Of course, that's still dependent on the applications providing this information, but creates an additional layer of complexity, or additional layer of transparency, and then you can add an additional layer of verification on top so that when transaction pop-ups are shown, the user might need to either present their face ID again or present an OTP code from SMS in order to authorize the transaction. I have made several questions already, and 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 pop-up for a user for a transaction, the content of the pop-up comes from the API from Para, or does it come from the local application? We have kind of a mapping between what we expect the applications to send and how that should appear to the users. If it's outside of this mapping, then it does not appear nearly as nice, but it looks something like this. So HyperDrive has given us instructions on how we should interpret something as an open long position.

Similarly, like closed long position, short long position, et cetera. So it is very dependent on a manual exercise 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. If you know of any solution for 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 forward to some magic like that.

Great. Anyone else? All right. Great. Well, if you have any other questions, I'll probably be downstairs and