Wake Me Up When the Price Hits $5,000

Encrypted transactions protect data in transit. Conditional Transactions (CTXs) allow encrypted data to be executed when a condition is met.

This is a new EVM primitive. CTXs enable top-tier automations and workflows: onchain poker, automated liquidations for lending & perps, limit orders on AMMs, sealed-bid auctions, and private agent negotiations where terms stay hidden until reveal time.

What CTXs Enable

Standard EVM contracts store plaintext. Anyone with a block explorer can read state. CTXs change this — contracts store encrypted data and trigger decryption via callbacks.

The pattern:

1. User or agent submits encrypted data to a contract. It stays encrypted in storage.
2. When conditions are met, the contract calls submitCTX()
3. Validators batch all decryption requests from block N
4. Block N+1 executes all onDecrypt() callbacks with decrypted data

This is a two-block operation. The callback executes with an ephemeral sender address — not the original submitter.

Comparison: Chainlink Automation

If you've worked with Chainlink Automation, the mental model is similar. Both enable condition-triggered smart contract execution. The key difference: CTX adds encryption.

Breaking EVM Assumptions

EVM developers assume atomicity. You call a function, state changes, the transaction succeeds or reverts — all in one block. CTXs break this assumption intentionally.

When submitCTX() executes, the decryption does not happen immediately. It queues for the next block's batch decryption. This means:

• You cannot read decrypted results in the same transaction
• Logic must be structured as callbacks, not synchronous reads
• Multiple decryption requests from the same block batch together

The batching is the feature. All requests from block N decrypt simultaneously in block N+1, processed in order of creation. If block gas is exhausted, remaining decryptions roll over to the next block. This eliminates timing advantages — a sealed-bid auction where all bids decrypt together is fundamentally fairer than sequential reveals.

The Supplicant Interface

Contracts that receive CTX callbacks implement a standard interface:

interface IBiteSupplicant {
    function onDecrypt(
        bytes[] calldata decryptedArguments,
        bytes[] calldata plaintextArguments
    ) external;
}

When the committee decrypts, every registered supplicant's onDecrypt() fires. This enables complex multi-party workflows where multiple contracts react to the same decryption event.

source — docs

Use Cases for AI Agents

Encrypted Strategy Parameters. A trading agent stores rebalancing thresholds, price triggers, and position limits encrypted onchain. The contract only decrypts and executes when market conditions match. Competitors see that something triggered — not what the thresholds were.

Sealed Agent-to-Agent Negotiations. Two agents submit encrypted terms for a task. The contract decrypts both simultaneously when both sides have submitted, executing on the overlap. Neither agent sees the other's terms until reveal — eliminating first-mover disadvantage.

Conditional Autonomous Payments. Payment triggers fire only after decryption confirms a condition — delivery of data, completion of compute, verification of a result. This is "if/then" financial logic enforced by the chain.

Time-Locked Reveals. Encrypted data that automatically decrypts at a specific block number. Research swarms publish findings simultaneously. Prediction markets seal predictions until events resolve.

CTXs and Encrypted Transactions

Together they form complete privacy: encrypted in transit, encrypted state executed only when conditions are met.

Want to Build with CTXs?

If you're building something that needs conditional execution on encrypted state, reach out.