Execute

The trade execution engine that implements the Umoja protocol’s smartcoin and synth strategies is the intellectual property of Umoja Labs Corp.

Overview

Although Umoja's governance community may change key parameters as to how such strategies are executed via the Umoja Trade Engine (UTE), the trade execution engine itself is a proprietary product of Umoja Labs Corp.

Decentralized trade execution, with quickly changing regulatory guidance and institutional custody requirements, is simply not yet possible, but we hope to gradually introduce such technology when minimal security and counterparty requirements can be met.

It's important to note that the minting and burning of smartcoins is handled by the protocol, whereas the execution of the smartcoin's underlying strategies is executed by the UTE. The UTE is simply a component of the protocol, which is to be governed by the broader Umoja community.

UTE Architecture

The UTE is comprised of several core components:

Orders & Positions System (OPS)

The Orders & Positions Service (OPS), formerly known as MDES, provides essential functions for managing account positions, submitting orders, and facilitating transfers. It offers APIs that allow users to access account information and submit trades while also orchestrating the movement of collateral between off-exchange settlement providers and centralized finance (CeFi) exchanges. Additionally, OPS stores the entire history of account cashflows, orders, and trades for record-keeping.

Market Data System (MDS)

The Market Data Service (MDS) aggregates and normalizes market data from multiple centralized (CEX) and decentralized exchanges (DEX), utilizing CoinAPI as the primary data aggregator when available. Its infrastructure consists of an API microservice built with Flask, a Postgres database for data storage, and a Redis caching layer for efficient data retrieval.

Reference Data Service (RDS)

The Reference Data Service (RDS) manages static data for four key areas: assets (e.g., tokens, futures), markets (venues for asset exchange), exchanges (collections of markets), and ledgers (ownership registry locations, such as Arbitrum, Ethereum, or OKX). A demo of RDS is already set up using a Postgres database, running in AWS Singapore.

Market Simulation Service (MSS)

The Market Simulation Service (MSS) models market behavior through low-level code customized for specific markets and exchanges, adhering to a standardized interface.

For transfers, MSS evaluates which transfers are possible, estimates dynamic costs and time, and checks transfer validity. It also detects if a transfer is temporarily unavailable, such as OKX’s inability to withdraw from Arbitrum, and may require manual intervention. MSS maintains a list of acceptable exchanges and addresses for transfers.

For orders (limit and market), MSS calculates trading costs, market impact, fulfillment time, and checks order validity.

Regarding margin, MSS determines initial and maintenance margin requirements, assesses the impact of position changes, and defines acceptable leverage levels (max, min, increments), including whether leverage adjustments can be made without closing positions. It also accounts for exchange-specific margin requirements.

Smartcoin Core Algorithm

The Smartcoin Core Algorithm has two main components:

1. Position Solver

The Position Solver defines target positions using market data, current positions, and a strategy library. It adjusts positions based on triggers like $yBTC mint/burn requests, delta/margin rebalancing, and portfolio optimization. The system manages BTC liquidity between the $yBTC smart contract and centralized exchanges, ensuring delta neutrality and adhering to market and exchange constraints. Leverage manages counterparty risk and margin requirements, with adjustments made as needed.

2. Execution Solver

The Execution Solver translates target positions into an execution plan, detailing the steps and algorithms required (e.g., transfers, orders, leverage adjustments). It ensures execution across assets, markets, and exchanges, optimizing trades to minimize costs and handle market conditions like suspended withdrawals or cross-currency trades.

Execution Service

The Execution Service processes execution plans by accepting a JSON file detailing the steps involved. Some steps are run in parallel, while others follow a sequence. Each step specifies an action (e.g., transfer, algorithm, set leverage) along with its parameters. The service includes a REST API with endpoints to start, monitor, stop, or simulate an execution plan, supporting multiple plans running simultaneously and allowing for orderly cancellation if needed. It also stores results for each step, including associated trades and cashflows.

Pre-Trade and Post-Trade Analysis

The service performs pre-trade analysis using the Market Simulation Service to estimate costs and market impact. After execution, it calculates post-trade results, including slippage by comparing execution prices with reference values, such as the OKX index price.

Multi-Leg TWAP Strategy

This strategy executes orders over time to minimize market impact, balancing multiple legs while maintaining delta-neutral positions. Initially, it used market orders for simplicity, with plans to shift toward limiting orders to reduce trading costs.

Monitoring Service

The Monitoring Service is a standalone microservice that operates on a separate host or AWS availability zone and is designed to monitor and report on the health of key yBTC system components. It tracks the integrity of exchange APIs (both centralized and decentralized), market data APIs, and other external dependencies. Additionally, the service performs real-time reconciliations of portfolio positions and cash flows, alerting users to any anomalies it identifies. While important, this service is not within the scope of the trading prototype development.