degenbot.builders.tick_data_fetcher =================================== .. py:module:: degenbot.builders.tick_data_fetcher .. autoapi-nested-parse:: Tick data fetching and bitmap loading for V3/V4 pools. Module Contents --------------- .. py:class:: TickDataTypes Type-params that differ between V3 and V4 tick data fetchers. V3 and V4 use the same algorithm but different concrete types for the bitmap-at-word and liquidity-at-tick values. This dataclass captures those differences so the algorithm can be written once. .. py:attribute:: bitmap_at_word :type: type .. py:attribute:: liquidity_at_tick :type: type .. py:attribute:: tick_struct_types :type: tuple[str, ...] .. py:data:: FetchedTickData .. py:function:: make_tick_data_fetcher(pool_lookup: collections.abc.Callable[[int], degenbot.uniswap.v3_liquidity_pool.UniswapV3Pool | degenbot.uniswap.v4_liquidity_pool.UniswapV4Pool | None], io: degenbot._ffi.BotIo, types: TickDataTypes, *, state_view_address: str | None = None, pool_id: bytes | None = None) -> collections.abc.Callable[[int, int], FetchedTickData | None] Create a tick data fetcher callback for a concentrated-liquidity pool. ADR-005 sparse-map parity (slice 3b): the returned fetcher RETURNS the fetched word's tick data (``{tick: (liquidity_gross, liquidity_net, block)}``) rather than writing it back via ``update_tick_data``. This is the contract both the Rust ``TickWordFetcher`` seam AND the Python companion's sparse-write-back sites expect — the former holds the write lock across the fetch call (a write-back fetcher would re-enter it and deadlock), the latter now merges the returned data explicitly so the on-chain baseline is preserved when an update is later applied on top. Returns ``None`` if the pool is not found or the bitmap RPC fails (the Rust loop treats this as a fetch failure → gives up; a Python sparse loop treats this as an unresolved word → ``LiquidityPoolError``). An empty dict marks the word known with no initialized ticks (an all-zero bitmap word — the Rust merge records the word as known either way). For V4 pools, pass ``state_view_address`` and ``pool_id`` so the fetcher calls the state-view contract with the correct V4 ABI (``getTickBitmap(bytes32,int16)`` / ``getTickLiquidity(bytes32,int24)``). When these are absent the fetcher uses V3 ABI calls (``tickBitmap(int16)`` / ``ticks(int24)``) on ``pool.address``. :returns: The computed value.