Universes Rollups
  • 👋Introductions
  • Overview
    • 💡Background
      • Intents
    • ✨How it Works
      • Architecture
      • Intents
      • Transfers
  • OUR FEATURES
    • 🔗Bridge Cross-Chain
    • 🧊Liquidity Pools
    • 🔀Swap For Any Chain
    • ☄️Agregator AI
  • EXPLORER
    • 🔎Scan explorer
  • RESOURCE
    • ⌛Deployment
      • 📝Testnet Staging
  • FOR DEVELOPERS
    • Guides
    • 📹Solver Network
    • 🖥️xApps
Powered by GitBook
On this page
  • Overview
  • Flow of Funds
  • Components
  • Contracts
  • Agents
  • Transport Layer
  1. Overview
  2. How it Works

Architecture

PreviousHow it WorksNextIntents

Last updated 11 months ago

Overview

There are three types of messages related to intents within Uniroll:

  1. Intent. These messages are created when a user generates an intent, and are dispatched periodically from the source chain to the clearing chain using the transport layer. They contain the source of truth information for the intent data.

  2. Fill. These messages are generated when a solver fills an intent, and are dispatched periodically from the source chain to the clearing chain using the transport layer. These messages contain information about which solver should be credited in settlement.

  3. Settlement. These messages are generated when both the intent and fill messages arrive on the clearing chain. They are sent from the clearing chain to the settlement domain, which is where the solver will be repaid for intent execution.

Flow of Funds

When users create intents, funds are debited from the caller of newIntent and stored on the Spoke contracts. The unclaimed balance for this spoke is incremented by the intent amount, and can be used to settle solvers of other intents to this domain.

Solvers must deposit into the Spoke contracts, and this balance is debited when fillIntent is called.

deposit and fillIntent can be executed in the same call by the solver networks. deposit can also be called at any point in advance of filling.

Once an intent is filled and the message is added to the FillQueue, the solver can be thought of possessing a claim on any of the available liquidity held on the Spoke contracts.Settlement of these claims happens via the processSettlementQueue function on the Hub contract.

Intent settlement does not have to happen on the same domains associated with the intents, but can happen on any solver-configured spoke domain. This decouples repayment from intent routing and allows protocol participants to access a global settlement flow across chains.

Once the settlement messages arrive on the spokes, the settlement amounts are debited from the unclaimed balance held on that spoke and the associated solver has their balance incremented. At any point solvers can withdraw this balance from the contracts, or use it for filling new intents initited from the settlement domain.

Components

There are several on and off-chain components within this system.

Contracts

  • Hub. This clearing chain contract handles inbound intent and fill messages, and dispatches settlement of solver claims via the gateway contract.

  • HubGateway. This clearing chain contract is responsible for dispatching messages to the transport layer, and formatting the inbound message payloads to properly call the functions on the Hub.

  • Auctioneer. This clearing chain contract governs solver selection for routers. Routers compete in a race-to-the bottom auction, and only winning routers are reimbursed for transfers.

  • Spoke. This spoke contract holds funds from created intents (used as liquidity for settlement), and solver balances. It formats messages from the Intent and Fill queue and dispatches them via the SpokeGateway contract.

  • SpokeGateway. This spoke contract is responsible for dispatching messages to the transport layer, and formatting the inbound settlement messages to properly call the functions on the transport layer.

Agents

  • Relayers. These agents are responsible for executing periodic transactions across the network, primarily processing queues. Queues are processed according to configured age and size thresholds per chain.

  • Cartographer. This agent is responsible for creating a natively cross-chain view of the network state. This view is derived from an indexing layer (i.e. subgraphs) on each chain.

  • Router. The router is a solver, that looks to execute crosschain transactions broadcast throughout the network. These solvers are useful for integrations of crosschain applications without their own solver network.

Transport Layer

The transport layer is responsible for sending messages throughout the network. The messages are dispatched and processed by the HubGateway and SpokeGateway contracts.

✨
Uniroll architecture.