> 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/architecture.md).

# Architecture

How SVPChain is put together — Cosmos SDK + EVM, CometBFT consensus, in-protocol oracle, native CLOB, and bridge daemon.

SVPChain is a Cosmos SDK application chain with an EVM execution layer. CometBFT (Tendermint) drives consensus, the EVM module runs Solidity, a native Cosmos SDK module provides the on-chain CLOB, the Slinky oracle sidecar feeds prices in via vote extensions, and a bridge daemon watches Ethereum for deposits.

### Stack at a glance

<table data-view="cards"><thead><tr><th>Layer</th><th>What it does</th></tr></thead><tbody><tr><td>Consensus</td><td>CometBFT BFT PoS. ~1s blocks, single-block finality.</td></tr><tr><td>EVM execution</td><td>Solidity contracts, EIP-1559 fees, JSON-RPC on port 8545.</td></tr><tr><td>Native CLOB</td><td>Protocol-level order book and matching engine implemented as a Cosmos SDK module.</td></tr><tr><td>Oracle</td><td>Slinky sidecar; prices delivered through validator vote extensions.</td></tr><tr><td>Bridge daemon</td><td>Polls Ethereum for deposit events; bridge contracts forked from Hyperliquid.</td></tr><tr><td>State / storage</td><td>IAVL-backed Cosmos store; EVM state lives alongside the SDK state.</td></tr></tbody></table>

### Components

#### Consensus (CometBFT)

* Byzantine Fault Tolerant, Proof-of-Stake.
* Block time: \~1 second (`timeout_commit = "1s"`).
* **Finality is instant** — once a block is committed, it cannot be reverted. There are no reorgs to design indexers around.
* The active validator set is **permissioned** today. See [Validator setup](/svpchain-docs/chain/validator-setup.md).

#### EVM execution layer

* Drop-in EVM. Solidity, Vyper, all standard tooling.
* EIP-1559 enabled. Min gas price `2 Gwei`, default base fee `1.9 Gwei`.
* Replay protection via EIP-155 chain IDs (`2518` mainnet, `2517` testnet).
* JSON-RPC on `:8545`, WebSocket under `/ws`.

#### Native CLOB module

* On-chain order book and matching engine, implemented as a Cosmos SDK module — not a Solidity contract.
* Order placement, cancellation, and fills are first-class chain transactions.
* Accessible from Solidity through a precompile (address: TODO — published once stabilized).

#### Slinky oracle

* Prices are delivered into consensus via validator **vote extensions**, not by a permissioned oracle contract.
* Each validator must run the Slinky sidecar — a validator that is bonded but not running Slinky will be jailed for invalid vote extensions.
* How DEX/CLOB prices stay authentic and valid: [DEX oracle (Slinky)](/svpchain-docs/chain/oracle.md). Operations: [Validator setup §6](/svpchain-docs/chain/validator-setup.md). Ecosystem reporter feeds: [Oracle](/svpchain-docs/ecosystem/oracle.md).

#### Bridge daemon

* Built into `svpchaind`. Polls an Ethereum JSON-RPC endpoint (Sepolia for testnet, mainnet TBD) for deposit events.
* The bridge contracts on Ethereum are a fork of the Hyperliquid bridge contracts.
* Contract addresses: TODO.

### Transaction lifecycle

1. **Submit.** A signed transaction hits an RPC node — EVM tx via `eth_sendRawTransaction`, Cosmos tx via the SDK transaction broadcast.
2. **Mempool.** The tx is gossiped to other nodes through the P2P network.
3. **Propose.** The current proposer includes a batch of txs in a block, alongside vote extensions carrying oracle prices.
4. **Commit.** Validators run BFT voting; once 2/3+ pre-commit, the block is **final**.
5. **Execute.** Each node deterministically applies the block — EVM state, CLOB matches, bank/staking effects.
6. **Receipts.** Receipts and logs are exposed over JSON-RPC and WebSocket; explorer indexers pick them up.

### Account model

* SVPChain accounts have **two address representations** for the same underlying key:
  * **EVM (`0x...`)** — used by MetaMask, Solidity, and JSON-RPC.
  * **Bech32 (`svp1...`)** — used by Cosmos tooling, staking, governance, and the CLI.
* They map 1:1 — funding either address funds the account.

### Next steps

<table data-view="cards"><thead><tr><th>Keep reading</th><th data-card-target data-type="content-ref">Link</th></tr></thead><tbody><tr><td>Endpoints, chain IDs, native token</td><td><a href="/svpchain-docs/chain/networks.md">Networks</a></td></tr><tr><td>Talk to the chain from code</td><td><a href="/svpchain-docs/build/api-overview.md">API overview</a></td></tr><tr><td>Run production infrastructure</td><td><a href="/svpchain-docs/chain/run-a-node.md">Run a node</a></td></tr><tr><td>Chain parameters and limits</td><td><a href="/svpchain-docs/reference/chain-parameters.md">Chain parameters</a></td></tr></tbody></table>


---

# 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/architecture.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.