Research Summary: I Told You Tomorrow: Practical Time-Locked Secrets using Smart Contracts


  • The Time-Lock (TL) implementation within a smart contract is achieved by distributing a secret to multiple parties, punishing them for revealing their share before disclosure time, and rewarding them for acting in accordance with the commitment.
  • I Told You Tomorrow (ITYT) is an innovative approach as it does not rely on trusting individuals, and can be executed cost-effectively with respect to time, memory, and gas.


  • Enrico Bacis, Dario Facchinetti, Marco Guarnieri, Marco Rosa, Matthew Rossi, and Stefano Paraboschi. 2021. I Told You Tomorrow: Practical Time-Locked Secrets using Smart Contracts. In The 16th International Conference on Availability, Reliability and Security (ARES 2021). Association for Computing Machinery, New York, NY, USA, Article 17, 1–10. DOI:


Core Research Question

  • What are the practical steps toward creating a decentralized time-lock service?


  • A Time-Lock (TL) is a way to hold a secret and reveal it after a certain point in time. Real-world scenarios include voting for elections, or sealing an inheritance in a will. Without smart contracts, they are achieved by entrusting a third party, such as a notary public.
  • The Bitcoin Lightning network, for example, runs on the basis of Hash Time-Locked Contracts in order to facilitate use cases such as micro payments in Bitcoin.
  • There have been multiple approaches to the creation of payment channels on Ethereum using decentralized Hash Time-Locked services, such as the Raiden Network.
  • Early approaches for the creation of a decentralized TL have tried to estimate the computing power needed to solve a cryptographically-hard problem, but time estimation of future computing power is often not reliable.
  • Secure Multi-Party Computation (sMPC) is a cryptographic protocol for jointly computing a function while keeping them private.
  • Threshold Cryptography is a field in cryptography that distributes a secret between multiple users, and allows reconstruction only when multiple pieces are combined.



The I Told You Tomorrow protocol (ITYT) is a decentralized TL that leverages threshold cryptography, secure Multi-Party Computation framework (sMPC), smart contracts, and the economic hypothesis on rational adversaries.

A rational adversary is a player in game theory, characterized by their rationality: they seek to maximize their interests, and will not hurt others if there is nothing to gain, which would be emotional and irrational. This is the bedrock for game theory analysis and thus this protocol.

ITYT is built on a smart contract, which ensures execution without centralized middlemen. Threshold cryptography and sMPC are technologies that simulate player actions in the game.

The Game Setting

In the protocol setting are three players: the Owner, Shareholder, and Whistleblower.

  • The Owner is responsible for launching the protocol and specifying parameters, such as the number of other participants (n), payoffs of each action, and the condition in which the secret is retrieved. The protocol will split the secret into n pieces, and only at least k shares could retrieve the secret.

  • Shareholders are responsible for keeping a piece of information secret until a given point in time. Otherwise they are punished.

  • Whistleblowers are responsible for reporting shareholders that leaked secrets before final disclosure time. Should at least k shares uncover the secret together, Whistleblowers will also whistleblow the secret, marking the protocol as failed, and depriving all Shareholders of the final reward.

Design of Payoffs

To make sure there are no loopholes for profiting without following the desired route, the authors discuss possible alternatives participants may consider, and how to set the pay-off so that they are discouraged to do so.

These are protocol parameters that would be helpful for the discussion. (3.1 Definitions, page 3)

Misbehaviors from single users

  • To ensure that the people will join as Shareholders, the cost of participating B_H must be smaller than the expected reward R_H
  • The reward of whistleblowing a share W_h must be lower than the cost of participating B_H. Otherwise, the Whistleblower could falsely report a share, collect the reward, and split it with the reported Shareholder
  • Participants should be incentivized to report an early disclosure of the secret. Therefore, the payoff for reporting when the secret is revealed before time W_S should be larger than the Shareholder reward R_H
  • Since the Owner is also a participant, we should also make sure that the owner’s fee F_O does not exceed the reward of whistleblowing the whole secret W_S

Reconstruction of the secret

  • k shareholders may want to cooperate to reconstruct the secret, profit on that (at the pay-off of V, and whistleblow the leaked secret to collect the reward for whistleblowing W_S. To avoid this outcome, we need to ensure the payoff for keeping the secret and revealing only after disclosure time is a better option:

    • k \cdot B_H > V + W_S
  • The opposite strategy should also be prevented. n-k+1 shareholders might cooperate and not release the secret.

    • (n-k+1) \cdot R_H > V

Abuse of the share whistleblowing

  • A coalition M could submit shares, then whistleblow the secret, and profit from other participants who might also happen to submit their shares. Note: W_{er} is the profit from whistleblowing shares of other participants.

    • k \cdot B_H > V + W_S + W_{er}
  • However, another coalition M' may also want to profit in the same way, except that they would like to take advantage of the fact that someone else has already revealed shares.

    • Coalition M does not want this to happen, so they need to restrict the number of shares they disclose. j_a^o is the optimal number of shares to whistleblow so that M' does not end up having a positive payoff.

    • j^{0}_{a} = \max_{i} \left\{ i|(k - i) \cdot B_{\mathcal{H}} > V + W_{\mathcal{S}}, \ i \in 1,..., k - 1 \right\}

    • j_b^o will be the optimal number of shares to recover if there is no other coalition than M capable of recovering the secret.

    • j^{0}_{b} = max \left\{ 2k-n-1; j^{0}_{a} \right\}

Rewards and bonuses

  • The fee paid by the owner has to cover the rewards

    • Which is in the case of success:

    • F_O \geq n \cdot (R_H - B_H)

    • And in the case of failure:

    • F_o +n \cdot B_H \geq (k-1)*W_h + W_S

Smart contract implementation

A finite-state machine is used to represent the different states of the protocol:

  • setup: Owner deploys the contract for the Shareholders to subscribe
  • share generation: splitting the secret and getting ready for activation
  • activation: Owner finalizes contract, Shareholders confirm, and the economic penalties become consequential if the misbehavior happens
  • lock: Shareholders keep their secrets, and Whistleblowers do their duty
  • termination: the secret is finally disclosed, the TL either fails or succeeds

It is worth noting that share generation is implemented by the sMPC mentioned in the first section.


Game theory derivation: To ensure the incentives are going to properly work, the authors set up rules to properly incentivize players, including negative incentives and positive incentives, and base everything on game theory.

Experiment: A test that includes the deployment and testing of smart contracts and the simulation of sMPC network protocols is carried out. The former is to estimate the execution cost of each ITYT instance measured in gas. The latter is for execution time and memory consumption.


Gas cost: measuring the amount of computational effort for running on the Ethereum network. The table below shows the gas amount corresponding to the executed function in ITYT.

Memory and Time consumption: The authors discovered that as the number of participants rises, so does significant sMPC latency. To address this problem, they sought to implement a two-phase sMPC, which separates and bulk executes the share generation phase of several participants together. The results are visible in the figure below.

Discussion and Key Takeaways

The authors include a discussion section to show how ITYT prevents unwanted loopholes.

Misbehavior detection

A joint effort among Shareholders is possible to bypass the protocol and recover the secret before disclosure time by recovering the secret without releasing any share nor the key, thus preventing the Whistleblower from whistleblowing.

This can be prevented by either using an encryption scheme that is vulnerable to the Known Plaintext Attack, or incompatible with the sMPC setting

DOS and deadlock prevention

This is caused by multiple ITYT users that refuse to deposit their bids, commit, or correctly execute the sMPC protocol

This can be prevented by introducing a reputation system. Research has shown that adding an additional step in the FSM setup phase of asking all participants to deposit a small service pawn that returns only at activation time can accurately filter misbehaving users.

Implications and Follow-ups

The authors dedicate a section to discussing related work that uses cryptography to achieve TL, pointing out each of their shortcomings. To name a few:

  • One type of TL entrusted individuals with a private decryption key to release a secret in the future. This is breakable once users misbehave.
  • As mentioned before, time-lock puzzles are not practical because they depend on estimations of future computing power.
  • Early attempts to use smart contracts did not introduce security deposits, nor did they consider misbehavior from collective users
  • Witness encryption was also used to create TLs, but relies on the availability of a witness encryption scheme


The improvements proposed in this paper open the door to applying smart contract TLs with more versatility and fewer limitations, providing a way to seal confidential messages in a trustless manner.


Thanks for the summary! The trustless and distributive time-lock in this paper seems promising. There is a lot to be explored here when it comes to implementation!

I did have a few questions that hopefully we can discuss here. First, it seems like this is a potential solution to “future proof” time-locks. @Larry_Bates summarized research on the potential quantum computing threat to Bitcoin a few months back. The big takeaway from that project to me was that some of the forward-looking security concerns were not as specific as they needed to be nor as worrying. This article isn’t talking about quantum computer, but it did mention the difficulty in estimating future computer power. That left me thinking:

  • How big of a concern are these estimates of future computer power to current time-lock protocols?
  • How well does the ITYT protocol solve this problem?

It also seems like the major advantage here is the distributed and decentralized nature of the protocol. From my understanding here, that is enabled by Threshold Cryptography. Are there some good sources to look into regarding this? Or maybe someone could provide an overview? I know that @Sami_B has been working on literature related to decentralization, so it might be great to have his contributions here also.


Just to add to this conversation:

One of the reasons time-locked smart contracts may be more viable is because “time-warp attacks” had been prevalent early on when blockchain networks were small and easily 51%'ed. As the time-warp attack problem was less likely to occur in a large network, the newer and smaller networks that started to grow took the time-warp attack as a serious threat. The inevitable result would be a time-based locking system that effectively becomes the solution to the time-warp attack.

While the time-warp attack is not as much of a threat to larger networks, a Time-Lock will still prove useful as a means of securing information in smaller networks and eventually larger networks alike.


It’s true that the ITYT protocol is approaching this problem from a different angle. With this direction, the effectiveness of computing power estimation isn’t a remote concern.

As for threshold cryptography, a deep understanding of that field isn’t necessary for reading this paper. ITYT is using it as a practical solution, and the paper maintains its focus on mechanism design.

1 Like

Thanks for joining the conversation by briefing us with a little history of preventing attacks.

To go a little further on the topic you’ve started, I would start by saying that time-locks can still be useful scaling solutions. The Bitcoin lightning network, briefly mentioned in the paper, is a great example.

As we all know, transactions are costly and particularly undesirable if they happen in small quantities frequently. A possible approach to this problem comes from creating a micro-payment channel and finding a more efficient way of settling small payments.

To keep it short, a timelock makes sure that both parties have an agreement before broadcasting a state or settling the balance.

It is the trustless custody that runs with a similar logic behind the ITYT protocol.


I went through the paper, quite an innovative move.
Thanks for the summary.

I’ll have to point out some things.

While cryptographic systems which is the foundational implementation of IIYT provide a secured protocol for private data and information and can be applied to different applications, the project builds the level of confidentiality attained by the stakeholders on the incentives and pay-offs, instead of on the value of information secured.

@Twan points out, as written on the paper that an agreement of all parties is maintained. It is speculated that the bids from the shareholders, attack costs, and payoff might discourage the shareholders from teaming up to expose the secret.

Although, there are preventive measures to prevent bypassing the protocol through sMPC, building the system on the rationality and ‘assumed behaviors’ of shareholders might open subsequent rooms for maneuvering the system in a manner which the whistleblower might not be able to detect. This is feasible, especially if the shareholders figure out that the private data at stake is worth the attack.


Thanks @Twan for this summary! I echo @Nachy in their sentiment of quite an innovative move.

My biggest interest here is why someone would use the ITYT protocol. I’m not sold on the removal of a single-party notary, as the paper mentions, as the primary use case for this. Nor does the assumption of a notary as a single-point of failure hold. Notaries are typically incentivized to uphold agreements by the state (and in the US, by the legal consequences) and nor do they have anything to gain in cases where they’ve notarized private data (unless they also hold an additional role in the private data. I.e., executor of a will & estate or a relative, but those cases have to be far and few and most likely unreported with low impact and consequences to the public). Notaries are also valuable because of “physical presence” which cannot be replicated with a remote smart contract that may not be able to verify the true identity (government-defined) of the individuals involved. See national notary standards linked here for context.

As well, notaries have a condition called ‘disqualifying interest’, where they cannot be family members or such relative of the signer. ITYT did not classify who the shareholders cannot be. I think the disqualification here that identity is not important to private information is actually a mischaracterization of the private data or Secret itself.

With that, and looking for use cases in data management systems, I’m not clearly seeing the use cases beyond current use of time-locks in concurrency control of multi-user systems. Is there a use case where private data or algorithms for deployment would need to be secured by a seemingly random or at least reputational group of people?


Thanks for the summary @Twan!

Based on this article and others cited, it seems like the future computing power matters significantly to time-locked puzzles that are locked with cryptography. Because cryptography is both expensive, and computing power changes and updates significantly over time that it would be difficult to estimate how much computing power it would take to be able to unlock these times.

But I’m curious now about time-locking mechanisms that do not use cryptography. The citations of this piece have all sorts of nuggets that I’ll be diving into.

There is a protocol, the Threshold Network, that could effectively deploy time-lock smart contracts, which I can see having a use case for trusts, wills, equity agreements.


Interesting summary @Twan. I don’t have much experience on the topic but I have some questions and ideas that might be relevant.

Firstly, as @valeriespina pointed out more in depth, I am not sure that the uses of this tech are fully discovered as the notary example doesn’t hold water as you need verified physical input (ie: the owner died) that can’t be sorted trough smart contracts or random shareholders spread around the globe.
I am thinking that this tech might be used in things bounded by time ONLY, for example, depending on the volume purchased/sold of a public stock, the new owner has to make public the purchase but sometimes the purchase is done outside working hours, Friday night, and will have to be done public first hour Monday. Meanwhile, the info has to stay secret in order to avoid stirring the market and creating too much volatility.
Other uses:
1.In betting events where the outcome of the event is provided at a later stage. Similar thing is already going on now in web2 where some events like dog racing, lottery picking and other similar events are filmed in advance and knowing the result in advance might give unfair edge against the house.
2. Content publishing where you want the article out at a specific time while keeping it private meanwhile.
3. Commercial uses like gender reveal or other similar events.

I think this is a wrong assumption when you talk about potentially valuable secrets being the main subject of this service.

I also have 2 things to say about this:

  1. I don’t believe is fair to punish all shareholders for misbehaving K random shareholders. Minimum good faith response might be to refund their BH
  2. I think a possible checker might be needed where the whistleblower can check and confirm that the secret was leaked without spreading the information even more. Like, for the use of the service to release financial information of a purchase, one inside trader is bad, but having all shareholders potentially doing it is even worse.

Lastly, I saw no much focus on picking the shareholders where I think is the easiest to ensure lowest chance of misplay. I think that some mechanics can be used to avoid collaboration of K shareholders:

  1. Release multiple similar deals at the same time so a Shareholder won’t have a way of knowing if he is in the same pool with his partners.
  2. Randomly selecting Shareholders that can participate in each cycle. You can employ some useful methods like pre bid as mentioned in Summary in order to ensure a larger pool of Shareholders willing to join in the cycle.

I hope this is helpful and I am looking forward to the advancements on this subject as I personally didn’t even think of this capability before finding this Summary.

1 Like

Has anyone thought about the timelock implementation in context of the Ethereum merge when epochs become somewhat fixed as compared with variable block-timings now (ie will it still work for short secrets on order of minutes)? Also on EVM compatible chains which have fast finalisation times (eg DAGs) will there be security vulnerabilities in timing attacks near the end?

Looks like a promising game mechanic where say in a MMORPG you have randomised locations of loot and you split up the trigger-points amongst different “maps” but you don’t want cheating via off-channel sharing. With dynamic forced mad rush at end when the boss reveal shows the actual loot.

I am new to this ITYT concept, however, I think I understand the concept and I may have the user case; In the last 15 years I had a professional career in the business side of Software Development, and in 2021 I had reached a burnt out point that I simply quit my high end paying role for a US Agency at a State Level. Similarly, leveraging the public office of a notary public, and my professional career in software development has provided even greater insight.
Also in 2021 the US Federal & State adopted the ESIGN, UNA, and Remote Online Notarization Laws, this change was my perfect opportunity to founding my legal SaaS startup in the niche of eNotarizations, a more succinct term.
So I am making assumptions, how I interpret the logic here is that a smart contract can deploy built-in logic when certain timely bound key data elements are met, and only then the related outcome can be deployed correctly. Could this logic be used in any way? or are there any limitations that I am not aware of? Because our startup is a platform for eNotaries to perform their duties, our appraoch is quite extensive and determined by the individual and specific predetermined 3rd party parameters, so the assistance of such control + the assistance of an Ai + potentially the Ethereum blockchain could further streamline our procedure but only if certain legally binding aspects are met in Ethereum so I am currently researching the matter and how I found this conversation. Could anyone please provide me with feedback on my interpretation?

smart contract can deploy built-in logic when certain timely bound key data elements are met,

Thats the dataflow model of bitcoin, Ethereum is a universal turning machine which has its own problems. Algorand uses decideable langauge as has got less flaws.

The expressiveness of a language to function on the virtual machine depends a great deal on the theoretical basis. eNotories are basically a 3rd party witness certification. Ethereum per se at Layer 1+2 (layer zero mining) has very little legal presence, you have to look to EIPs … there was one which described jurisdiction, authority but I believe its still unpublished. If the smart contract conforms to that standard, then a court may presume whoever is running that smart contract has aceded to that choice of law, and forum otherwise you’d get a big international fight over which law.

Basically what a technical implementation and a court interpretation can differ and where there’s discrepencies, thats the loophole. Whole business models work on regulatory arbitrage. Classic being satellite TV where feed signals via cable to adjacent country to undercut monopoly (who obviously sued).

I suggest you start looking at EIP technical standards and start mapping them to specific legal use-cases (LHS) rather than start with legal precedence at layer 4 to move down.

1 Like

Actively, I am reviewing the EIP 712 technical notes of only the instances regarding data hashing, signatures, authentication, and similar.

Similarly, It is also, broken down by withdrawn, stagnant, draft, review, last call, and final, should I review just the final version? what is your take?

Subsequently, your response indicates of other EIP that have different functionality but different purposes, a) where can I locate the other documents, and b) what common denominator do they all share so that I can identify the lot? e.g. data having, signature verification, etc

Consequently, how would I approach a request for the unpublished EIP to review? pretend that I qualify, what path or with who would I discuss and request this document?

Lastly, the diagram you are showing is it a use case or sequence diagram, would this be the most beneficial to accomplish such a tedious endeavor? or do you reckon that a functional decomposition diagram would get the job done faster and cleaner?

Finally, while I will contribute the final review I don’t think that this conversation should continue here please respond to me via direct message and I will start a research instance once I have more of my ducks in a row by the end of today. thank you.