# 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.$$ $M$ $$ 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}}
$$

* $$ $S\_{init}$ $$ (Initialized):The contract is instantiated, parameters have been configured, waiting for funding.
* $$ $S\_{lock}$ $$ (Locked): The buyer's funds have been deposited into the Vault, and the guarantee has taken effect.
* $$ $S\_{del}$ $$ (Delivered): The seller submitted the on-chain performance certificate (Proof of Delivery).
* $$ $S\_{disp}$ $$ (Disputed): A dispute is triggered, the contract is suspended, and control is transferred to DAN.
* $$ $S\_{fin}$ $$ (Finalized): Normal case closure, with funds flowing to the seller.
* $$ $S\_{void}$ $$ (Voided): If the transaction is cancelled or an arbitration ruling decides on a refund, the funds will be returned to the buyer.
* $$ $q\_0$ $$ (Initial state): $$ $S\_{init}$ $$
* $$ $F$ $$ (Set of terminating states): $$ ${S\_{fin}, S\_{void}}$ $$。Once entering this set, the state becomes immutable.(Immutable)。

#### 3.1.2 Transition Function $$ $\delta$ $$

transfer function $$ $\delta: Q \times \Sigma \rightarrow Q$ $$ 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 $$ $S\_{del}$ $$(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).


---

# 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.1-deterministic-finite-state-machine-dfsm.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.