> For the complete documentation index, see [llms.txt](https://docs.omnipact.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omnipact.io/developers/omnipact-technology-white-paper/readme/oes-the-omni-escrow-system/3.1-deterministic-finite-state-machine-dfsm.md).

# 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).