Orbs are PoS-secured Layer 3 infrastructure for advanced DeFi trading

From dLIMIT intent to an on-chain fill

One dLIMIT order turns a target price into a single fill when a competitive taker satisfies the maker's constraints.

The maker starts inside an integrated DEX interface such as QuickSwap or Sushi. After choosing input and output tokens, amount, limit price, and expiry, the wallet approves the ERC-20 input token if required. The order transaction then records the maker's constraints. Because dLIMIT is a one-chunk form of dTWAP, the total amount and chunk amount are equal. The underlying contract records order data without taking custody of the maker's balance; allowance authorizes transfer only when a valid fill executes.

Two roles drive the auction. Makers define the minimum acceptable output, deadline, and permitted exchange; takers search routes and bid with an output amount plus a requested fee. The contract compares net output after fees, so a better bid displaces a weaker one. A single competitive taker seeking only gas reimbursement anchors the auction near the best route it finds.

A fill occurs only while the order remains active, the wallet holds enough input tokens, and its allowance covers the chunk. The successful transaction moves input tokens from the maker to the selected exchange and returns output tokens to the maker. If no qualifying bid arrives, the order waits, expires, or is cancelled. Price control is therefore firm, while execution remains conditional, as documented in Using Orbs.

How does Orbs compare with AMM swaps and intent routers?

Three execution models serve different jobs: AMM swaps quote now, intent routers optimize a trade, and Orbs automates conditions.

A Uniswap pool prices an immediate swap from reserves, so execution and price impact occur in one transaction. 1inch and ParaSwap search multiple routes for a stronger quote, yet their ordinary swaps still execute at signing time. CoW Protocol is structurally closer to Liquidity Hub because solvers compete around signed trade intents. Chainlink Automation and Gelato automate contract calls, but a DEX must design and fund the job logic. Orbs packages advanced order behavior as trading protocols DEXs integrate directly.

Liquidity Hub evaluates two outside liquidity channels: an on-chain solver auction and decentralized orders submitted through an API. Its quote competes with the host DEX's AMM route. When external liquidity fails to improve the minimum output, settlement falls back to the AMM contract. The relevant alternative changes with whether the priority is immediate pool access, broad routing, or persistent order logic.

A three-layer execution model

Three layers divide responsibility: base chains secure assets, scaling networks reduce costs, and Orbs supplies application-specific execution.

Guardians run off-chain computation, while Proof-of-Stake elections and stake reside in EVM contracts on Ethereum and Polygon. The production mainnet has operated since 2019. Orbs supports two broad smart-contract environments: EVM networks and TON. Its documented EVM scope includes Ethereum, Polygon, BNB Chain, Avalanche, and Fantom; deployments also reach Base and Arbitrum. A DEX keeps its assets and settlement contracts on the connected network, so adopting the service does not require migrating liquidity into a separate Orbs pool.

V5 adds Committee Sync, which propagates Guardian-signed committee state to target contracts. Its first deployed phase covers two chains, Ethereum and Arbitrum, while existing products continue on the earlier execution rails. The registrar on each destination verifies committee thresholds, signatures, and registry rules before the application executes. Settlement-chain gas and finality still govern the on-chain leg.

The advanced trading toolkit

Four long-running product lines anchor Orbs trading infrastructure: dLIMIT, dTWAP, Liquidity Hub, and Perpetual Hub.

• dLIMIT adds decentralized limit orders at a specified price or better.
• dTWAP brings decentralized Time-Weighted Average Price schedules to a DEX.
• Liquidity Hub lets external solvers and professional liquidity providers compete with AMM liquidity.
• Perpetual Hub supplies decentralized services for intent-based perpetual markets.

At order level, dTWAP exposes three user-facing variables: total duration, chunk size, and interval. Its contract architecture has two actors, maker and taker. A maker defines amount, deadline, minimum output, and spacing; takers bid routes and fees. dLIMIT collapses that structure to one chunk, making total order size equal to individual trade size. dSLTP extends advanced orders with stop-loss and take-profit triggers, while Orbs Agentic applies cosigned oracle data and autonomous execution to agent-driven DeFi logic.

Liquidity Hub evaluates two external sources before using the underlying AMM: solver bids backed by on-chain liquidity or inventory, and decentralized API orders from liquidity providers. This design expands the quote set without moving the DEX's deposited liquidity. If neither source improves execution, the original pool route remains available.

The original Perpetual Hub design named three operating services: Hedger, Liquidator, and Price Oracle, with SYMMIO and IntentX among its collaborators. The Perpetual Hub Ultra 2.0 rollout expands this into a full-stack platform covering execution, settlement, hedging, liquidation, pricing, and a trading interface. Its target architecture uses a Trusted Execution Environment for state transitions, EIP-712 signed price data, a unified Merkle tree, and on-chain state-root commitments. Margin and liquidation thresholds remain settings of each deployed venue.

What does a dTWAP schedule look like?

Four hypothetical inputs define this dTWAP schedule: 12 ETH total, a 12-hour window, 1-hour intervals, and 3 missed intervals.

Dividing the 12 ETH total by 12 scheduled intervals produces a 1 ETH chunk. Nine eligible windows therefore settle 9 ETH, while three missed windows leave 3 ETH unfilled at expiry. The completed portion uses nine separate fills, so it also carries nine winning taker bids and their gas-reimbursement components. This concrete result shows the trade-off: smaller chunks spread market impact, but every successful chunk adds another execution cost. Changing any of the four inputs changes the completed amount or schedule.

ORBS token and Guardian incentives

Ten billion ORBS form the fixed token supply used for staking, delegation, Guardian selection, and network-service incentives.

The ORBS token launched as ERC-20 on Ethereum with a fixed supply of 10,000,000,000 units. Its original distribution assigned 55% to long-term reserves, 20% to the private sale, 20% to the team and founding partners, and 5% to advisers. Those genesis percentages explain where the units began; they do not describe live circulating balances. Polygon later became a second staking venue, while Ethereum remains the native token environment.

PoS V3 sets the gross staking reward parameter at 10% APR, and unstaking starts a 14-day cooldown without rewards. Each Guardian chooses the delegator share within a 0% to 66.667% range, so the gross rate is not an automatic wallet yield. Network governance controls PoS parameters, which makes the reward percentage a published setting rather than an immutable monetary rule.

Tetra charges 0 ORBS as its own staking-interface fee, while Ethereum or Polygon gas still applies. The staking rules set no minimum delegation amount. Gas therefore establishes the economic floor for small positions, and Guardian reward settings determine the delegator's share.

Entering through an integrated DEX

One integrated DEX defines the Orbs entry path, from network selection through allowance and order submission.

Open a DEX integration such as QuickSwap or Sushi, select the advanced order feature, and connect MetaMask or another compatible EVM wallet. Match the network displayed by the DEX: Ethereum Mainnet uses chain ID 1, Polygon 137, BNB Smart Chain 56, Avalanche C-Chain 43114, and Base Mainnet 8453. These identifiers describe networks in the Orbs EVM ecosystem; each DEX exposes only the products and chains it integrated. TON uses a different account and contract environment.

For dLIMIT, enter the amount, limit price, and expiry. For dTWAP, add the total duration, chunk size, and interval. The wallet approval covers the ERC-20 input token, and the order submission records the restrictions. The DEX's open-order view then shows pending, partially filled, completed, cancelled, or expired state. Cancellation stops future fills, while completed output settles to the designated wallet.

Order cost has four components: settlement-chain gas, the taker's requested fee, any DEX pool or route fee, and price impact. The dTWAP contract permits a taker fee from 0 output-token units upward, while better net-output bids outrank weaker bids. More completed chunks mean more gas-bearing executions. The integrated contract version and chosen network determine the exact signing sequence.

Who gains the most from Orbs-powered trading?

Three conditions define the strongest fit: a supported DEX, a compatible wallet, and an order worth automating. Orbs tools suit traders setting limit prices, splitting larger swaps, or seeking liquidity beyond one AMM. The main trade-offs are partial fills, repeated gas-bearing chunks, chain-specific contract exposure, and reliance on taker competition plus Guardian availability. dLIMIT favors price discipline; dTWAP favors execution spread; Liquidity Hub favors quote competition. A plain AMM swap remains clearer when immediate execution outweighs automation.