3.1 Deterministic Finite State Machine (DFSM)

In OES, we not only regard state machines as a code pattern, but also as a kind of mathematical constraint. We have defined a five-tuple automaton. Let's formally describe the guarantee process:

$$M = (Q, \Sigma, \delta, q_0, F)$$

3.1.1 Mathematical Definition of States

• $Q$(Finite state set): All possible legal states in the protocol.

$$Q = \{S_{init}, S_{lock}, S_{del}, S_{disp}, S_{fin}, S_{void}\}$$

• (Initialized):The contract is instantiated, parameters have been configured, waiting for funding.

• (Locked): The buyer's funds have been deposited into the Vault, and the guarantee has taken effect.

• (Delivered): The seller submitted the on-chain performance certificate (Proof of Delivery).

• (Disputed): A dispute is triggered, the contract is suspended, and control is transferred to DAN.

• (Finalized): Normal case closure, with funds flowing to the seller.

• (Voided): If the transaction is cancelled or an arbitration ruling decides on a refund, the funds will be returned to the buyer.

• (Initial state):

• (Set of terminating states): 。Once entering this set, the state becomes immutable.(Immutable)。

3.1.2 Transition Function

transfer function Defines the legal state transition paths. Any attempt to transition that is not defined in this function will be handled by the smart contract's require()Statement interception and rollback (Revert)。

The core transfer logic is as follows:

1.Locking Transition:

$$\delta(S_{init}, \text{Deposit}) \rightarrow S_{lock}$$

Constraints: msg.value >= amount or token.transferFrom Success.

2.Delivery Transition.

$$\delta(S_{lock}, \text{SubmitProof}) \rightarrow S_{del}$$

Constraints: Only the seller can call, and block.timestamp < deliveryDeadline。

3.Settlement Transition:

$$\delta(S_{del}, \text{Confirm}) \rightarrow S_{fin}$$

Constraints: Buyer's signature confirmation or block.timestamp > inspectionPeriod (Automatic acceptance)。

4.Dispute Interrupt:

$$\delta(\{S_{del}, S_{lock}\}, \text{RaiseDispute}) \rightarrow S_{disp}$$

Constraints: within the inspectionPeriod, and neither party has confirmed.

3.1.3 Atomic Swap Implementation

OES leverages the atomic nature of blockchain to implement Conditional Asset Swap. Unlike traditional Hash Time-Locked Contracts (HTLC), which rely solely on hash preimages, OES expands the triggering conditions.

Solidity Style Pseudocode:

Solidity

function releaseFunds(uint256 escrowId) external nonReentrant {
    // 1. Load State
    Escrow storage e = escrows[escrowId];
    
    // 2. Validate State (Check Logic)
    // Must be in the "delivered" state and no disputes have occurred.
    require(e.state == State.DELIVERED, "Invalid state");
    
    // 3. Validate Triggers (Condition Logic)
    bool isManuallyConfirmed = msg.sender == e.buyer;
    bool isAutoRelease = block.timestamp > e.timelock + e.inspectionPeriod;
    require(isManuallyConfirmed || isAutoRelease, "Not releasable yet");

    // 4. State Update (Effects)
    // Modify the state before transferring funds to prevent reentrancy attacks(Checks-Effects-Interactions Pattern)
    e.state = State.FINALIZED;
    
    // 5. Execution (Interaction)
    // Call the Vault singleton for fund transfer
    IVault(vaultAddress).transferAssets(e.asset, e.seller, e.amount);
    
    emit FundsReleased(escrowId, e.seller, e.amount);
}

Security Properties:

• Idempotency: because the state was modified in step 4 to FINALIZED, even if the attacker calls the function again, it will still be in step 2 require fail. This ensures that the funds can only be released once.

• Delivery-versus-Payment (DvP): The only prerequisite for the release of funds is that the state machine has successfully transitioned to (meaning that the seller has submitted evidence). Mathematically, it is guaranteed that the buyer cannot withdraw funds unless the seller has submitted the action (except for refund upon timeout).