TL;DR — Payment streams (and some channel designs) need the execution environment to know the current time. LEE does not currently expose block context to programs, so we cannot implement streams as defined today. The same limitation affects other context-dependent programs (voting, auctions, locked tokens). This post walks through how time works in blockchains, how it is exposed elsewhere, and what options LEE may consider. The goal is to open discussion and collect opinions.
Context and timestamps in LEE
A blockchain’s core purpose is to establish an order over a series of state transitions. Each state transition results from a program execution. Some programs need external information at execution time. We call such information context. Context may include the current timestamp, block height, environmental parameters, and similar values that the environment supplies at execution time.
Generally, consensus implies determinism. Yet some input values become known only at execution time. In transparent blockchains, executing entities (validators, block builders) supply context. The situation is more complex for privacy-preserving chains with shielded execution. A user, acting as a prover, runs the program and generates a proof. A node, acting as a verifier, checks the proof later. What if the verifier uses other values for some inputs? Must the proof then be considered invalid?
Logos needs off-chain payment mechanisms for efficient and private service incentivization. Payment streams are being designed for that purpose (see raw spec). In a stream, funds accrue from user to provider over time. The provider may claim at any time. The claim transaction computes the accrued amount on-chain (e.g. rate × elapsed time since last claim or stream start, capped by the remaining balance). Streams need block context—in particular, timestamp—to compute accrual.
Payment channels could be an alternative. In channels, state transitions happen off-chain via co-signed updates without relying on timestamp-based calculation. Still, channels need a time signal to enforce dispute windows in case of fraudulent channel closure. Workarounds with weaker assumptions may exist (further research is needed).
This post attempts to classify approaches to exposing on-chain context within LEE (Logos Execution Environment), motivated by payment streams implementation. Should LEE expose context to programs, such as streams? If not, what are alternative payment protocols for service incentivization? Might streams or channels still work without a system context provider, perhaps under weaker security assumptions (e.g. a trusted timestamp oracle)? Which other programs need context (e.g. voting, time-locked token allocations)? What approaches are possible for LEE, and how should we prioritize them?
In this post: Time in blockchains · How timestamps are exposed to execution · Off-chain protocols and timestamps · Context in privacy-preserving systems · The challenge in LEE and shielded execution · Options for LEE context-aware design · Summary and questions for discussion.
Time in blockchains
The term “blockchain” started as “timechain” in the Bitcoin source (the whitepaper never says “blockchain”). The design establishes agreed transaction ordering to prevent double-spends. Solving double-spend means reaching consensus on timing: which transaction came first? Syncing with physical time is sufficient but not required for ordering. A logical ordering suffices.
Proof-of-work (PoW) in Bitcoin provides a coarse, independent time signal. Nodes do not fully trust the timestamps miners put in block headers. Consensus arises from block-level logical synchronization with automatic difficulty adjustments. Note that a blockchain cannot give a finer time signal than its block interval (e.g. Bitcoin ~10 minutes). Blocks in PoW exist in part because of non-negligible global latency. If a decentralized network could maintain a common trusted timestamp at millisecond resolution, it could accept valid transactions and reject double-spends without blocks.
Proof-of-stake (PoS) chains (including Ethereum) rely on external time. The protocol defines a leader per time slot. Slots are derived from physical time, which validators must be aware of. External time signal makes equivocation (double-signing within one slot) easy to define and punish. PoS extends an initial trust assumption in a time signal into a full transaction system, rather than building a sequence counter independent of external time.
How timestamps are exposed to execution
Notes on terminology in what follows:
- “timestamp” means either a literal timestamp or block height (unless specified). Timestamp and block height are to an extent convertible. The choice matters for resolution. Streams generally need higher time resolution than channel dispute windows. Whether block height alone is enough for a stream depends on block height granularity.
- The terms “script”, “(smart) contract”, and “(on-chain) program” mean roughly the same thing in the context of their respective systems (Bitcoin, Ethereum, LEE).
Chains differ in whether and how they expose time to execution. Let us define levels of such exposure from 0 to 2.
Level 0 establishes only logical order between blocks and transactions within a block. Any chain does this by definition. For a simple transaction system we only need a robust test: did transaction A come (logically) before or after B? Validity is a chain of valid state transitions from genesis. Each transition is defined only by arithmetic (inputs = outputs + fees) and ownership signatures). In other words, UTXO validity does not depend on when its owner spends it.
Level 1 adds transaction-level timelocks. Transaction validity is defined by a script (as before) plus optional time locks on the whole transaction. Validating nodes treat the timelock as an extra validity check against the current timestamp at execution time.
Level 2 exposes context (timestamp, block height, sender, etc.) to the execution environment. In addition to level-1 transaction validation, the on-chain program can branch or calculate values depending on context (for example compute accrued funds in a stream from elapsed time).
Context in off-chain protocols
Off-chain (aka L2) protocols are a major way to scale blockchain throughput. The core idea is to move most interactions off-chain and use the chain (aka L1) only for disputes and settlement. This approach allows higher throughput without putting too much strain on nodes, so decentralization is preserved.
In the context of Logos service incentivization, we focus on off-chain payment protocols. Options include payment channels and payment streams. We refer to them simply as channels and streams in what follows.
A general observation: regardless of the “context exposure level” of the underlying blockchain, both streams and channels still need some notion of time.
A channel is a two-party protocol where a sequence of state transitions is agreed off-chain. By co-signing each state update, the parties establish an agreed-upon off-chain state order. The design goal is to convince the chain that a given valid off-chain state is the latest one.
Validity itself is checkable cryptographically (stateless), but “latest” implies time-based on-chain dispute resolution. This is the principle behind optimistic systems (e.g. Lightning and optimistic rollups): off-chain state transitions are considered valid unless disputed on-chain within a given time window.
Streams are more reliant on time context than channels. As stream funds accrue proportionally to elapsed time, parties do not co-sign state transitions. Streams lack dispute semantics, which makes the protocol simpler than channels. The trade-off is that streams require program-level exposure of timestamp for accrual calculation.
Channels, in theory, only require time context for dispute resolution. In practice, though, looking at the Lightning Network (LN) as the only widely deployed channel network, script-level timelocks are also needed. The LN uses two timelock types: script-based relative and transaction-based absolute. Absolute timelocks encode “sender can take back after T” to prevent locked-up funds if the channel partner is unresponsive. Relative timelocks enforce dispute windows. The window starts at confirmation of the closing (potentially fraudulent) transaction. Strictly speaking, channels could theoretically rely on transaction-level timelocks only (via replacing HTLC with PTLC and a transaction-level timelock), but in practice script-level timelocks are also required.
Context in privacy-preserving systems
Two classes of systems are most relevant for our discussion: privacy coins and ZK-ZK rollups.
Privacy coins (Monero, Zcash, Mimblewimble-based Grin and Beam) have no scripts (except Zcash’s transparent mode), so they do not expose timestamps to scripts. Off-chain protocols on such chains are theoretically possible but, to the best of my knowledge, none are widely deployed.
ZK-ZK rollups use ZK proofs not only for scalability but also for privacy (i.e. execution and proof generation happen user-side). That term distinguishes them from validity rollups (often called ZK-rollups), which use ZK proofs as a compact proof of state transition validity but rely on a centralized, non-private sequencer for execution and proof generation.
Notable ZK-ZK rollups include Aztec and Aleo. In Aztec, the user runs code locally on public and private inputs. Context values (including timestamp) are considered public inputs and queried from the sequencer. The verifier then accepts if context at execution time falls within the allowed range. Aleo’s block-context access is unclear (likely not exposed to programs).
Note that rollups with sequencer-based execution tie L2 context to L1 so the sequencer cannot simply forge timestamps. The L1 contract enforces consistency and extends the “L1 timestamps are correct” trust assumption to L2.
The context challenge with shielded execution
LEE aims for a unified execution model with the option to run the same (stateless) programs publicly (on-chain) or privately (off-chain, aka shielded). Off-chain execution produces a ZK proof for verification on-chain.
Combining this duality with context injection is non-trivial. In shielded execution model, both the prover (i.e. user) and the verifier (i.e. sequencer) supply inputs for proof generation and verification, respectively. The proof says: given these inputs, this program produced these outputs. If present, context must be part of the inputs. What if prover and verifier supply different context?
Programs must allow leeway in timestamp or block height for the gap between proving and verification. Consider an example. The prover submits a timestamp t_0 with inputs and generates a proof. The verifier supplies context (including execution timestamp t_1) and verifies against it. Verification fails if the timestamps disagree beyond the allowed bounds.
Leeway size is a trade-off. Too large and a malicious prover can choose a favorable time (e.g. claim more from a stream than entitled). Too small and valid proofs fail due to network or inclusion delay.
Options for a context-aware LEE
A context-aware LEE design should specify prover-supplied context, verifier-checked context, and leeway between proving and verification.
We must specify the security model with respect to both the prover and the verifier. A malicious prover could supply a favorable timestamp e.g. to claim more from a stream than really accrued. A malicious verifier could use “false” context to reject a valid proof or delay a transaction until a dispute window closes. We must account for these and similar issues in the design.
We should also design context handling with future decentralization in view, even if initial design assumed a centralized sequencer as the verifier.
The rest of this section outlines two main ways to handle context: system-provided and oracle-provided.
System-provided context
Privileged parties supply system-provided context: a centralized sequencer, or the slot leader after a potential transition to proof-of-stake or similar consensus. A local prover queries the “system” for e.g. current timestamp and uses it for execution. The verifier queries the “system” for context at verification time. For timestamps, proving and verification timestamps must lie within the allowed interval.
Oracle-provided context
Oracle-provided context outsources context provision to independent third parties (oracles). Oracles maintain accounts that hold updatable values (e.g. current time). A prover includes oracle accounts as program inputs. Programs choose which oracles they use. Users decide whether that choice fits their security model. Oracles compete on precision and reliability. It should be difficult for an oracle to selectively censor users or to control which programs use its data.
Extending the oracle model
The oracle-based pattern extends to other data (e.g. digital asset prices). It may be combined with optional attestation (TLS, zk-Passport) at the cost of extra trust assumptions.
An oracle-maintained account may post Bitcoin headers, which would act as a coarse time signal (~10 min resolution), in a “merged mining” fashion. The security assumption relies on enormous PoW cost to fake a Bitcoin header. The main failure mode for such an oracle is availability (did not post a new block on time) rather than authenticity (posted a fake block). Timestamp resolution from Bitcoin blocks may be too coarse for streams but is likely enough for dispute windows in channels.
System-provided and oracle-provided context accounts are not mutually exclusive. Block height is system-defined and is a natural fit for system-provided context. External data such as price feeds are by nature external, so oracles fit better for that. A program may use both (e.g. block height from the system, price feed from an oracle).
Summary and questions for discussion
- Should LEE expose context to programs? If yes, which options (sequencer vs oracle, transaction-level vs program-level)? If no, what is the impact on streams and channels, and what alternatives exist (oracle-only, weaker secutiry assumptions)?
- What LEE architecture constraints speak for or against the options listed here (or others)?
- What are the security and privacy implications? For example, using timestamp as a public input reveals that a program contains time-sensitive logic even if the code is shielded.
- What other context-dependent programs (e.g. voting, time-locked token allocations) do we consider important?
UPD: Edited on 2026-02-25 for clarity.