Spot — Limit, TWAP, Stop-Loss, Take-Profit Non-Custodial Decentralized DeFi Protocol

Agent-ready decentralized DeFi protocol for non-custodial advanced order types on EVM chains.

Spot provides non-custodial market, limit, TWAP, stop-loss, take-profit, and delayed-start orders on EVM chains, backed by immutable onchain contracts.

🔒 Security Audit Reports: Initial AstraSec audit and updated AstraSec audit

Why Spot

1. ✅ Non-custodial: RePermit binds spend authorization to exact order hashes instead of handing custody to the protocol.
2. 🔒 Oracle-protected: Trigger checks, slippage caps, freshness windows, and deadlines constrain execution.
3. 🛡️ Battle-tested: Contracts are audited and covered by an extensive Foundry test suite.
4. 🏗️ Production-ready: Spot is built for multi-chain deployment with repo-shipped config, ABIs, skill files, and a hosted MCP endpoint.

Supported Order Types

1. Market swaps
2. Limit orders
3. TWAP orders
4. Stop-loss orders
5. Take-profit orders
6. Delayed-start orders
7. Chunked recurring execution

Supported Chains

Spot supports multiple EVM chains. See config.json as the canonical source for supported chains and runtime addresses.

Orvex uses Spot's universal integration on Robinhood Chain (4663), with execution routing selected at fill time. No other Orvex mainnet deployment is listed in its official contract directory.

Robinhood's solver adapters cover Kyber, Flytrade (Magpie), OpenOcean, and LI.FI (LiFi).

How It Works

Each Spot order combines timing, sizing, trigger, and settlement rules in a single signed payload.

1. input.amount is the per-fill chunk size.
2. input.maxAmount is the total budget across fills.
3. output.limit is the minimum acceptable output per chunk.
4. output.triggerLower and output.triggerUpper define stop-loss and take-profit style trigger bands.
5. epoch controls recurrence: 0 for one-shot, > 0 for recurring fills.
6. start and deadline define the execution window.

output.limit, triggerLower, and triggerUpper are encoded as per-chunk output-token amounts in the output token's decimals.

A typical order lifecycle is:

1. Order creation: The user signs one EIP-712 order with chunk size, total amount, limits, slippage tolerance, epoch interval, and deadline.
2. Price attestation: The cosigner signs both trigger-time and current market price data.
3. Execution trigger: A whitelisted executor calls Executor.execute() when the order is eligible.
4. Validation: OrderReactor validates signatures, checks start, enforces epoch windows, verifies timestamps, and applies slippage protection.
5. Settlement: The reactor transfers input tokens, validates the fill result, and enforces minimum output.
6. Distribution: Surplus output is distributed between the swapper and optional referrer according to configured shares.

Security

Spot's contracts were professionally audited by AstraSec. See the initial security audit report and updated security audit report. Spot is also oracle-protected: execution depends on cosigned trigger and market price data, freshness windows, and slippage checks.

Access Controls

1. WM Allowlist: WM-gated entrypoints restrict privileged admin operations, and order execution honors exclusivity rules.
2. Two-Step Ownership: WM uses OpenZeppelin Ownable2Step for secure ownership transfers.
3. Executor Binding: Orders specify an authorized executor; only that executor can fill the order.
4. Non-Exclusive Fillers: exclusivity = 0 locks fills to the designated executor, while values above zero allow third-party fillers that satisfy the higher minimum output requirement.

Validation Layers

1. Order Validation: OrderValidationLib.validate() checks all order fields for validity.
2. Signature Verification: RePermit validates EIP-712 signatures and witness data binding.
3. Oracle Price Attestation: The cosigner supplies trigger-time and current market price data used to gate execution.
4. Epoch Enforcement: EpochLib.update() prevents early or duplicate fills within time windows.
5. Slippage Protection: A maximum 50% slippage cap is enforced in src/Constants.sol.
6. Freshness Windows: Current cosignatures expire after configurable time periods.
7. Trigger Timestamp Rules: Trigger timestamps must be after start and no later than the current timestamp.

Economic Security

1. Witness-Bound Spending: RePermit ties allowances to exact order hashes, preventing signature reuse.
2. Surplus Distribution: Excess tokens are distributed between the swapper and referrer.
3. Exact Allowances: SafeERC20.forceApprove() avoids allowance accumulation attacks.

Operational Security

1. Reentrancy Protection: OrderReactor uses ReentrancyGuard; Executor and Refinery rely on WM gating and internal invariants.
2. Safe Token Handling: The system supports USDT-like tokens and ETH handling semantics.
3. Emergency Pause: OrderReactor can be paused by WM-allowed addresses.

Examples

Plain-English examples:

1. Sell a fixed amount once, but only if the execution meets a minimum output.
2. Split a larger budget into equal chunks and execute one chunk every hour as a TWAP.
3. Move into a safer asset if price falls below a stop-loss threshold, or exit on strength if a take-profit threshold is reached.

Single-Shot Limit Order

Order memory order = Order({
    // ... standard fields
    epoch: 0,                    // Single execution
    input: Input({
        amount: 1000e6,          // Exact amount to spend
        maxAmount: 1000e6        // Same as amount
    }),
    output: Output({
        limit: 950 ether,        // Minimum acceptable output
        triggerLower: 0,         // No lower trigger gate
        triggerUpper: 0          // No upper trigger gate
    })
});

TWAP Order

Order memory order = Order({
    // ... standard fields
    epoch: 3600,                 // Execute every hour
    input: Input({
        amount: 100e6,           // 100 USDC per chunk
        maxAmount: 1000e6        // 1000 USDC total budget
    }),
    output: Output({
        limit: 95 ether,         // Minimum per chunk
        triggerLower: 0,
        triggerUpper: 0
    })
});

Stop-Loss / Take-Profit Order

Order memory order = Order({
    // ... standard fields
    epoch: 0,                    // Single execution
    start: block.timestamp,      // Order becomes active immediately
    output: Output({
        limit: 900 ether,        // Minimum per chunk output when executing
        triggerLower: 950 ether, // Stop-loss boundary per chunk
        triggerUpper: 1200 ether // Take-profit boundary per chunk
    })
});

Technical Overview

Core Components

1. 🧠 OrderReactor (src/OrderReactor.sol): Validates orders, checks epoch constraints, computes minimum output from cosigned prices, settles via inlined implementation with reentrancy protection, and supports emergency pause via the WM allowlist.
2. ✍️ RePermit (src/RePermit.sol): Permit2-style EIP-712 signatures with witness data that bind allowances to exact order hashes, preventing signature reuse.
3. 🧾 Cosigner (src/ops/Cosigner.sol): Attests to trigger-time and current market prices with token validation.
4. 🛠️ Executor (src/Executor.sol): Whitelisted fillers that execute eligible orders, enforce minimum output, and distribute surplus.
5. 🔐 WM (src/ops/WM.sol): Two-step ownership allowlist manager for executors and admin functions with event emission.
6. 🏭 Refinery (src/ops/Refinery.sol): Operations utility for batching multicalls and sweeping token balances by basis points.

Order Structure

Based on src/Structs.sol, each order contains:

struct Order {
    address reactor;           // OrderReactor contract address
    address executor;          // Authorized executor for this order
    Exchange exchange;         // Exchange parameters, referrer, and data
    address swapper;           // Order creator/signer
    uint256 nonce;             // Unique identifier
    uint256 start;             // Earliest execution timestamp
    uint256 deadline;          // Expiration timestamp
    uint256 chainid;           // Chain ID for cross-chain validation
    uint32 exclusivity;        // BPS-bounded exclusive execution
    uint32 epoch;              // Seconds between fills (0 = single-use)
    uint32 slippage;           // BPS applied to cosigned price
    uint32 freshness;          // Cosignature validity window in seconds
    Input input;               // Token to spend
    Output output;             // Token to receive
}

struct Input {
    address token;             // Input token address
    uint256 amount;            // Per-fill chunk amount
    uint256 maxAmount;         // Total amount across all fills
}

struct Output {
    address token;             // Output token address
    uint256 limit;             // Minimum acceptable output, in output-token decimals, per chunk
    uint256 triggerLower;      // Lower trigger boundary, in output-token decimals, per chunk
    uint256 triggerUpper;      // Upper trigger boundary, in output-token decimals, per chunk
    address recipient;         // Where to send output tokens
}

Limits & Constants