 My name is David Snyder, that's Chris Casano, and as you can see, we're going to talk about decentralized programmable key pairs. We are the two co-founders of a project called Lit Protocol, and to start with a big, exciting hook. We are living in a world where with threshold cryptography, from a certain point of view, you can consider that private keys no longer exist. So what do we specifically mean by this? This Lit network is essentially a distributed custody programmable key, and one of the key technologies at the heart of this is something called a DKG, a distributed key generation. And so what Lit is specifically is a distributed network of nodes that are custodian shares of an underlying private key. I'll take a quick moment to talk about how security works on this network, and then we'll get into some of the use cases. But essentially, this key is formed in this distributed key generation context and stored as shares across these nodes, and then all of the nodes operations take place inside of a trusted execution environment, and then there are named node operators who are staking that are running the programs on this underlying key. And so now let's talk about what some of those programs can be. So as you know, a key can functionally do two things. It can read or encrypt and write, and this network provides the same functionality in a programmatic way. So let's talk about how the read works first. The hexagons in the middle represent the Lit nodes. In this case, Alice, let's say, is a creator and wants to say anybody who owns Alice's NFT can see her video. She would encrypt that video client side and store it somewhere in public, whether it's on a blockchain or a storage network like IPFS, and then create a set of rules that says only somebody who owns Alice's NFT can see that video. Bob owns that NFT. He shows up later. He signs a message, and he broadcasts that to the nodes. Each of the individual nodes validates against the blockchain. Does Bob own that NFT? And the whole kind of frame of view here is thinking about these public storage, excuse me, public state machines, as access control lists. At which point the nodes verify that Bob has that node, or excuse me, has that NFT, and each of the individual nodes produces something called a decryption share. You could think about this like an authorization. Those authorizations are then sent to Bob, who's collecting them client side, and a good mental model is kind of similar to the way that you may think about torrenting. You know, torrenting, you're collecting little bits of media from a bunch of nodes. In this case, you're collecting bits of authorization. And once you've collected a threshold of those authorizations, in this case, decryption shares, Bob can reproduce that symmetric key associated with the video or that content and decrypt that client side. And so some of the applications that we're seeing this use for today are things like token-gated social media, like token-gated chat. This technology is used hand-in-hand a lot with the lens protocol, for example, where only let somebody who's following me on lens see my posts. We also see this happening in the context of intellectual property, whether it's token-gated videos or various other content. And then really excitingly, there's also been a lot of stuff around verifiable credentials and selective disclosure. So I'm sure you all are familiar with the notion of signing in with Google as an authorization method for how one logs into a site. What we're starting to see is some teams build this out in a much more kind of user sovereign type of way, whereby when a user goes logs into a site, they're conveying decryption rights, or quote, the read rights, to that application to see their private information. And it starts to become like a pretty interesting picture and we'll talk more about what this user-owned web looks like. But in a way, this is kind of one definition of Web 3, where the user, rather than necessarily showing up to a website with their own kind of self-sovereign server, they're arriving with their own encrypted shard of the open web and then selectively disclosing to various friends or applications what information from that shard they can decrypt or read. And so this product has been out since January. We still are running all the nodes centrally and we'll have those decentralized by the end of the year. And there's hundreds of applications that are leveraging this. But just last week, we started talking publicly about new capacity, which is the ability to essentially do distributed custody programmatic signing. And as you can see, the architecture is incredibly similar, but instead of the nodes reading the blockchain as an access control list, they are reading programs that are stored at a specific CID on IPFS. Each of those nodes is running those programs. And now in this case, instead of producing the decryption share, which lets that party decrypt some content, they're producing a signature share. Again, coming back to the idea that keys can functionally do two things, kind of encryption and signing. And then those shares can be aggregated and you can make a right to your favorite decentralized state machine, like Ethereum. And so talking about some of the applications for this, there's a huge list, right? Thinking about the key as an application development platform, we kind of like think about it as a paintbrush. We're really just starting to explore some of the application potential here, but I'll run through a couple right now. So one would be like DeFi automation. The state-of-the-art for self-custody DeFi today is if you have some staked tokens and the state-of-the-art is to sign up for some DeFi alerting service, such that when the price starts to drop, you get a text, you have to wake up in the middle of the night and push a button on your ledger. But in a world where you've staked those tokens from one of these cloud wallets, as we can kind of call them, you could have that program listening to a feed and when the price drops, have a program that kicks off, that unstakes the tokens, sells them for USDC on a dex and sends them to your ledger. And this is all happening kind of without a human signer in the loop because the key is custodyed in this distributed context at the network level. Chris will talk a little bit more about vaults, but in a way what we're talking about here is making private keys liquid. So you could send a bunch of NFTs and tokens to a given address and then trade the underlying ownership of that address. There's also a lot to explore here as it relates to account abstraction, doing things like hooking up biometric auth like Apple pass key as the auth method into one of these cloud keys in this whole context of how do we bring the next billion users into this ecosystem and abstract away the complexity associated with the seed phrase. This is really exciting and certainly a lot to explore in the context of cross-chain messaging and bridging as well. And so with that, I'll pass this clicker off to Chris. Thank you, David. Yeah, so I'd like to introduce the idea of a decentralized programmable key pair, which we call PKPs. A PKP is an ECDSA key pair that's held as private key shares, custodied by the lit nodes. You can create a PKP by minting an NFT that represents ownership over that PKP. And so whoever owns that NFT can ask the PKP to sign anything on their behalf, including Ethereum or even Bitcoin transactions. You can do this by writing some JavaScript code that we call a lit action. So this is a really basic hello world lit action. It literally signs the string hello world with ECDSA. And what happens is this code will be run on all the lit nodes in parallel. Lit actions live on IPFS and are immutable, just like smart contracts. And I just explained that whoever owns the PKP NFT can request a signature using the PKP. But what's actually more interesting is that you can also grant the ability to sign using your PKP to a lit action. This is very similar to the token approval pattern that we use on Ethereum, where you can grant a smart contract the ability to transfer your tokens. But instead of granting the ability to transfer tokens, you're granting the ability to sign anything with this programmable key pair. So here's how it actually works. The user can create a lit action execution request, which you can see at the top there. Oops, wrong button. I think I had a laser, cool. And they pass in an IPFS CID, which is some JavaScript code, and a cryptographic signature that could come from their Ethereum wallet, an Apple passkey, or any public key cryptography scheme. They send that execution request to all of the lit nodes in parallel. The lit nodes use a JavaScript runtime to execute the lit action from IPFS. They check the PKP authentication by talking to a blockchain where the PKP NFT lives. And the lit action can also make arbitrary HTTP requests. So it can also act as a kind of oracle. So you can pull any data in and use it in your JavaScript lit action. The lit action can request a signature using the threshold private key share that creates a signature share that gets sent down to the user that initiated the request. They could be using a browser or this could be like a server-side client. They combine those signature shares and they broadcast that signed transaction to Ethereum or any ECDSA blockchain. And I'm talking about a transaction here, but it doesn't actually have to be a transaction. It could be any signed data, like a write on a ceramic or anything else like that. An interesting pattern that LitSupports is called Mint Grant Burn. The idea is that you mint a PKP, grant it the ability to use a lit action, then burn the PKP in a single atomic transaction. This means that the PKP can only ever be used by that lit action because burning the PKP makes it impossible to use the PKP for signing anything else. A kind of fun toy example would be creating a lit action that takes any number as input, but will only sign that number if it's prime. Since anyone can check that the signature matches the public key of the PKP, they know that any number signed by the corresponding private key must be prime and the signature acts like a proof that the number is prime. You end up with a kind of prime number certification system. This can be used to create a proof of a lit action to create a proof of any JavaScript code execution. This is kind of similar to how ZK proofs work conceptually, but instead of being proven by pure math, it's proven by the guarantees provided by threshold cryptography via the lit network. Here's kind of how that works. The way that you interact with and grant access to use things is by talking to a PKP smart contract that currently lives on Sello, but we're going to move that to Polygon soon, and you mint the PKP, grant access for it to use the lit action in this authorized lit action table, and then you burn it all in one transaction. We talked a little bit about using a PKP as a vault. You can mint a PKP, then send a bunch of assets to it like NFTs, tokens, Ethereum, and even ones not on Ethereum, like Bitcoin or Cosmos tokens. Then you can sell the PKP NFT on OpenSea and transfer all the assets at once. You are essentially trustlessly trading a private key, something that has been impossible until now. This breaks soulbound tokens, because now you can trustlessly sell the wallet that contains your soulbound tokens in the same way that you could sell a traditional non-soulbound ERC721 NFT. This also enables things like liquid staking for chains that lock up the staked tokens, like Ethereum 2. You could use a PKP as an EOA cloud wallet. Because a PKP can grant the ability to sign to a lit action, you can create any auth method that you want, as long as it's possible to express it in JavaScript. You could create a wallet that will only sign if the user calling the lit action is a member of a DAO. You could use another signature algorithm for verification that's unsupported by Ethereum, like ED25519 or BLS. You could even create a wallet that will only sign transactions on Tuesdays. You can use a PKP for automation, because the lit nodes do the actual signing. You could create a lit action that checks the price of a token you're staking, drops below a certain price, unsteak the token, and sell it. This works across chains and could run while you're asleep. You could make any sort of complicated automated trading bot without needing to have a hot wallet sitting on a server somewhere that will get hacked when you forget to update your Linux distribution. And here's some ideas of a lot of different things that you can build. I won't read them all, but you can check them out. We could talk about some of these ideas, I think, which is worth pointing to, but maybe just a few more metaphors. One of the ways that I really like thinking about this programmable key pair notion, what we've been calling a PKP, in a way, the centralized equivalent is thinking about this like an Amazon Lambda function plus the Amazon KMS. But in this case, the KMS isn't something that's centralized. It's distributed across this threshold cryptography-based network, and these lit actions are the equivalent of the Lambda functions. And so it's this distributed system for doing the same type of operations that you would build with a Lambda function and Amazon's KMS. But in this case, you, as the application developer, when you come and bring customers on board, you have this kind of distributed backend where you can't get access to the keys, where if you build a DeFi automation bot and start selling that somebody has a subscription today, you could jump into Amazon's KMS and grab the keys and the funds out at any point. A couple other interesting things that I think are really fun to think about when we start to think about the notion of kind of this cloud key. There's a lot of implications for this as a DAO's key. So we could talk about DAOs and DeFi and use our own social media. But in the context of a DAO, the current state of the art for DAOs is, of course, to use smart contract wallets to manage the treasury. But more and more, especially protocol DAOs, we're seeing things that want to extend cross-chain and cross ecosystem. And so to start to think about the account abstraction, not at the level of the blockchain, but at the level of the signing algorithm and creating the rules and the governance at the level of the signing algorithm starts to get really interesting because you can have the same rules around governance, issuing verifiable credentials for your DAO, making transactions on ETH, doing rights to ceramic all from the same underlying curve. And then, yeah, I think another one that's kind of really interesting here is thinking about this in the context of mainstream adoption. We touched on this a little, but there's always capacities to add different levels of authorization and security to wallets. But we've been really, really excited about groups that have started to integrate this with the likes of Discord and Apple Passkey. And there's definitely a lot of opportunity to build really sophisticated tooling in this ecosystem. It's one of the reasons that we're really excited to give this talk. We have a core team that's super focused on this threshold cryptography component, but there's all kinds of opportunities to stick an email server inside of an enclave and use that as a methodology for authorizing this with email. That's something that we're not going to build internally. And so if this kind of tooling and privacy tooling and mainstream adoption tooling is something that you're interested in, definitely come talk to us. But yeah, maybe we'll keep this slide up and we'll take questions for the next 10 minutes if there are any. Thanks so much. How do we establish the trust relationship between the clients and the nodes? Because anyone kind of like snooping on that can essentially rebuild the signing or the Christian key. Yeah, I mean right now you pass a cryptographic signature with your request to the lit nodes. So that could be a signed wallet message. Like if you want to prove something about your wallet, it could be any other cryptographic signature. So it could be, you know, you need some encryption, right? Because like you need to keep this. You don't need encryption. Just a signature. And the nodes verify the signature and by verifying the signature they can prove that you own that wallet. Yes, but they're going to send you in exchange like a key share, right? Yeah, they don't actually send a key share. They send a decryption share or a signature share. So the key shares themselves never leave the node. Got it. Okay. I think that like I misunderstood this part. And so the second question that I have is essentially like can you do in any form of resizing of, you know, this, I wouldn't call it like a quorum, but like, you know, just this, this set. Oh, like changing the set of nodes and changing the threshold for example. Yeah, absolutely. Yeah. So we use a technology called proactive secret sharing. And what that lets us do is it lets the nodes, like new nodes join and leave the network and keep the underlying secret the same, but the private key shares are incompatible between like epochs when nodes leave and when nodes join. Basically this process of proactive secret sharing is quite similar to the distributed key generation process. And, you know, the secret is very, very simply put, right? A line on a graph. In this key refresh process, you're signing new points along the same underlying secret, such that the shares in epoch two are incompatible with epoch one, but they still represent the same underlying secret. And that's functionally the goal of this network is to persist a shared cryptographic secret in perpetuity. Okay, I think that ties into my third question, which is how do you ensure kind of like any form of like non-so-like counters so that, you know, essentially like the number of time that this thing has been signed or like decrypted. Maybe you want to like ensure it that like, you know, you can decrypt it x amount of times. You don't want to, you know, you may want to like sequence essentially, especially for vaults, like operations, right? Like the signing of like specific nonces or like just ensuring that like you don't have essentially just like resigning operations with different nonces either. I'm a true curious. How do you think about that? Yeah. So what you could do, so the lit nodes themselves are mostly stateless. So they don't necessarily have a place to store anything like that. But what you can do in the lit actions is you can read and write from blockchains or from IPFS or wherever. So you could like at the end of a lit action after you create the signature share, write to a chain to record that a transaction has already happened. And then if somebody tries to run that lit action again it could, you know, check and see like, you know, did this transaction already happen or not? And if so, it wouldn't sign. And that's like how it works within the lit system. Within like, you know, the if you're signing a Ethereum transaction, for example, right? You would just include the nonce in the thing to be signed. When you send up like whatever you want to the lit action to be signed. And so then you couldn't reuse that signature, right? Because it has already been broadcast with that nonce. Maybe I missed how you explained how to create a PKP without any keys, but how does that work? And how does the user not have a key and how do they authenticate what things they want the network to do? Yeah. I mean, they need some kind of key. It could be an Ethereum wallet or it could be like Apple Passkey, which is like one click and they generate a public-private key pair for you that's backed up to your iCloud in an encrypted way. It could also be like potentially a Web 2 auth method like Discord login anything like that. It just needs to be basically an authentication method that can be verified by the lit nodes. Every time someone creates a PKP, do you generate a new threshold key? And where is that key stored? Are you spinning up new cloud nodes to store those keys? So the lit nodes, each node stores multiple key shares. So there's a million keys on the network and a hundred nodes. Each of the nodes would store a million key shares, representing one share from each of the underlying cloud wallets or cloud keys. And what kinds of thresholds are you guys using in production, in test? Like the number threshold? Yeah. We're using two thirds right now and that's hard-coded across the network so it's not user-changeable. Yeah. We're using ECDSA, non-interactive signing on the signing side and then on the encryption and decryption side we're using BLS keys. We have some more questions in the middle area. Do you mind if I have one more question? That's a fourth one, right? What are your plans for decentralization and how do you plan to grow this network? It sounds like it's a pretty fixed set and you do no rotations. There's this notion of the proactive secret sharing which is not quite a rotation because it's the same underlying secret but some of our cutting edge work is right at the notion of changing the threshold which makes the network become more dynamic over time but currently there is the capacity for new nodes to join the network and for the key to be refreshed creating those new shares in epoch 2, 3, 4 and so on and then practically in terms of the plan by the end of the year this network will be up with a handful of named node operators and then those node operators are functionally a dow of sorts that decide who comes in and who comes out to the system. Thanks everybody.