---
# System prepended metadata

title: Delorean Protocol - Onepager

---

# Delorean Protocol - Onepager

![](https://github.com/BadBoiLabs/Delorean-Protocol/blob/7f0f8b8a48f44486434bae881ba85785f6f7cf64/Delorean-Docs/assets/logo.png?raw=true =500x500)

## One Sentence

Delorean is a protocol for programmable key distribution. It lets developers write contracts to determine when keys should be released, and to whom.

## Capabilities

### Programmability

Using Delorean you can write a contract encoding your key release conditions and then encrypt data with respect to a deployed instance of that contract. The contract is responsible for calling a function to notify the validators of the chain they must perform a signing action.

The signing action can produce a public decryption key or produce a decryption key which itself is encrypted with respect to a particular users key. This allows for programmatically generating either public decryption keys or decryption keys for a particular individual.

### Encryptor Flexibility

Using threshold signing techniques data can be encrypted with respect to a user-defined m-of-n signers defined at encryption time. This allows the encrypter to chose validators they trust (similar to delegating in dPoS) and makes the encrypted data more resilient to validator churn.

### Interoperability

Delorean is an EVM chain meaning any programmed key release contracts can benefit from existing Solidity tooling and libraries.

It is a [subnet](https://docs.ipc.space/concepts/subnets) meaning it can be hosted by any existing EVM chain, use the host gas token, and trustlessly read host state. This allows any tokens, bridges, NFTs, DAOs etc on the host to be used when programming key release conditions.

## How it works

The protocol is a Tendermint/IPC EVM chain with special precompiles that allow you to pay a fee to queue up a signing action that all validators in the network must perform or be slashed.

Using this in combination with recent developments in witness encryption it can be used to generate threshold decryption keys.

Key generation comes with economic guarantees tied to the liveness of the network. Either the keys are generated or the network halts. This is thanks to the use of the `extendVote` and `validateExtendVote` functionality of ABCI. Validators cannot cast consensus votes for the finalized tip of the chain without also participating in key generation.

## Use-cases

### Users Purchase Access to Encrypted Media

Delorean provides a complete end-to-end, decentralized solution for purchasing media access keys.

A smart contract can accept payment from buyers along with their public key. Upon receipt of funds the contract can trigger the network to generate a decryption key that has been re-encrypted to that user.

The result is that the purchaser is now able to receive and decrypt an access key while the key remains hidden to other non-paying users.

### Exchange of Hidden Game Information

Certain on-chain games like Dark Forest rely on hidden information and this information can be valuable. 

Delorean enables a fully on-chain exchange or sale of such information without requiring both parties to be online or communicate directly (as in [Nightmarket](https://blog.zkga.me/nightmarket)). Encrypted information for sale should be accompanied with a ZK proof proving some facts about its contents without revealing it.

### Integrate with Existing On-chain Ecosystem

Being a subnet, Delorean is able to trustlessly receive cross-chain messages from its parent. If it chose Ethereum or Base as a parent this would allow it to access the state of any existing on-chain dApps and tokens.

An example might be using a user's [Blackbird](https://www.blackbird.xyz/) $FLY points balance on Base to selectively reveal the location of a secret party or restaurant opening to users with high reputation.

## Comparisons

### DRAND/tlock

https://drand.love/docs/timelock-encryption/

- only allows for encryption to a time in the future. No programmable conditions

### LIT Protocol

https://www.litprotocol.com/

- LIT has a fixed signer set while Delorean is open and allows entry/exits. LIT also does not support user configurable m-of-n.
- LIT has no economic guarantees
- Delorean can integrate with its host chain using a secure and trustless IPC bridge. This is unlike LIT which is a soverign chain and relies on its own cross-chain oracles.
- LIT requires validators to use a Trusted Execution Environment (TEE) to house their keys. This makes it more difficult to launch an attack assuming TEEs are secure, but limits participation.
    - Idea: Delorean could have both kinds of signers and they must submit a proof if they are using TEE. Encryptors can then select which kind they want to use.
- LIT supports more features such as programmable transactions. Delorean focuses only on key management
- Delorean will be open source and developed in the open. LIT node source code is not available

## Where It's At

- We have a PoC we can demo. [See video](https://www.youtube.com/live/N-nMY6Lyvwk?si=BZhBeBzuKiSRrHMF&t=1645)
- Threshold signing not yet implemented (although Eric has a early PoC)
- Re-encryption not yet supported. Can only produce public keys