# Problem & Vision

<figure><img src="/files/RbjRLrUiadDnQ1LTY6YV" alt=""><figcaption></figcaption></figure>

This section explains where on-chain perpetuals fall short today and how BasePerp intends to address those gaps.

### 2.1 The Problem

On many perpetuals venues, execution can drift from fair value during bursts of latency or chain reorgs, and makers/takers only discover the gap after the fact. Cost of trading is also obscured by fixed opens/closes and funding, which collectively raise breakeven and punish iteration.

Liquidity is fragmented across multiple pools and bespoke vaults, making hedging hard and risk opaque for LPs. Weak liquidation hygiene turns volatility into cascades, while buffers and backstops—if they exist—are rarely expressed as clear, observable limits that LPs can underwrite.

### 2.2 Constraints Today

Traders face unpredictable fills and fee drag that make short feedback cycles expensive. LPs carry path-dependent PnL without explicit buffers or circuit breakers they can monitor in real time. Builders integrate into non-standard vaults and interfaces, limiting composability and re-use.

### 2.3 Our Vision

**Fair execution**. Orders should fill at an oracle price that is continuously validated by an independent deviationGuard and heartbeat checks—if validation fails, the trade reverts.

**Unified liquidity**. A single stablecoin counterparty vault concentrates depth, simplifies accounting, and presents one transparent source of maker economics to integrators.

**Low-friction fees**. Zero Fixed Commissions by default; a profitFeeRate applies only when a position closes in profit. Fixed opens/closes and funding can remain off unless a market explicitly requires them.

**Balanced exposure**. Open-interest is nudged toward equilibrium with transparent, bounded incentives governed by a counterSkewCap.

**LP protections**. A live buffer metric drives dynamic withdrawal tiers; optional hedging is used when it improves expected outcomes and is disclosed in reports.

**Composability & governance**. Standard ERC-4626 interfaces and read-only risk hooks invite integrations; parameter changes and upgrades are timelocked and audited.

**Rules-based backstop**. A security module with a capped securitySlashCap can absorb defined shortfalls without socializing routine losses.

### 2.4 Design Goals → Outcomes

We target outcomes that map directly to user safety and total cost:

* High hit-rate within the configured deviationGuard, with clear behavior on stale/out-of-band feeds.
* Lower breakeven via ZFC and profitFeeRate only on profitable closes.
* Predictable LP economics through transparent fee share, buffer tiers, and disclosed hedging policy.
* Public observability of OI/skew, buffer, fee flows, and risk parameters.
* Safe upgrades enforced by timelocks, audits, and narrowly scoped emergency powers.

### 2.5 Non-Goals

BasePerp does not promise yields or distribute presale funds as profit. It is not a custodian—contracts are self-custody, while the frontend may implement geo-screening.&#x20;

During development, we track a small set of operational metrics to guide iteration:

* Execution deviation hit-rate: percentage of orders filled within the configured deviationGuard.
* Buffer uptime: time spent in the zero withdrawal-fee tier.
* Liquidation success: percentage of eligible positions closed within target windows.
* OI balance health: share of time in low-skew bands vs. stressed bands.
* Parameter change SLA: time from proposal → timelock → activation.

Status & Funding. BasePerp is under active development. Presale proceeds fund engineering, audits, monitoring, testnet operations, and launch readiness; no presale funds are distributed as profit.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://baseperp.gitbook.io/baseperp-whitepaper/essentials/publish-your-docs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.