Introduction At Osmosis, we frequently need to operate the nodes for extracting data. This data can be used for various purposes such as analytics, monitoring, or serving off-chain web data services to clients. In this task, we request implementing a data pipeline that retrieves pool data from a real Osmosis full-node and creates a web server that allows retrieving ready-for-display pools in the frontend app. We will provide the necessary infrastructure to support your development. Problem Description

Introduction Osmosis is a decentralized exchange that is focused on providing traders with the best in-class opportunity to swap tokens. Being an app-chain, Osmosis has its own network operated by 150 validators. As a result, it heavily relies on applications such as blockchain explorers that would offer users and developers the opportunity to inspect the historical state. Some examples of the Osmosis explorers created by the community: Mintscan

Currently, there is a bug that leads to gas being charged for newly added events and attributes in Cosmos SDK messages that are called from CosmWasm contracts As a result, this prevents chain developers from adding useful events in a state-compatible manner. For example, these events in the Osmosis concentrated liquidity module lead to a state-break due to diverging gas numbers in the v23.x release line. Source 1 The first source of the state-break stems from the fact that wasmd does not correctly filter out events for StargateMsg here. As a result, the ReplyCosts function ends up charging gas for the newly added event attributes. Source 2

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

Estimation This is from estimating MsgSwapExactAmountin Gas used total: 155732 I[2023-12-19|23:32:27.763] runTx start sim=info I[2023-12-19|23:32:27.765] InfiniteGasMeter.ConsumeGas sim=info amount=1000 descriptor=Has I[2023-12-19|23:32:27.765] InfiniteGasMeter.ConsumeGas sim=info amount=1000 descriptor=ReadFlat I[2023-12-19|23:32:27.765] InfiniteGasMeter.ConsumeGas sim=info amount=30 descriptor=ReadPerByte I[2023-12-19|23:32:27.765] InfiniteGasMeter.ConsumeGas sim=info amount=15 descriptor=ReadPerByte

DexPerps Orderbook Cross-chain swaps Fee abstraction Privacy CosmWasm privacy support Threshold Decryption Chain-level privacy pool

Objective There are two main objectives in implementing account abstraction Add flexibility in what represents an account and how they are managed Add flexibility to account authentication when executing transactions/messages Accounts Right now an account is mainly represented by a key pair and and account's address can be derived from its public key. An account gets an account id when it first interacts with the chain. This has particular drawbacks for key rotation, but also the benefit of account addresses being deterministic across chains. Authentication

DeFi Degeneracy What was the first major DeFi protocol to do liquidity mining on Uniswap? Synthetix What was the first DEX launched on Ethereum? Etherdelta What currency was the first Terra stablecoin pegged to?

Notes Pre-swap block: https://www.mintscan.io/osmosis/blocks/9465039 Swap block: https://www.mintscan.io/osmosis/blocks/9465040 Tx in question: https://www.mintscan.io/osmosis/txs/E054F4F363113C6006C82BD7A899C48D454E419C5EED15CBF859F7D60718E99C Swaps in: 3000000 UUSDC Gets out: 10944266 UQCK Swap route is pools 678 > 952

http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-21.07.51.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-22.24.31.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-22.31.17.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-22.36.29.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-22.45.15.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-22.53.18.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-23.03.29.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-23.16.02.json http://localhost:3000/pixels?url=pixel-history/data/2022.06.20-23.28.16.json

The following are the different networks that are avaialble to use in the Osmosis blockchain. Network Description Upgrade Date local Local build or localOsmosis MM/DD/YYYY

https://docs.osmosis.zone/developing/dapps/get_started/cosmwasm-localosmosis.html Submit a wasm proposal The following is a quick guide to provide a basic example on how submit a wasm binary proposal in localOsmosis. Localosmosis The easiest way to setup your localOsmosis is by downloading the automated installer. You can learn more about localOsmosis by reading the README in the official repo. Run the following and choose option #3.

The following is a quick guide that shows the basics of deploying a contract to Osmosis. It covers: Seting up LocalOsmosis with the Osmosis installer. osmosisd binary automatically configured to connect to your localOsmosis localOsmosis setup in yout $HOME directory (~/localosmosis) Deploy a smart contract Download, compile, optimize

Date: March 2022 Link to WTF Osmosis v1: https://hackmd.io/EKgajOrXSASn950iPNCLXQ?edit Chain Dev Milestone 1 Agoric clawback enabled vesting Test & integrate updated vesting module from Agoric

Rendered This proposal proposes that the chain elect to do a software upgrade to the v5.0.0 software tag of the Osmosis codebase on block height 2383300. The timing of this upgrade is crucial to properly execute the Proposal 32 airdrop clawback. This clawback should happen right at the Airdrop end date of December 15th 5PM UTC, thus this upgrade must execute before it. The upgrade block height 2383300 is estimated to be at December 14th, UTC 2:30PM. Block times have high variance, so please be monitor the chain for more precise time estimates. Upgrade features This upgrade adds features such as: Upgrade Cosmos-SDK to SDK v0.44 from SDK v0.42 For a full list of updates in Cosmos-SDK v0.44.3 please see its changelog. Noteable highlights include:

This upgrade is a large stability upgrade to Osmosis. It brings with it faster epochs, and improved computation time for various on-chain operations, and fixes to the high gas amounts needed for bonding and unbonding txs. The features of this upgrade are: Fixing gas issues for bonding and unbonding tokens (NOTE: issues at epoch of there just being super high amounts of activity may still persist, with it taking seconds for txs to get into a block) Removing the need for users to withdraw locked tokens once they are finished unlocking Adding a governance parameter for a minimum fee to create a pool. Implements prop 12 See more in the changelog

Hey everyone! We have a testnet on v3, and are planning to upgrade that to the v4 upgrade soon. We wanted to have everyone have an opportunity to try syncing it / testing their cosmovisor setups against this, and check out what epoch time is looking at. This testnet is based on a September 9th state export of mainnet, with Sentinel's public key swapped out with other private keys, and its stake increased to be greater than 66% of the network. (Sentinel chosen because they had the highest stake) I think the plan should be to have this testnet going on for the week, but if no issues are found by tomorrow, we put an upgrade proposal on chain late Sunday. This would have voting end on Wednesday, and if no issues are found, we proceed with that. The upgrade block height should then target Friday morning EST. Links: Release notes: https://github.com/osmosis-labs/osmosis/releases/tag/v4.0.0-rc1 Testnet Frontend

AMM Design Batch execution design The core difficulty here is finding how to effectively price the gas costs, and making corresponding AMM designs. Smart LBPs how can we make LBPs not suck so much? The Balancer weight changing mechanism seems like a terrible way to do it. Also, should be demand weighted

Analytics & Tooling Pool-level analytics Historical data on TVL, volume, liquidity providers, swap fee V1 - historical price data -> imperator.co Estimated pool LP token value Record of parameter changes