Verifiable Condition

A verifiable condition's outcome is deterministic, meaning it will always resolve to the same result given the same on-chain data. Its logic is transparent and publicly auditable on the blockchain, eliminating hidden rules or subjective interpretation. This ensures all parties can independently verify the condition's state before and after execution.

• Example: A condition checking if block.timestamp > 1672531200 will be true for every node at the same moment.

Verifiable conditions are evaluated using data that is native to the blockchain state. This includes block data (timestamp, number, hash), transaction data (sender, value, calldata), and smart contract storage or event logs. They cannot rely on private or off-chain information unless it is first attested via an oracle like Chainlink.

• Common Data Sources: msg.sender, block.number, token balances, event emissions.

The logic of a verifiable condition is encoded within or referenced by a smart contract. The contract's code acts as the ultimate arbiter, automatically executing predefined actions (e.g., releasing funds, transferring NFTs) when the condition is met. This enforceability removes the need for intermediaries and creates cryptographic guarantees.

• Mechanism: Conditions are typically evaluated within functions guarded by require() or if statements.

Verifiable conditions are composable, meaning simple conditions can be combined using logical operators (AND, OR, NOT) to create complex, multi-faceted rules. They are also programmable, allowing developers to craft intricate business logic for DeFi, gaming, or governance.

• Complex Example: (userBalance >= 100 tokens) AND (block.timestamp > vestingStart + 1 year) OR (governanceVotePassed == true).

Conditions are fundamentally triggers that react to changes in blockchain state or the passage of time. State-based triggers depend on a variable crossing a threshold (e.g., price >= $100). Time-based triggers depend on the blockchain's timestamp or block number.

• Use Cases: Vesting schedules (time), limit orders (price state), DAO proposal execution (vote state).

The computational cost (gas) of evaluating a condition is a critical feature. Conditions that rely on cheap SLOAD operations or pure math are far more efficient than those requiring complex computations or external calls. Optimizing condition logic is essential for scalable applications.

• Best Practice: Use stored boolean flags or timestamps instead of re-calculating complex results on-chain.

On DEXs like Uniswap, verifiable conditions govern trade execution and liquidity provision.

• Limit Orders: A trader can set a condition to execute a swap only if the price reaches a specific level, creating a trustless limit order.
• Concentrated Liquidity: Liquidity providers (LPs) set price range conditions (e.g., ETH between $3,000-$3,500). The smart contract verifies the current price is within the range before allowing the LP's capital to be used, improving capital efficiency.
• Fee Collection: Conditions automatically divert a percentage of each trade to the protocol treasury and LPs.

This enables sophisticated, time-based financial agreements without intermediaries.

• Vesting Schedules: Token grants for employees or investors unlock linearly over time. A verifiable condition checks the block timestamp against the vesting cliff and schedule before releasing tokens.
• Subscription Services: A user streams payment (e.g., via Superfluid) to a service. The condition verifies the service is active (e.g., a wallet holds a valid NFT) each second; if not, payments stop automatically.
• Escrow & Milestones: Funds in a smart contract escrow are released only when a verifiable condition is met, such as the delivery of a digital asset confirmed by an oracle.

Decentralized Autonomous Organizations use verifiable conditions to enforce community decisions transparently.

• Proposal Execution: A successful governance vote creates a condition. The treasury smart contract will only execute a fund transfer if the proposal has passed a quorum and majority vote, verified on-chain.
• Multi-Sig with Time Locks: Conditions can require both a multi-signature approval from council members and a mandatory waiting period before high-value transactions are valid, adding security layers.
• Grant Disbursements: A grant is paid out in tranches, with each payment conditional on the recipient providing verifiable proof of milestone completion.

These complex financial instruments rely entirely on objective, verifiable conditions for payout triggers.

• Parametric Insurance: A crop insurance smart contract pays out automatically if a decentralized oracle reports rainfall below a certain threshold for a defined period. The condition is based on objective data, not claims assessment.
• Options Contracts: An American call option smart contract allows the holder to exercise (buy the underlying asset) at the strike price, but only if the condition current_price > strike_price is true at the time of exercise.
• Prediction Markets: Markets resolve to 'Yes' or 'No' based on a verifiable condition about a future event (e.g., "Will Candidate X win the election?"), with payouts distributed automatically.

A verifiable condition must be deterministic; its outcome is solely determined by its inputs and logic, with no external dependencies. This property is critical for consensus and reproducibility across all network nodes.

• Security Impact: Prevents disputes over condition outcomes, as any honest node can independently compute and verify the same result.
• Risk: Non-deterministic elements (e.g., random numbers, oracle data without consensus) can lead to chain forks or failed state transitions.

The data required to evaluate a condition must be available to the verifying parties, creating a fundamental tension with privacy.

• On-Chain Conditions: Input data is public, enabling universal verification but exposing transaction details.
• Off-Chain/ZK Conditions: Use cryptographic proofs (like zk-SNARKs) to verify execution without revealing inputs, enhancing privacy. This shifts trust to the correctness of the cryptographic setup and proof system.

Conditions relying on external data (oracles) inherit the oracle's security model. This is a major attack vector.

• Centralized Oracle Risk: A single point of failure; compromise leads to incorrect condition resolution.
• Decentralized Oracle Networks: Mitigate this but introduce latency, cost, and potential data freshness issues.
• Example: A loan liquidation condition based on a manipulated price feed can trigger unjustified liquidations.

The complexity of a condition's logic is constrained by the execution environment's gas limits and computational model.

• Smart Contract Platforms: Complex conditions consume more gas, increasing cost and potentially hitting block gas limits, causing transaction failure.
• Specialized VMs: Systems like the Ethereum L2 Scroll's zkEVM allow more complex verifiable computation off-chain, with only a proof verified on-chain, bypassing gas limits for the main logic.

Conditions dependent on block timestamps or block numbers are vulnerable to miner/validator manipulation within a small tolerance.

• Block Timestamp Risk: Miners can slightly adjust timestamps (e.g., ±15 seconds in Ethereum), which can be exploited in time-sensitive financial logic.
• Best Practice: Use block numbers for longer timeframes (e.g., 30-day locks) and account for manipulation tolerance in design. Oracle-based time services provide more precision but add oracle risk.

The security of a long-lived verifiable condition depends on the immutability of its defining code and the upgrade mechanisms of its host system.

• Immutable Logic: Provides strong guarantees but lacks bug fix ability.
• Upgradable Contracts: Introduce proxy risk; a compromised admin key can change the condition's logic, violating its original intent.
• Mitigation: Use timelocks, multi-sig governance, or immutable logic registries to manage upgrade risks transparently.