OtterLiquidityDocs
Architecture

How requests travel

Nothing in your browser talks to a node provider, a data provider, or any third party directly.

The chain path

Every call to the network goes to an endpoint on this domain, which forwards it onward. That endpoint accepts only the methods the application uses and rejects the rest, caps request size and batch length, and refuses requests whose origin is not this site.

Three things follow. The provider key never appears in anything shipped to a browser. The provider can be changed without redeploying the frontend. And people whose internet provider tampers with connections to well-known public endpoints — which happens on this chain — reach the network normally.

Two upstream providers are configured. If the first answers with anything other than success, the second is tried inside the same request.

What this does not cover

Transactions are broadcast by your wallet through its own node. Only simulation and waiting for confirmation travel through this path, and nothing can force a wallet to route elsewhere.

The data path

Prices, volume and market values come from a third-party index, also through an endpoint on this domain with an allowlist of permitted paths. Anything outside that list is refused rather than forwarded.

Every successful response is written to storage on our side before being shown. When the index is unavailable or rate-limited, the last snapshot is served with the time it was taken. The page is never blank, and stale data is always labelled as stale.

Which numbers come from where

Read from the chainRead from the index
Liquidity depth per price stepPrices in dollars
Current price and step sizeVolume and market value
Fee tier and token orderingToken names and images
Your positions and fees owedCandles

The split is not arbitrary: anything you would sign a transaction against is read from the contract. The index is good enough to choose a pool with and not good enough to commit money against.