Binding Timelock Encryption: Only Time Will Tell

As your parents insisted when you were growing up, good things come to those who wait. It turns out recent advances in cryptography have proven them right.

When competing head-to-head, revealing your move before your opponent gives them an obvious advantage. If I know you're playing rock, I'll play paper. Whether it's rock-paper-scissors or a keyword auction for search results, competitive applications need to hide submissions until everyone has committed. That's why they typically run on centralized infrastructure where moves can be blinded until resolution.

Blockchains don't yet offer this "temporal privacy". Transactions are public the moment they hit the mempool. Look no further than the meteoric rise of MEV bots that monitor mempools, frontrun trades, and sandwich transactions to see the value of this information leakage.

What if blockchains could run fair competitions?

The Missing Primitive: Binding Timelock Encryption (BTLE)

Enter Practical Timelock Encryption (TLE). TLE lets you encrypt data that cannot be decrypted until a future moment (specifically, when validators generate a threshold signature over a known message). Once that signature exists, anyone can use it as a decryption key to reveal the encrypted data. Simply put, if you know the static public key of some threshold set and you know a message it will sign at some point, you can encrypt data that can be decrypted when a signature is generated over that message.

It turns out we already have such a signature generation mechanism in the Commonware Library: threshold-simplex's Verifiable Random Function (VRF). At each view (every ~200ms on a global network), validators produce a threshold signature over the view number (a message that can be known ahead of time by anyone looking for a timelock encryption target).

TLE, a standalone cryptographic primitive, however, lacks the ability to enforce commitments to encrypted data. Nothing in the TLE scheme prevents a user from sharing different encrypted data to different people or encrypting updated data if they change their mind. Embedded into a blockchain, TLE commitments become "Binding Timelock Encryption" (BTLE). Submit an encrypted move before the end of a contest, and you can't back out or change your mind (your move is stored in state and can't be changed). Anyone possessing the VRF output associated with the end of the contest can decrypt the committed ciphertext.

With BTLE, blockchains can finally offer temporal privacy. Good things (or fair contests onchain), as your parents said, come to those who wait (for timelock decryption).

BATTLEWARE: Proving BTLE is Practical

To demonstrate how to use Binding Timelock Encryption, we built BATTLEWARE. BATTLEWARE is an onchain game where players duel each other to climb a global leaderboard (sorted by ELO score). If you've played Pokémon, you'll feel right at home.

Figure 1: A battle between two trainers on BATTLEWARE. The opponent (DEVOTE RITUAL) has locked their move for this round but we can't see it yet.

It all starts when you submit a transaction to generate your "creature". The same signature generation mechanism used to power BTLE decryption doubles as the VRF used to randomly generate your creature's appearance, name, and moves.

Figure 2: A creature's traits are derived from the hash of your address, nonce, and a seed by the embedded VRF. The output of a VRF is only known after a block has been notarized (or nullified), so a player can't compute the outcome of the generation prior to their transaction's inclusion in a canonical block (under healthy network conditions).

With a creature generated, you can enter the arena for matchmaking. Again using the same VRF, we randomly pair you with some other player (making it a bit more difficult to play yourself to boost your ELO).

Figure 3: Players submit match requests onchain and after a configurable amount of time has passed or the arena is full, players are paired and battles started.

Once in a battle, you have 15 rounds to defeat your opponent. During each round, both players submit moves encrypted to the view at which the current round will resolve (50 views after matching or the end of the previous round). Once that view is reached, either player can submit the VRF output to decrypt both players' moves and resolve the round. If a player has won, the battle resolves and each player's ELO score is updated. If not, the battle continues to the next round.

Figure 4: Any player can submit a settle transaction with the VRF output from the end of the round.

To make decryption performant enough for BATTLEWARE, we perform parallel decryption of moves during execution using a BATTLEWARE-specific execution environment.

The entire implementation is open source under both an MIT and Apache-2 license. The code is still a bit rough around the edges, but we were able to reach 77% test coverage (on ~11.2k lines of code). Consider it your opportunity to become a contributor.

Securing Player Access

Instead of trusting our API to provide access to game state, we opted to build a pipeline to provide visitors with authenticated access (like we did with alto). The big difference here being that BATTLEWARE players need to verify state and events against consensus outputs (rather than just consensus outputs directly).

To accomplish this, we inject state changes and execution events into our ADBs. We then use consensus::aggregation to generate a threshold signature over the computed roots of each ADB. Because execution relies on the output of a VRF not available during verification, we cannot just use the threshold signature emitted by threshold-simplex (unfortunately).

Figure 5: After execution, the State ADB and Events ADB is updated and once wrapped by a threshold signature are pushed to Exoware.

Once a threshold signature is generated, validators then push these computed artifacts to Exoware. On-the-fly, Exoware generates Multi-Proofs over the events that each websocket subscriber is interested in to save bandwidth (the events for your account or the battle you're in).

Figure 6: Instead of sending a full proof and all events for each block, Exoware dynamically generates Multi-Proofs over only the events that matter to the subscriber.

These updates are processed by your browser where you both verify the threshold signature attesting to some set of roots was valid and that there exists a valid proof of your events in the provided root.

Wrapping Things Up

At Commonware, we believe that the best onchain experiences will develop a sustained edge through specialization. Whether it a game, a trading application, a social network, or something only you know how to build, building a blockchain around a product provides differentiated capability that can't be bolted on to existing blockchains.

We will (finally) have capacity to onboard our next Commonware design partner on October 1st. If you want to collaborate on a blockchain application that doesn't feel like one, reach out now (our next slot opens in 2026).