GOEMON Docs
  • Welcome
  • Introduction
    • GOEMON protocol
    • Intents
    • Solvers
      • Advanced Optimization Algorithms
      • Role of Searchers & Resolvers
      • Computational Complexity & Real-Time Data Integration
    • Privacy Preservation
      • Sealed-Bid Batch Auction
    • MEV (Maximal Extractable Value)
      • Advanced Strategies for Mitigating MEV
      • Comparative Analysis with Existing MEV Blockers
    • References
  • How it work
    • Order Flow
      • Declarative Input to Atomic On‑Chain Execution
  • Adapter Framework
  • Strategies
    • Overview
      • Vault Operation
      • Yield Farming Management
    • Ecosystem Strategies
Powered by GitBook
On this page
  1. How it work
  2. Order Flow

Declarative Input to Atomic On‑Chain Execution

Users submit high-level intents encoded in structured messages compliant with EIP‑7521. These messages are digitally signed using ECDSA (or similar asymmetric cryptography) and include metadata (nonce, timestamp, and execution conditions) that are validated against a pre-defined JSON schema. Our parser module uses formal grammars (e.g., Context-Free Grammars) to ensure strict adherence to the schema, rejecting any malformed or ambiguous intent. The system leverages a custom domain-specific language (DSL) that abstracts the low-level transaction details, allowing for a high-level semantic interpretation of user desires.

The Execution Engine compiles the outputs from our solver modules into a composite transaction. Utilizing techniques akin to a two-phase commit protocol, the engine performs a pre-execution simulation (using a symbolic execution engine) to verify state transitions and gas estimations before submission. Once verified, the engine assembles an atomic transaction payload ensuring that all sub-operations are executed in a single state transition or are entirely reverted. This guarantees not only transactional atomicity but also consistency with the user’s declarative intent, enforced through invariants verified via TLA+ specifications.

Our protocol uses formal verification frameworks (e.g., Coq, Isabelle/HOL) and model checking (e.g., TLA+, TLC) to prove that high-level intents transform correctly to on-chain operations. Each module is verified via automated theorem proving to ensure correctness, such as maintaining state invariants in the aggregator module.

PreviousOrder FlowNextAdapter Framework