> For the complete documentation index, see [llms.txt](https://docs.dolomite.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dolomite.io/dolomite-governance/past-governance/dip-05-native-limit-orders.md).

# DIP-05: Native Limit Orders

{% hint style="info" %}

* **Outcome:** Passed
* **Vote date:** April 1, 2026
* **Official vote:** [BeraVote](https://app.beravote.com/space/dolomite/proposal/QmTeG6HRDDYuJBT54NQb6C7WcTawWfbhusx2j7ptZHcagY)
* **Final vote totals:** 3.72M veDOLO for; 0 against; 1.92K abstain
* **Implementation status:** In development
* **Original discussion:** [Dolomite Governance Forum](https://discord.com/channels/945099853929795607/1478937434057085010)
* **Current documentation:** To be added when the feature is released.
  {% endhint %}

The proposal text below is preserved exactly as presented for the governance vote. Only the status summary above is updated over time.

***

## Title

\[DIP-05] Approve Development & Deployment of Native Limit Orders

## Author(s)

Dolomite Team

## Date

2026-03-04

## Related Discussions

N/A

## Simple Summary

This proposal authorizes Dolomite to design, implement, audit, and deploy native limit order functionality across supported chains. The goal is to improve execution quality, unlock more advanced strategies for users, and strengthen Dolomite’s competitiveness versus CEX and DeFi alternatives.

## Abstract

Dolomite currently supports robust borrowing/lending and strategy workflows, but users still rely on manual execution timing for many trades and position-management actions. Native limit orders are a foundational product upgrade that enables users to predefine execution conditions (price, expiry, and optional risk controls) and have orders execute automatically when those conditions are met.

This proposal seeks governance approval for full delivery of limit orders from development through audited production launch, with rollout prioritized across most supported Dolomite markets/chains rather than a single-chain pilot.

## Motivation & Background

* **User demand:** Community and internal stakeholders have repeatedly requested limit-order style execution to reduce manual overhead and missed opportunities.
* **Product parity and growth:** Advanced order functionality is baseline on major CEX venues and increasingly common in DeFi; adding this closes a key feature gap.
* **Execution quality:** Rules-based order execution improves user control over entry/exit conditions and reduces dependence on live manual monitoring.

## Proposal Type

**Protocol Feature Development**

## Specification

Approve development, audit, and launch of native limit order support with the following baseline capabilities:

1. **Bulletin-board style limit order contract**

* Users submit order intent (asset pair, price, side, source subaccount) to an order-book-like contract.
* Orders can be created from Dolomite subaccounts used for borrow positions.
* **No funds are moved at order creation,** so collateralization can remain active while orders are open.
* Only **whitelisted solvers** are able to submit fills for now (as an additional security measure).
* Explore feasibility of offering limit orders on Isolation Mode markets

2. **Order types / controls**

* Spot limit orders
* Expiration / time-in-force (including optional no-expiry)
* Stop-limit support, with explicit oracle-based execution to ensure no pre-mature fills.

3. **Execution architecture**

* Dolomite subgraph indexes open orders.
* A solver monitors fillable orders and submits fills through a dedicated contract entrypoint.
* Solver integration may be implemented via the existing Dolomite liquidator TypeScript application with a dedicated “limit-order mode” run configuration.

4. **Fill behavior and lifecycle**

* Create / view / cancel order workflows
* Optional/flagged support for partial fills
* Orders that are temporarily unfillable (liquidity/cap constraints) should remain open and continue to be eligible for later fill attempts until canceled or expired.

5. **Fee model (initial)**

* 5 bps for uncorrelated assets
* 1 bp for correlated assets
* 50% of positive slippage as an additional performance fee component. This fee is waived for stop orders
* To reduce likelihood of spam on cheap chains, static non-refundable gas fee of $0.25 may be assessed. This amount is subject to change (up or down)
* Fees accrue to the DAO

6. **Pricing and settlement safeguards**

* Contract-level checks that fill price meets user constraints (or better) before fee application.
* Stop-limit trigger condition enforced in smart contracts using oracle/price checks to prevent premature execution.
* Settlement path includes fee extraction and routing to fee admin via appended action(s) in execution flow.

7. **Implementation-spec requirement**

* Before final release, publish a concise technical specification that documents:
  * trigger path
  * settlement path
  * fee calculation path
  * partial-fill behavior
  * failure/retry semantics

## Chain Rollout

* **Target:** Ethereum, Arbitrum, and Berachain, subject to final technical readiness and safety checks.

## Economic & Market Impact

Expected positive impact areas:

* Higher user retention from reduced manual execution burden
* Increased strategy participation and transaction activity
* Better execution tooling for active users and professional participants
* Improved competitive positioning versus platforms with mature order systems

Potential costs/considerations:

* Engineering and audit overhead
* Additional operational requirements for execution monitoring and fail-safes

## Risks & Considerations

1. **Execution risk:** Incorrect trigger conditions, stale price reads, or edge-case settlement failures.
2. \*\*Fillability risk: \*\*Orders can become unfillable due to liquidity constraints, supply/borrow caps, or insufficient executable depth at crossing prices.
3. **Market integrity risk:** Order handling must avoid unfair execution ordering or exploitable mechanics.
4. **Cross-chain consistency risk:** Feature parity and reliability must be validated per chain.
5. **Operational risk:** Solver uptime and robustness are required; retries, monitoring, and fail-safe behavior must be clearly defined.

## Security Requirement

Before production deployment, the implementation must complete:

* Independent smart-contract / execution-path audit (as applicable to final architecture)
* Remediation of high/critical findings
* Internal verification / test coverage sign-off *Note: Governance can later amend or waive this requirement, but this proposal includes audit-first as the default safety posture.*

## Implementation Plan

Upon approval, implementation should follow this sequence:

1. Finalize technical spec and acceptance criteria
2. Build core contracts/services/UI for limit order flows
3. Complete internal QA + simulation testing
4. Complete external audit and remediate findings
5. Deploy to production environments across supported chains
6. Publish user documentation and launch communications

Implementation is created by Leavitt Innovations, LLC, as the development company contributing to the Dolomite protocol, consistent with standard governance execution process.

## Success Criteria & Metrics

Primary success condition:

* **Feature is live in production and actively used by users**

Suggested measurable indicators (post-launch):

* Number of unique users placing limit orders
* Total notional volume executed via limit orders
* Fill rate and cancellation rate trends
* Adoption across supported chains
* Incident-free execution quality over defined observation window

## Additional Information & References

N/A