# Trading Layer

Pumpkin’s trading layer is designed to support live trading. That imposes a stricter requirement than “a DEX UI”:

* execution must be fast enough to follow a room in realtime,
* state must be verifiable enough to prevent performance theater,
* and the terminal must be powerful enough for professional flows without leaving the surface.

***

### Spot Aggregation (Multi-chain)

Pumpkin supports onchain spot trading across Solana, Base, BSC, and the broader EVM ecosystem, aggregating liquidity across mainstream DEX venues and routing paths.

#### Routing philosophy: optimize expected outcome, not only quoted price

A real router optimizes a composite objective:

* output after impact and fees
* execution success probability
* latency penalties
* slippage bounds
* fallback path reliability

{% @mermaid/diagram content="flowchart LR
Q\[Quote Collection] --> P\[Path Generation]
P --> S\[Simulation + Slippage Bounds]
S --> X\[Execution + Fallback]
X --> R\[Receipt Parsing]
R --> U\[Fill Events + Trace Links]" %}

### ZK Perpetuals Engine

#### Design goal

Deliver high-performance perpetual trading with:

* deterministic matching and risk rules,
* verifiable accounting (PnL, funding, liquidation),
* and an execution layer that cannot “cheat” via hidden ledger manipulation.

#### The exchange as a provable state machine

Pumpkin models the perps exchange as a state machine with a canonical committed state root:

**State includes (conceptual):**

* account collateral balances
* open positions (size, entry, funding index)
* open orders
* market configs and risk parameters
* fee accumulators (protocol, rebates, builder add-ons)
* event log commitments (for audit and replay)

Each batch applies a set of inputs (orders, cancels, oracle samples, funding updates, liquidations) and produces a new state root.

A proof attests:\
\&#xNAN;**“Given previous root and batch inputs, the new root is correct.”**

Only verified proofs are accepted onchain.

{% @mermaid/diagram content="flowchart TB
U\[Signed Orders + Cancels] --> SQ\[Sequencer: batch builder]
O\[Oracle Samples + Funding Inputs] --> SQ
SQ --> EX\[Deterministic Matching + Risk Transition]
EX --> PR\[Prover: generate validity proof]
PR --> VC\[Onchain Verifier]
VC --> SR\[State Root Update]
SR --> EV\[Event Commitments + Receipts]" %}

#### Matching policy: price-time priority

Pumpkin uses price-time priority by default:

* highest priority to best price
* within the same price level, earliest time first
* deterministic partial-fill rules
* deterministic tie-breaking

This matters because the matching rule must be:

1. understandable to traders, and
2. enforceable inside the proof.

#### Risk enforcement as circuit invariants

Risk is enforced as invariants inside the state transition, not as a discretionary system setting. Examples:

* positions cannot transition into invalid margin states except via defined liquidation transitions
* leverage caps and position limits are enforced deterministically
* liquidation eligibility is computed from approved price constructions

#### Price constructions: last, index, and mark

Pumpkin supports multiple price types:

* **Last price:** executed trade price
* **Index price:** external reference aggregation
* **Mark price:** used for liquidation safety

Candle series can be derived from each type to provide transparency and reduce manipulation risk.

#### Liquidation as a deterministic, provable transition

Liquidation events are part of the same proven state machine.

{% @mermaid/diagram content="flowchart LR
M\[Mark Price Update] --> C\[Margin Check]
C -->|Healthy| H\[No Change]
C -->|Below Threshold| L\[Liquidation Transition]
L --> U\[State Update + Event Commitment]" %}

### Trading Terminal Innovations

Pumpkin’s terminal is designed as an execution environment that can keep up with live trading. These features are not “nice-to-haves”; they reduce follow friction, improve comprehension, and increase safety.

#### Multi-chart split (15 layouts)

Users can view multiple charts simultaneously with 15 layouts—critical for correlation monitoring, hedging, and multi-market sessions.

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

#### Fully modular UI layout

Trading components (chart, order panel, orderbook, positions, fills, alerts) are movable and resizable, allowing both beginners and professionals to build a workflow that matches their execution style.

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

#### Sound alerts for critical events

Users can configure sound alerts for:

* TP/SL triggers
* funding events
* auto-deleveraging events
* liquidation proximity warnings

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

#### Position management: merge vs split

Positions can be managed in merged mode or split mode.

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

#### Trade-on-chart workflows

Pumpkin supports professional workflows:

* click-to-order on the chart
* drag-to-set TP/SL
* chart markers and annotations
* reverse position

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

#### Themes (six styles)

Pumpkin offers six trading themes to improve long-session comfort.

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

#### Position direction modes: hedged vs one-way

* **Hedged mode:** hold long and short simultaneously (execution-friendly).
* **One-way mode:** single net position (capital efficient, professional/MM friendly).

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


---

# 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://docs.pumpkin.xyz/product/trading-layer.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.
