GG EZ NO RE: How Lit Can Be Used To Build Next-Gen Web3 Games

Introduction

Lit Protocol is decentralized infrastructure for web3 applications. Blockchain-agnostic decentralized key management middleware, developers can integrate Lit within their application backend to facilitate access control to private data and powerful condition-based automation.

When it comes to blockchain-based games, AKA “web3 gaming”, there are several facets where Lit’s tech stack becomes useful. For this article, we will be focusing on three:

1. Condition-based automation for on-chain games.
2. Private data for web3 games.
3. Wallet abstraction and seamless onboarding experiences for new gamers.

To learn more about Lit, check out our documentation.

Web3 Gaming

Blockchain-based games have exploded in popularity over the past several years. According to a16z’s State of Crypto ‘22, over 20% of all NFT sales in 2021 were gaming related — that’s more than $5 billion spent on in-game assets. Within that same year it was reported that nearly half of all measured crypto wallet activity was related to gaming.

Off-chain, gaming is over an $100 billion industry, suggesting that there is plenty of growth to be expected ahead. If you look at the current state of the games themselves, there still exist many shortfalls that must be addressed before we can expect any sort of adoption en masse.

Highly complex onboarding experiences have been one of the biggest barriers to entry for new users. Non-crypto natives struggle to grasp new concepts like NFTs, tokens, seed phrases, and wallets. Playing blockchain-based games today requires prerequisite knowledge on the industry as a whole — and it shouldn’t.

Lit for Gaming

At Lit, we are working on building tools that simplify the user experience across the decentralized internet. We’re developing a network that provides cryptographic solutions that empower individuals with true data sovereignty, while delivering the frictionless experience we are used to within our legacy systems. When it comes to gaming, we are interested in providing open source tooling that promotes the adoption of blockchain gaming by simplifying the user experience.

Developers can use Lit to instill unique functionality into their gaming experiences, such as introducing condition-based access control for games with private data. Lit can also be harnessed to program powerful automations and facilitate the native interoperability of in-game assets, helping foster cross-platform compatibility. Additionally, Lit’s cloud wallet infrastructure can be leveraged to provide seamless onboarding experiences for new users, allowing them to use familiar sign-on methods (such as Discord auth, Google login, or Apple Passkey) as an auth method over their crypto wallet, abstracting away many of the frictions that exist today.

Below, we will dive into some of these areas in more detail, exploring how Lit can be integrated on a more technical level.

Automation for Games

When we think of automation, we think of tasks being executed based upon pre-defined conditions and programs. Developers write some rules (in the form of code) and those rules are automatically executed when triggered. This is precisely how a smart contract works: you input some rules, and the contract gets executed (or not) based on those rules.

But smart contracts on their own aren’t a “one size fits all”. For one, they are limited to the blockchain in which they’re deployed, meaning you can’t easily incorporate data from other networks (either on-chain or off) into your computation. In order to communicate data across chain you need to use some sort of bridge, and in order to incorporate off-chain data you need to pull in some external data using an oracle.

At Lit, we’ve been working on an alternative solution: Lit Actions. Lit Actions are immutable JavaScript programs stored on IPFS. They can be thought of as our native implementation of smart contracts, only much more powerful. They are the permissionless rules that govern Lit’s signing automation.

Lit Actions are blockchain agnostic, giving them the inherent capacity to communicate data across blockchains. This enables interoperability between previously disconnected ecosystems.

They can also use off-chain data sources in their computation. Lit Actions can make arbitrary HTTP requests, for example fetching off-chain data or calling an API.

Functionally, this gives developers the ability to instill “oracle” or “bridging” capabilities into their blockchain applications with ease from a single development environment, where the signature provisioned by Lit stands as the mechanism for verifying state changes.

This can be applied to gaming in quite a few ways. First, some aspect of off-chain data will most likely be a requirement for most applications. Take a prediction market (that counts as a game right?). The data used to form and settle each market will most likely require pulling data from some external API, like an ESPN sports feed for example.

Lit’s conditional signing capabilities can be applied broadly. Developers can define some arbitrary condition (whether it exists on-chain or off) and request a signature be provisioned when they are met. This signature can be used in the context of a proof generation or certification system, or to trigger an on-chain transaction.

To learn more about automation via conditional signing, check out this example from our docs.

Additional Examples: Dynamic NPCs:

Non-playable-characters (AKA CPUs) that react to moves players make in-game and respond “accordingly”. This could be implemented using Lit Actions, where the responses are programmed based on the particular interaction that was observed. Data from both on-chain (via RPC call) and off-chain (via API) sources can be utilized as “triggers” for response.

In this context, NPCs are actually wallets (PKPs) that can buy and sell assets and interact with arbitrary smart contracts.

Private Data

Blockchains are inherently open systems, meaning all data that is transacted is public by default. Anything that occurs on-chain can be viewed by anyone with an internet connection on a public block explorer such as Etherscan.

Obviously, this lack of privacy is an issue. There are industries where it could be argued that privacy is a necessity. What if everyone had open access to your bank account balance or healthcare data?

When it comes to gaming, there are several areas where privacy becomes important. At a high level, this makes sense. Any sort of strategy game or competitive head-to-head will have some aspect of “confidentiality”. Take blackjack for example: if everyone’s hand were to be publicly available, it becomes quite easy to game the system.

Use Lit’s decentralized access control protocol, game devs can incorporate programmable privacy into their product offerings. Using Lit, you can specify certain “conditions for entry” based on on-chain data. This includes things like:

• User holds an NFT in a collection (a particular in-game asset or trait)
• User holds at least 0.1 ETH (a user’s wallet balance)
• The result of any smart contract function call (using the games “state” — via contract call — as a mechanism for access control)
• Using boolean operations (AND + OR) for any of the above (composable conditions!)

Game devs can incorporate this logic into any blockchain-based game, where specific actions and events that occur within gameplay stand as triggers for unveiling and decryption. A trivial example: the game “map” unlocking dynamically as a player explores different areas. Here the specific coordinates explored “in-game” stand as the decryption condition for the map itself.

This could be configured by making a custom call to the game’s smart contract using Lit’s evmContractConditions, which you can dive into here.

You can get started with more decentralized access control examples here. Additionally, this example of encrypting NFT metadata may be applicable.

Additional Examples: Selective Disclosure of In-Game Assets and Strategies

Lit’s access control protocol can be used to programmatically configure decryption conditions over private data. Again, the private data itself is arbitrary, based on your specific use case. Above, I mentioned the example of a dynamic map that updated as new areas were explored. Here are a few more ideas:

• Multiplayer card games where each player only has access to their own hand
• Private metadata that only an owner of an NFT has access to
• Board games where new information is “released” dynamically according to the move each player makes

Wallet Abstraction

As mentioned in the introduction, some of the biggest deterrents to the widespread adoption of blockchain technology are the high complexities in the onboarding process. The notion of a crypto wallet and a private key is confusing and mind-boggling from the outside, foreign compared to the legacy tech that we are used to. Does somebody need to understand how WiFi works to connect to the Internet? Does somebody need to understand how browser security works to use HTTPS? No, so why should users be expected to understand the nitty-gritty of these cryptographic primitives to use them?

The short answer is “they shouldn’t”. That’s what we are working on at Lit: abstracting away the complex to facilitate an onboarding experience that is frictionless and smooth, without having to trust a centralized custodian.

To that end, we have built Programmable Key Pairs: distributed ECDSA keypairs custodied collectively by the nodes that make up the Lit network. By collective custody, we mean that each node only holds a share of the complete private key*. In order to be used for signing or decryption (the two things you can “do” with public key cryptography) you must combine these shares above their threshold, which is two-thirds of nodes. So if there were 100 nodes in the Lit network, you would need to collect shares from at least 67 of them.

The catch with Lit is that only an authorized client can create and combine these shares. The authorized client is the owner of the underlying keypair, and only they can authorize the nodes to sign or decrypt some data with their key.

The part where the notion of “wallet abstraction” comes in has to do with how this key is authorized by a user. Right now, Lit supports several auth methods, including Discord, Google sign-on, owning a given PKP NFT (via wallet), SIWE, with more coming soon. This means that any of these methods can be used as the “controller” of a valid ECDSA wallet.

Imagine if you all you had to do was simply sign in with your email (or any other form of web2-style MFA) and a crypto wallet was generated for you automatically in the backend, no secret recovery phrase or additional heavy lifting required. Well, you don’t have to imagine this any longer. With Lit, this is precisely the functionality that becomes possible.

We are currently looking to fund integrations between Lit and traditional game-dev infrastructure (such as Unity) through our Grants program. Specifically, we are interested in the development of SDKs or composable “modules” that enable seamless interactions between PKPs and blockchain-based games built in Unity or related gaming engines. If you’re interested in building any of these primitives, reach out to us on Discord or apply for a grant.

Example Use Cases

Let’s dive into some more potential use cases for Lit as gaming infrastructure.

P2P Prediction Markets

One of the more interesting use cases is using Lit to develop infrastructure for P2P prediction markets. Here, the idea is using Lit as the permissionless environment for constructing custom markets.

Let’s take an example. Alice and Bob are debating who will win the upcoming student body election at their local university. Alice thinks that Student X will win, whereas Bob has put his faith in Student Y. Both individuals, being overly-confident in their selection, decide to place a wager on the winner. If Student X wins, Alice shall receive 5 tokens from Bob. If Student Y wins, Bob shall receive 5 tokens from Alice.

This type of logic could easily be configured within a smart contract, where the winner is automatically paid out based on the result. But the problem here is communicating the winner with the smart contract itself. The winner will be announced off-chain, so in order to “see” who won, some sort of data oracle will need to be setup.

Alternatively, you can use Lit Actions and PKPs! In this case, each market would revolve around its own PKP (functionally a rules-based token vault). Instead of depositing funds into a smart contract, both Alice and Bob would deposit them into the PKP. The party that sets up the vault would then associate this PKP with a Lit Action and grant it permission to sign using it. The Lit Action stands to define the particular rules that should be followed: “if X wins, pay Alice token balance. If Y wins, pay Bob”. Again, no data oracle or additional infrastructure would be necessary here, as Lit Actions themselves can make off-chain HTTP requests natively, for example a call to an external API.

But how can you guarantee that a Lit Action signed by a particular PKP can be “trusted”? How do you know that it wasn’t used to sign a bunch of other things instead? To solve this we came up with a method called “Mint-Grant-Burn” where one:

1. Mints a PKP.
2. Grants a particular Lit Action to sign using it.
3. Burns the PKP.

All in a single atomic transaction, ensuring that the PKP can never be used to sign any other than the Lit Action which it was granted permission.

Greater Portability of Cross-Chain Assets and Data

As mentioned in the introduction, Lit can best be defined as a blockchain-agnostic middleware layer. Lit uses the elliptic-curve digital signature algorithm (ECDSA) for digital signatures, the same algorithm that is utilized by Ethereum and most EVM chains, Cosmos, Bitcoin, as well as dWeb storage solutions like IPFS and Ceramic (among others). This means that Lit is inherently compatible with each of these ecosystems, and can easily be fitted to read and write data between them.

Each game may possess any number of native “assets”, whether they be an NFT or any other sort of token. Using PKPs, we can design wallet solutions with interoperability baked-in, meaning these assets can be easily transported across a wide array of supported chains with ease.

Learn More

To learn more about Lit, check out our developer documentation. Here you will find an overview of our different product offerings, detailed code demos and technical walkthroughs, and additional example implementations and use cases.

If you’re interested in contributing within the Lit community, check out our Request for Ecosystem Proposals page. Here you will find a list project ideas that we are looking to fund through our Grants program. Have another idea of what to build with Lit? Get in touch by applying for funding!

For developer support or questions, join our Discord and say hi on Twitter.

*It is also important to note that all of the node’s operations take place within a secure enclave, meaning node operators never have access to any of the underlying key material or data that is being processed.