With Polymarket's recent acquisition of DomeAPI to bring their infrastructure in-house, there is a sudden gap for developers building cross-market arbitrage bots, tracking whale wallets, or running quantitative models across prediction markets. If you are trading across Polymarket, Kalshi, or Limitless, you need a unified API to avoid getting locked into a single exchange's ecosystem.

pmxt is stepping in to fill that void.

Comments URL: https://news.ycombinator.com/item?id=47098551

Points: 4

# Comments: 0

We’ve hit ~450 stars and 30k downloads. We are currently the standard in the space. Limitless.Exchange endorsed us, and the founder of ccxt has even starred the repo.

What worked: Instead of traditional marketing, we focused on "Utility Marketing." We found risk-free arbitrage opportunities between markets, wrote scripts to capture them using pmxt, and posted the open-source code on r/algotrading. Basically, "Here is free alpha -> You need this library to run it -> Download pmxt."

That strategy got us the initial wave of retail algotraders, but we've plateaued. We seem to have exhausted the "retail algo" crowd. We want to break into the next tier: becoming critical infrastructure for larger players or expanding the pie.

My Question to HN: For those who have scaled niche OSS dev tools past the "initial traction" phase: 1. Do we keep feeding the retail crowd? (e.g., more complex strategies, more "make money" scripts?) 2. Or do we pivot to "Enterprise" features? (e.g., focus purely on latency, reliability, and institutional docs?) 3. Is this just a market cap issue? Are prediction markets just too small right now to support a 1k+ star library, and we should just wait for the industry to catch up?

Thanks for the insight.

https://github.com/pmxt-dev/pmxt

Comments URL: https://news.ycombinator.com/item?id=46958011

Points: 2

# Comments: 1

Test coverage is high. I'd recommend checking it out to form your own opinions.

I built pmxt to solve this. It normalizes the data across platforms so you can treat them as a single liquidity source.

It’s open source and I'm looking for feedback on the API structure before I start adding execution/trading endpoints.

Comments URL: https://news.ycombinator.com/item?id=46575615

Points: 2

# Comments: 2

Turns out, going straight to the source is not only cheaper, but I could offer the same data for more than 50% less than traditional providers. So I built Qoery, a Python SDK that makes DeFi data actually affordable for students, indie devs, and anyone building side projects.

What you get: Real-time and historical data from major DEXs, token prices, pool analytics – all accessible through clean Python code.

My Product Hunt launch: https://www.producthunt.com/products/qoery-python-sdk

I'm hanging out there all day answering questions and would genuinely appreciate any feedback or support if you've ever been in the same boat (aka needing data but being priced out).

Comments URL: https://news.ycombinator.com/item?id=46453466

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46444902

Points: 1

# Comments: 0

That infrastructure is heavy, expensive, and requires constant maintenance to filter wash-trading and normalize order books.

But if you are building for DeFi, that data is technically irrelevant. The "real" executable price is on-chain (Uniswap, Raydium, Curve).

I realized that if I just ignored the CEXs entirely and only indexed the blockchain, I could drop the cost basis by an order of magnitude.

So I built qoery.com

It indexes DEX logs directly from RPC nodes. It doesn't touch centralized exchange data.

The Trade-off: If you need global VWAP (Volume Weighted Average Price) including Binance/Coinbase, this API is useless to you. If you need the actual on-chain price for a dApp or wallet, this is the exact same data as the big guys, but ~85% cheaper (starts at $3.99 vs ~$35).

I’m curious if there are edge cases I’m missing where a DeFi app would strictly require off-chain CEX data?

Comments URL: https://news.ycombinator.com/item?id=46419862

Points: 2

# Comments: 0

I learned to index and query the blockchain directly, cutting out the middleman fees.

The result is qoery.com.

Comments URL: https://news.ycombinator.com/item?id=46287113

Points: 1

# Comments: 1

So we built madrasly. Run

npx madrasly your-spec.json output-dir

and you get a fully interactive API playground with all fields pre-populated from your OpenAPI examples. Path parameters, query params, request bodies—everything just works. One command, zero configuration, and your developers can actually test your API without wanting to throw their laptop. Check out the live demo or grab it from GitHub. If Mintlify won't fix it, we will.

Feel free to star us on GitHub! We also offer free hosting on our website (no paid tiers available). madrasly.com.

Comments URL: https://news.ycombinator.com/item?id=46033516

Points: 1

# Comments: 0

DEMO: https://coingecko-y.vercel.app/ GITHUB: https://github.com/Playground-Y/Playground-Y

Comments URL: https://news.ycombinator.com/item?id=45968704

Points: 1

# Comments: 0

Quick comment: the code on the website isn't using any sort of intellisense or highlighting

I see what you're saying. Stay laser-focused on potential enterprise customers, and iterate with them until they pay.

I'm now building qoery.com. The product is functional but not fully polished. I have 60 sign-ups but no paying customers yet. The feedback I'm getting from existing users is "improve the product and we'll pay."

I've spent the last two weeks iterating heavily on the product based on this feedback. It's significantly better now, but growth has completely stagnated during this time.

So I'm facing a dilemma: should I keep iterating based on user feedback until I convert those first users to paid customers? Or should I shift focus to customer acquisition and try to find users who might pay for what exists today?

Looking for advice from founders who've been through this.

Comments URL: https://news.ycombinator.com/item?id=45914137

Points: 2

# Comments: 5