# 3.3 Conditional Triggers

In the OES architecture, the state transition function $$ $\delta(S, \sigma) \rightarrow S'$ $$ input signal $$ $\sigma$ $$ It is not limited to simple deposits and withdrawals of funds. We have built a modular trigger stack that supports complex conditional logic based on time, data, and cryptographic credentials.

#### 3.3.1 Time-based Triggers 

Time is the only objective and trustless variable on the blockchain. OES utilizes Ethereum's`block.timestamp` As an immutable clock source, it implements two types of core logics: Relative Timelocks and Absolute Time Windows.

1\. Liveness Guarantees

To prevent fund deadlocks caused by one party losing contact, the agreement enforces timeout-based mandatory state transitions:

* Seller Timeout:

$$
Condition: S\_{state} = Locked \land t\_{now} > T\_{deposit} + \Delta t\_{delivery}
$$

```
If the seller within $\Delta t_{delivery}$ The buyer shall obtain (it) if the performance certificate is not submitted within the period. reclai m() Permissions, trigger atomic refund.
```

* Auto-Finalization:

$$
Condition: S\_{state} = Delivered \land t\_{now} > T\_{delivery} + \Delta t\_{inspection}
$$

If the buyer has not initiated a dispute by the end of the cooling-off period $\Deltat\_{inspection}$, the system will assume "tacit satisfaction" and allow Keepers to trigger the release of funds.

2.Vesting Logic

For service or compensation guarantees, OES supports the streaming payment logic:

$$
Available(t) = Amount\_{total} \times \frac{t\_{now} - t\_{start}}{t\_{end} - t\_{start}}
$$

This allows funds to be unlocked linearly according to block time instead of being delivered all at once, reducing the prepayment risk for buyers.

***

#### 3.3.2 Oracle-based Triggers

This is a key component of OmniPact's implementation of "real-world perception". We have deeply integrated Chainlink Functions and Automation to convert Web2 API data into on-chain verifiable boolean values.

1\. Request-Response Pattern

OES does not directly initiate HTTP requests; instead, it executes them through a decentralized oracle network (DON) proxy:

1. Request: OES contract emits an event `OracleRequest(url, query, script)`。
2. Consensus: Chainlink DON nodes independently execute JavaScript code (such as querying FedEx API for logistics status or FlightAware for flight delay data) and perform aggregated consensus on the results.
3. Callback:  `bool isDelivered = true`）and its signature written back to OES `fulfillRequest()` Interface.

2.Verification & Aggregation

To prevent a single API source from misbehaving, OES supports a multi-source aggregation strategy:

$$
Trigger = (\text{API}\_A \land \text{API}\_B) \lor (\text{API}\_C)
$$

Status changes will only be triggered when cross-validation by multiple independent data sources (such as DHL + UPS + local postal services) is successful.

$$
\delta(S\_{lock}) \rightarrow S\_{del}
$$

***

#### 3.3.3 Signature-based Triggers 

For scenarios requiring human subjective confirmation, OES adopts a multi-signature logic based on EIP-712 (Typed Structured Data Hashing and Signing). This not only optimizes Gas costs (off-chain signing, on-chain verification) but also ensures that users clearly know what they are signing.

1\. Intent Verification

All manual operations (such as confirmDelivery, cancelOrder) all require the submission of an ECDSA signature that conforms to the following structure:

Solidity

```
struct ReleaseIntent {
    bytes32 escrowId;
    uint256 amount;
    string action; // "RELEASE" or "REFUND"
    uint256 nonce;
    uint256 deadline;
}
```

Contract passed `ecrecover` Recover the signer's address and connect with `Registry` Compare with the participants (Buyer/Seller/Arbiter) in it.

2\. 2-of-3 Escrow Multisig

In some lightweight modes (without invoking the DAN network), OES can be configured in the classic 2/3 multi-signature mode:

* Key A: buyer
* Key B: seller
* Key C: A mutually trusted intermediary (or DAN agent) jointly designated by both parties
* Trigger logic: Fund release requires $$ $\text{Sign}\_A + \text{Sign}*B$ $$(Happy cooperation) or $$ $\text{Sign}*{A/B} + \text{Sign}\_C$ $$(Dispute mediation).

This mechanism allows both parties to conduct multiple negotiations without consuming on-chain Gas, and only broadcast a transaction to the chain when a final consensus is reached, which greatly reduces the collaboration cost.

***

> The flexibility of OmniPact in handling complex business logic: ensuring liveness through time, connecting to reality through oracles, and anchoring human intentions through signatures.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.omnipact.io/developers/omnipact-technology-white-paper/readme/oes-the-omni-escrow-system/3.3-conditional-triggers.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.