> For the complete documentation index, see [llms.txt](https://svpchain.gitbook.io/svpchain-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://svpchain.gitbook.io/svpchain-docs/chain/oracle.md).

# DEX oracle (Slinky)

How the DEX and CLOB get consensus prices via Slinky — trust model for validators and traders.

The native **order book and perpetual markets** need timely, accurate prices for margin, liquidations, funding, and mark-to-market. Those prices come from the **Slinky** sidecar and are **confirmed through validator consensus** — the same mechanism that finalizes blocks.

This page covers the **protocol-level DEX oracle**. For reporter-based price feed contracts used by ecosystem DeFi apps (ETH/USD, BTC/USD, etc.), see [Oracle (ecosystem)](/svpchain-docs/ecosystem/oracle.md).

### What the oracle does

In plain terms:

1. **Slinky** (a sidecar process) pulls prices from multiple public exchanges (e.g. Binance, Coinbase, OKX) for each market listed on chain.
2. Each **validator** reads those prices and attaches its view to its vote when signing a block.
3. The network **aggregates** validator quotes (stake-weighted median) into the official on-chain price update.
4. Every other validator **checks** that update before accepting the block.

There is no “oracle contract” you trust instead of the chain. Price updates are part of **consensus**, not a separate permissioned service.

{% hint style="info" %}
**Full nodes** do not need to run Slinky. **Bonded validators** must — see [Validator setup §6](/svpchain-docs/chain/validator-setup.md). A validator without Slinky produces invalid vote extensions and will be jailed.
{% endhint %}

### Why on-chain prices are trustworthy

#### No single point of failure

Each market is configured with **several independent exchange feeds**. Slinky merges them; one exchange glitch or outage does not by itself define the chain price.

Validators do not all phone the same centralized server. Each runs its own Slinky sidecar and forms its own view before voting.

#### Consensus, not decree

The price written on chain is not “whatever the block proposer says.” It is the result of:

* Many validators reporting what they see.
* **Stake-weighted median** aggregation — outliers from small or dishonest actors carry less weight.
* **Independent re-computation** by every validator when a block is proposed. If the proposed prices do not match what honest nodes would derive from the same rules, the block is **rejected**.

Manipulating the median in a sustained way requires influencing a large share of **staked voting power** — effectively the same bar as attacking BFT consensus itself (more than one-third of stake, and sustained misbehavior risks slashing).

#### Built-in sanity checks

| Safeguard                        | What it means for you                                                                                                |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Minimum price change**         | Tiny, noise-level moves can be filtered per market so spam or micro-manipulation does not constantly move the index. |
| **Cross-validator verification** | Honest nodes compare proposed updates to their own cached prices; large unexplained gaps block acceptance.           |
| **Slashing & downtime rules**    | Validators that sign wrong or go offline lose stake or are jailed — including for bad or missing oracle votes.       |
| **Long unbonding period**        | Stake used to attack cannot be withdrawn immediately; attackers cannot “hit and run” with their bonded tokens.       |

Together, these layers mean **validity** (prices follow agreed rules and sources) and **authenticity** (they reflect what independent validators actually observed, not one party’s word).

### What “valid” means in practice

For integrators and traders, a price on SVPChain is **valid** when:

* It was included in a **committed block** that passed `ProcessProposal` checks on a supermajority of validators.
* It respects the market’s configured **sources and update rules** in `x/marketmap` / `x/prices`.
* It is the price the protocol uses for **the next settlement step** — note that some modules (e.g. CLOB liquidations) intentionally use the **previous block’s** consensus price so execution always runs on already-finalized numbers, not a price still being voted on in the same block.

If you read a price from RPC or an explorer, confirm it against the latest **committed** block height; pending proposals are not yet authoritative.

### Limits and honest expectations

No oracle is magic. You should still understand the edges:

* **Exchange reality** — On-chain prices track **configured CEX/index sources**, not every venue in the world. Illiquid or manipulated **off-chain** markets can still diverge from “fair value” until arbitrage and governance catch up.
* **Latency** — There is a short path from exchange → Slinky → vote → block. Extreme volatility can leave on-chain marks slightly behind the fastest off-chain feeds for a block or two.
* **Governance** — Which markets exist and which feeds count is set on chain. Wrong or stale **market configuration** is a governance/ops problem, not something users can fix from the client side.
* **Validator set** — Security scales with an honest, diverse validator set and total stake. A very small or colluding set would weaken any BFT chain, oracle included.

These are operational and market-structure risks, not “trust this one API key” risks.

### Who runs what

| Role      | Slinky sidecar | Oracle in `svpchaind`                                  |
| --------- | -------------- | ------------------------------------------------------ |
| Full node | Not required   | Disabled by default                                    |
| Validator | **Required**   | Enabled (`[oracle]` in `app.toml`, vote extensions on) |

Operational details — Docker image, ports, `oracle.json`, startup order — live in [Validator setup §6](/svpchain-docs/chain/validator-setup.md). Metrics and alerts: [Monitoring](/svpchain-docs/chain/monitoring.md).

### Next steps

| Related                     | Link                                                          |
| --------------------------- | ------------------------------------------------------------- |
| Run Slinky as a validator   | [validator-setup.md](/svpchain-docs/chain/validator-setup.md) |
| Ecosystem price feed oracle | [oracle.md](/svpchain-docs/ecosystem/oracle.md)               |
| Architecture overview       | [architecture.md](/svpchain-docs/chain/architecture.md)       |
| Oracle metrics & alerts     | [monitoring.md](/svpchain-docs/chain/monitoring.md)           |
| Glossary: Slinky            | [glossary.md](/svpchain-docs/reference/glossary.md)           |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://svpchain.gitbook.io/svpchain-docs/chain/oracle.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.