Nomad Docs
  • Nomad 101
    • Funds Recovery
    • Introduction
    • Our Mission
    • Getting Started
  • The Nomad Protocol
    • Overview
    • Cross-chain Messaging
      • Lifecycle of a Message
    • Verification Mechanisms
      • Background on Verification
      • Native Verification
      • External Verification
      • Optimistic Verification
      • Comparing Mechanisms
    • Security
      • Root of Trust
        • Fraud
          • Optimistic Timeout Period
          • Fraud Recovery
        • App-Governed Root of Trust
        • Liveness Assumptions
      • Attack Vectors
        • Key Compromise
        • Economic Attacks
        • Smart Contract Bugs
      • Long-Term Security
        • Permissionless Watchers
        • Financial Controls
        • Cross-Domain MEV
    • Smart Contracts
      • Home
      • Replica
      • XAppConnectionManager
    • Off-chain Agents
      • Updater
      • Watchers
      • Relayer
      • Processor
  • Token Bridge
    • Overview
    • How to Bridge
      • Using Etherscan
      • Nomad Bridge App
      • Testnet Bridge App
    • Asset Issuers
      • Custom Representations
    • Deployed Tokens
      • Mainnet
      • Testnet
    • Smart Contracts
      • BridgeRouter
      • TokenRegistry
      • BridgeToken
      • BridgeMessage
    • Architecture
    • FAQ
  • Governance Bridge
    • Overview
    • Zodiac: Nomad Module
    • Smart Contracts
      • NomadModule
    • Architecture
  • Developers
    • Quickstart
      • Send Messages
      • Receive Messages
    • Environments
      • Domain (Chain) IDs
    • Application Developers
      • Building xApps
      • SDK
        • Contracts SDK
        • Typescript SDK
      • Examples
        • Ping Pong
        • Example Bridge GUI
        • xApp Example
      • Advanced
        • Router Pattern
    • Node Operators
      • Running Agents Guide
        • Troubleshooting
      • Running a Watcher
      • Agent Operations
      • Agent Gas Values
      • The Keymaster
    • Core Developers
      • Upgrade Setup
      • Deploying Contracts
        • Development
        • Production
  • Operational Security
    • Audits
    • Bug Bounty
    • Governance
    • Contracts
    • Agent Operations
  • Resources
    • Awesome Interoperability
    • Brand Kit
    • FAQ
    • Glossary
    • GitHub
    • Discord
    • Twitter
    • Website
Powered by GitBook
On this page
  • What Constitutes Fraud?
  • Preventing Fraud
  1. The Nomad Protocol
  2. Security
  3. Root of Trust

Fraud

PreviousRoot of TrustNextOptimistic Timeout Period

Last updated 2 years ago

As described in the section on , Nomad's design introduces the possibility of the committing fraud.

Though this possibility exists, Nomad minimizes the chance of fraud by guaranteeing that:

  1. Fraud is easily observed by anyone

  2. Fraud is costly. Anyone can slash a fraudulent updater

  3. Fraud will be blocked. Permissioned Watchers can block Fraud before it takes effect in order to protect applications.

Because honest Watchers have time to observe and react to fraud, Nomad ensures the safety of the system while preserving other desirable properties like low cost and extensibility.

What Constitutes Fraud?

The Updater is the only actor in the Nomad system that can commit fraud in an attempt to cause safety failures. By fraud, we simply mean any case where an Updater signs an attestation to a merkle root that did not actually exist on the Home chain.

For example:

  • The canonical merkle root is 0xabcd...1234 — it reflects a commitment to all honest messages enqueued by applications and their users.

  • The Updater signs a fraudulent update attesting to merkle root 0xefgh...6789 — this root contains a malicious inserted message which sends all the funds escrowed in the to the Updater's address.

If the latter fraudulent state root is submitted to a Replica contract, then the malicious message can be authenticated against it after the optimistic timeout, which would enable the Updater to abscond with all of the escrowed funds.

For more details on Updaters, including their role and purpose in Nomad, please check out the.

Preventing Fraud

In order to prevent the malicious message from taking effect, Nomad enforces a dispute window during which all submitted roots remain pending. During this window, any honest can block the Replica from processing messages, which prevents the malicious message from settling.

Detecting Fraud

Detecting fraud is Nomad is very simple. Per the example above, fraud is easily noticed on the Home by observing for two distinct forms of fraud:

  1. Improper updates — where the Updater commits to an entirely invalid update

  2. Double updates — where the Updater commits to two conflicting updates

Double updates are easy to detect — if the Updater ever signs two updates where the old root is the same, but new roots conflict, this constitutes fraud.

The reason fraud is easy to detect in Nomad is we only need to check that state on remote chains is equal to the canonical state on the origin chain. Fundamentally, all we're doing is checking equivalence and inclusion of hashes, both of which can be done very quickly.

Proving Fraud on the Home

Importantly, fraud can always be proven to the Home contract on the origin chain. The Home contains the canonical message tree and the queue of roots, so any fraud attempted by the Updater can be proven deterministically on-chain and punished.

Thus, the Updater must submit a bonded stake on the origin chain which can be slashed as punishment. Anyone can permissionlessly prove fraud.

Blocking Fraud on the Replica

Unfortunately, certain types of fraud can't be objectively proven on the receiving chain; Replicas can't know which messages were sent on the origin chain and therefore can't check message tree validity in all cases.

Therefore, we rely on permissioned Watchers to block fraud on the Replica. Blocking Fraud simply involves unenrolling a Replica with a fraudulent root from the application's xAppConnectionManager contract, which disconnects the applications from receiving messages from that Replica. This effectively pauses message passing until Fraud has been remediated, keeping the application (and any funds or sensitive permissions therein) safe.

Improper updates are also easy to detect. The Home contract maintains a which contains every root generated — one for each message enqueued. If the Updater signs a root which isn't contained in this queue, this also constitutes fraud.

To learn more about how xApps disconnect from Replicas, please read more on .

App-Governed Root of Trust
optimistic verification
Updater
Nomad token bridge
Watcher
queue of roots
Updater documentation