Ecosystem

Building DeFi Apps with Lit Protocol and Sei Network

Learn how to build new DeFi primitives with Lit Protocol and the Sei Network.

alt

05 Jan 2023 • 8 min read

Introduction

Lit Protocol is a decentralized cryptography network that can be used to facilitate complex, rule-based automations for web3 applications using what we refer to as programmatic signing. A generalizable, blockchain-agnostic middleware layer, Lit can be harnessed by developers working across various ecosystems and on varying use cases.

We are thrilled to announce our partnership with Sei as we work together to build out the future of decentralized finance. Sei is a layer-one blockchain built using the Cosmos SDK. Sei is the first sector-specific Layer 1 blockchain specialized for trading. Every aspect of the blockchain has been optimized to help exchanges run better and offer the best UX for their end users.

This article will explore some of the most exciting use cases at the intersection of Sei and Lit, providing an overview of the ways our technologies can be harnessed together!

Overview of Lit

On a fundamental level, Lit is an attempt to decentralize public key cryptography. First introduced by three researchers at Stanford University in the 1970s, public key cryptography is the technology that underpins cryptocurrency and most of the security infrastructure on the Internet today.

Public key cryptography allows you to do two main things:

Encrypt information so that it can only be accessed by authorized parties.
Sign (write) data to blockchains, databases, storage networks, and other state machines using digital signatures.

As a protocol, Lit can be harnessed to build applications that leverage public key cryptography at their core and power the two main buckets of functionality introduced above. You can read more about what Lit is here.

For the sake of this article, we will be focusing on the second bucket, exploring how Lit’s programmatic signing capabilities can be used to spark enhanced functionality in the space of DeFi.

Programmatic signing: an intro to PKPs and Lit Actions

Smart contracts are powerful but generally isolated to the blockchain ecosystem on which they reside. Things like oracles and bridges help but must be set up on a case-by-case basis.

What if a smart contract could have it's own public and private keypair, just like any other wallet? And what if that smart contract had the ability to make arbitrary HTTP requests and use the data in its computation? Imagine smart contracts that can read and write from any HTTP endpoint, blockchain, state machine, or decentralized storage system.

We're building this at Lit: The smart contracts are Lit Actions and the key pairs they can use are PKPs.

Programmable Key Pairs (PKPs)

PKPs are public/private key pairs generated by the Lit network in a process called Distributed Key Generation. Each node custodies a share of the underlying private key, meaning the key never exists in its entirety.

Lit Actions

Lit Actions are our version of smart contracts, native to Lit Protocol. Actions are immutable JavaScript functions stored on IPFS that can utilize the threshold cryptography that powers Lit. They can also make external HTTP requests and interact with most EVM-compatible blockchains.

Lit Actions can be used for signing and decryption and work directly with Programmable Key Pairs (PKPs). You can write some JS code, upload it to IPFS, and ask the Lit Nodes to execute that code and return the result.

The Lit Nodes can sign or decrypt some data for you using their private key share. These signature or decryption shares can be collected and combined on the client side to get the full signature or decryption key.

Sei Network: the first L1 specialized for trading

Sei is the first layer-one blockchain optimized for traders. Built atop the Cosmos SDK, Sei’s goal is to help exchanges run better and offer the best UX for their end users. They have worked to pioneer several innovations in an effort to maintain the cutting edge, including:

Native order matching engine - drives scalability of orderbook DEXs built on Sei
Breaking Tendermint - Sei is the fastest chain to finality at ~600ms
Twin-turbo consensus - improves latency and throughput
Frontrunning protection - combats malicious frontrunning that is rampant in other ecosystems
Market-based parallelization - specialized parallelization for DeFi

The combination of these optimizations make it possible for new types of financial products to emerge, everything from live sports betting to complex options and futures.

Most Layer 1's fall into two extremes - with general purpose chains on one end (Solana, Ethereum) and app-specific chains on the other (dYdX, Osmosis). Sei unlocks an entirely new design space between the two—not general-purpose nor app-specific, but sector-specific, which enables Sei to create an environment custom-built for DEX applications.

By exploring the new design space in between app-chains and general purpose Layer 1's, Sei has carefully selected for a unique set of tradeoffs that make its Layer 1 the optimal environment to scale with the needs of decentralized exchanges.

Ways to use Lit and Sei together

As mentioned above, Lit is completely blockchain-agnostic and inherently interoperable with most EVM chains, Bitcoin, and the Cosmos ecosystem. This opens up an exciting design space to utilize these two protocol’s together.

Let’s start by diving into some of the use cases we are most excited about, before jumping in to some potential ways these solutions may be implemented.

On-chain limit orders

PKPs and Lit Actions can be used to facilitate condition-based orders for DEX applications built within the Sei ecosystem. These may take the form of simple limit orders, enabling the automation of buys and sells based on specific price parameters (i.e “sell my ATOM when the price hits $10 USD”), or more complex orders that utilize off-chain data (such as pulling in an off-chain price feed or making a call to any other external API).

Because Lit Actions possess the inherent capability to communicate with off-chain data sources, these sort of use cases can be implemented without the use of any sort of Oracle system.

Automated compounding of staking rewards

When it comes to staking your tokens — whether depositing into a DeFi protocol, locking up as a security deposit, or delegating to another Validator — there exists no easy way to automatically claim or redistribute rewards to other avenues. For example, say you wanted a percentage of your rewards to be compounded and redeposited every month, or you wanted them to be re-delegated to another validator, or even sent across chain to an external account for use in another ecosystem.

Using Lit Actions and PKPs in conjunction with the Cosmos authz module, we can start to define specific automations surrounding staked assets whereby a Cosmos user on the Sei Network can grant arbitrary permissions to a PKP to spend their assets on their behalf. We will dive further into what this potential architecture could look like in the sections ahead.

Recurring payments

One of the biggest hassles in using blockchains and dApps is the requirement to sign every time. Whether its making a swap on a DEX, sending a friend some crypto, staking some tokens, or the like, a wallet signature is always a prerequisite, requiring that the user be “online”. For recurring payments (such as a subscription or payment to an employee) this requirement creates an unnecessary hassle and poor UX.

Once again, we can define specific automations surrounding recurring payments for apps built atop the Sei Network using PKPs and Lit Actions. A potential example would be dollar-cost averaging, where a user could make recurring investments based on a preset time-scale or cost threshold.

Decentralized custody solutions

Another potential way to utilize Lit PKPs is as a decentralized custody solution. As each PKP is a valid ECDSA wallet, you could send a mix of assets to it and specify certain conditions for spending, sending, staking and more, kind of like a smart contract wallet.

The first key difference (no pun intended) here is where the private key is stored. Lit leverages the power of threshold cryptography to distribute each key pair across our network of nodes, meaning the key is never stored in its entirety. Instead, each node only holds a key share, and these shares must be combined above a threshold to form the complete signature for signing or decryption.

This threshold is set to two-thirds, so if there are 100 nodes in the Lit network, then you would need to request decryption or signature shares from at least 67 of them. Because of this, a single private key share is useless on its own, and the ownership of the private key itself is decentralized across the nodes.

The second key difference has to do with how one actually interacts with this key pair. Using a wallet like MetaMask requires a certain level of industry expertise: complex seed phrases, private keys, long addresses, a discrepancy between connected network, etc. The current onboarding experience is far from seamless for a non-crypto native user!

We have set out to change this, enabling individuals to use more “familiar” auth methods — such as Discord, Google OAuth, or WebAuthn — to generate their wallet and take ahold of their decentralized assets!

We look forward to exploring how PKPs may be utilized as a custody solution for Sei and other projects building within their ecosystem in the near future.

How to implement: using the Cosmos authz module

The Cosmos authz module allows you to delegate permission(s) to other accounts to execute actions on your behalf. The basic authorization type is a "generic" authorization, which is one that takes a message type as a parameter and allows the grantee unlimited authorization to execute that message on behalf of the granter. Other authorization types include "send", "delegate", "unbond", and "redelegate" in which case a limit on the number of tokens can be set by the granter. If no limit is set, the grantee can vote as many times as they want until the granter revokes the authorization.

Seeing as the Sei Network has been built using the Cosmos SDK, we can use the authz module to facilitate interactions between Cosmos accounts and Lit PKPs, whereby a user can delegate certain permissions to a PKP to spend assets on their behalf. A possible user flow looks like:

1️⃣

A user starts by sending an authz message, granting arbitrary privileges from their account (the granter) to a PKP (the grantee).

2️⃣

The grant object encapsulates an Authorization type and an expiration timestamp, outlining the actions that a grantee has permission to make on behalf of the granter.

3️⃣

After specific permissions have been granted (such as "grantee can only spend < 50% of portfolio"), the PKP will be able to execute arbitrary transaction logic on behalf of users, using Lit Actions to define certain condition-based automations (for example, the logic for the limit orders discussed above).

Looking Ahead

We are looking forward to working with the folks within our shared ecosystems to flesh out some of these potential use cases and example implementations in the months ahead. If you are interested in helping us build these primitives or have an idea for a potential integration, please get in touch!

We are currently looking to fund the development of a PKP SDK for the Cosmos ecosystem, enabling the use of a PKP as a valid signer for Cosmos transactions. This integration will be key in facilitating interactions between Cosmos accounts and PKPs, and in enabling the above-mentioned functionality provided by the Cosmos authz module. If this is something you or your team would like to work on, please apply for a grant here.

Only together can we build solutions that help spark continued growth within the space of decentralized finance and web3 at large!