3.3 Conditional Triggers

In the OES architecture, the state transition function input signal 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'sblock.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 (Happy cooperation) or (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.