Initial Architecture In the initial SQS architecture, we combined the SQS web server (the read side) together with the node logic (the write side) in-process. While this proved to be an attractive architecture for the initial iteration speed, it has also caused impediments stemming from chain repository merge, branch and release processes. Currently, each SQS change is low-risk. However, it has to go through the same expensive processes as the chain repository. Current Release Process During a chain release process, an SQS change has to be backported to multiple release branches. The process entails:

Docker Build Logs make docker-build-debug [+] Building 22.2s (16/18) docker:default => [internal] load .dockerignore 0.0s => => transferring context: 230B 0.0s => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 2.45kB 0.0s => resolve image config for docker.io/docker/dockerfile:1 0.8s => CACHED docker-image://docker.io/docker/dockerfile:1@sha256:ac85f380a63b13dfcefa89046420e1781752bab202 0.0s

Introduction Sidecar Query Server (SQS) is an off-chain server tailored to performing expensive query tasks. The high-level architecture is that the chain reads data at the end of the block, parses it, and then writes it into a Redis instance. There is no persistent storage. All data gets cleared and overwritten at the end of the block. The sidecar query server then reads the parsed data from Redis and serves it to the client via HTTP endpoints. The goal is to perform computationally and data-intensive tasks outside of nodes or clients. For example, swap routing falls under this category because it requires all pool data for performing a complex routing algorithm. Osmosis Swap Router

Mempool Fee Market Integrator Guide The Osmosis team recently introduced an EIP-1559 style fee market in order to mitigate blocks from being filled with invalid txs. This mechanism calculates a transaction fee each block (named base_fee), which is dynamic based on volume of transactions. If the blocks are consistently full, the transaction fee grows at a pre-defined rate, making invalid transaction spam less desirable from the viewpoint of the sending party. This increases until a maximum base fee is reached. Inversely, if the blocks are empty, the base fee decreases to a minium value. There are parameters for the min, max base fee, and the max rate of change.

Index Pool State Subscribe to Websocket events to get updates about the block advances On every event, requery pool state Query each module separately. Reasons:Concurrent processing and decreased lock contention E.g. while writing CL pool state to disk, query gamm pools 3 Node queries every ~5 secs Acquire Lock