Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(hyperliquid): read-only market data, backtests and cross-venue spread scanner

Open
#32 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python

Research direction

Start by reading the finance module's existing CSV or downloaded-price input path, the portfolio format, and the dependencies in issues #4 and #12. Then check Hyperliquid's public API limits and terms, and whether the proposed read precompiles are available on mainnet. Done means reproducible allocation backtests from stored inputs and a read-only spread scanner that reports timestamps and fee assumptions, with no order signing or trading keys.

Written by the indexing model from the issue text.

Description

chain-integration enhancement finance tier-3

Summary

Use Hyperliquid market data (spot, perps, funding rates) as an input to the finance module, add a backtest of the optimizer's allocations, and a read-only cross-venue spread scanner against Uniswap prices.

Motivation

It supplies a liquid crypto asset universe and ties into the arbitrage-detection capability described in the research paper, without trading risk.

Current state in this repo

  • The finance module consumes CSV or downloaded price data; the research paper in the documentation repo lists arbitrage detection as a target capability.

Proposal

  • Read-only data client for public market endpoints (and, if useful, on-chain read precompiles via the EVM adapter).
  • Asset loader producing input in the existing portfolio format; funding-rate series for analysis.
  • Backtest: apply an allocation over a historical window and report realised return/variance versus the optimizer's expectation.
  • Spread scanner comparing Hyperliquid mid prices to Uniswap quotes (#12) and logging opportunities; no orders are placed.

Acceptance criteria

  • No code path signs an order or holds trading keys.
  • Backtest results are reproducible from stored inputs (#4).
  • Scanner output states data timestamps and fee assumptions.

Out of scope

  • Order placement, even on testnet, until maintainers approve a separate design.

Dependencies

  • #4
  • Optionally #12 for the scanner.

Verify before implementing

  • Public API rate limits and terms of use.
  • Whether the read precompiles and any write paths are available on mainnet versus testnet only.

References


Part of ##1. Ground rules for all issues in this roadmap are listed there (testnet-first, no secrets in the repo, chain logic behind the registry, tests and docs with every PR).

Dominant language
Python
Stars
2
Forks
4
Avg merge
6h 54m
Merged PRs (30d)
7

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from QMeshPy/distributed-quantum

All issues in QMeshPy/distributed-quantum

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.