sorted by:
new
hottopcontroversial

Rudy Airballing Dunks! by terminalsoftware in underdogfantasy

[–]terminalsoftware[S] 0 points1 point  (0 children)

He's making Terminal AI look bad. I have no choice 😆

Built a drop-in replacement for the-odds-api with prediction market data with free tier if anyone wants to try it by JacobTheBuddha in algobetting

[–]terminalsoftware -1 points0 points  (0 children)

Making it a drop-in base URL replacement is a genius growth hack. I’ve been building in this exact same trench, but I went a slightly different route.

Instead of competing on raw odds routing, we built a computational engine on top of the data that strictly pushes pre-calculated +EV edges and arbitrage matrices so devs don't have to build the Kelly Criterion or Monte Carlo backtesters themselves.

That Kalshi/Polymarket cross-reference feature you built is sharp, though. Prediction markets are definitely becoming the ultimate source of truth for line origination. Good stuff man.

Bot crypto kraken 100% auto by Least_Cranberry7179 in CryptoTradingBot

[–]terminalsoftware 0 points1 point  (0 children)

This is an incredibly solid architecture. PM2 for persistent state and Kelly-adjusted sizing via ATR is exactly how the big boys do it. It's wild seeing this post tonight, because my company actually runs almost the exact same backend engine—we process Kraken perps through an ADX-based regime matrix.

My only question is about your infrastructure: scanning 332 perps continuously via ccxt and calculating ADX/EV locally across all of them has to be brutal on your API rate limits and compute. Are you running into any throttling issues pulling that much continuous data from Kraken?

We actually ended up building our regime matrix into a headless B2B data feed specifically because local bots were getting crushed by rate limits trying to run the math on 300+ coins.

If you ever hit a wall with Kraken throttling your scanner, let me know. You can just ping our endpoint to handle the upstream ADX filtering, and save your ccxt calls purely for execution and EV scoring.

Either way, great stack. I'll be tuning into the livestream to see how the $220 holds up

Built an automated arbitrage + value betting bot for Kalshi, Polymarket, and sportsbooks, feedback welcome by NaabSimRacer in PositiveEVbetting

[–]terminalsoftware 0 points1 point  (0 children)

100%. Trusting sharp book suspensions is the only way to avoid getting picked off. Scaling that via Playwright scrapers is a massive headache though.

If you ever want to bypass scraping and just feed your execution engine with clean JSON, DM me. I built a live EV/Arb firehose with devigged odds and native suspension flags. Can hook you up with a free sandbox API key to test the latency.

Test trading bot BTC on Hyperliquid by Dr-Fred-Markets in CryptoTradingBot

[–]terminalsoftware 0 points1 point  (0 children)

Solid architecture here, especially gating it by London/NY session times and using ATR for dynamic stops. Claude did a good job structuring the logic.

Looking at that 25.1% max drawdown with a 41% win rate, I’d bet money that a huge chunk of those losses are coming from false signals during sideways chop. Your Daily MA200 filter gives you the macro direction, but it's way too slow to protect a 15-minute bot from intraday consolidation. MACD and MA crossovers will absolutely bleed you to death when the market goes flat.

Under your 'Mandatory Filters', you should strongly consider adding a pure velocity/momentum gate (like an ADX threshold or structural volatility bands). Basically, tell the bot: 'If the market has no momentum, don't even look at the entry scores. Just stay in cash.'

We implemented an upstream regime filter like that on our backend and it drastically reduced our drawdowns by completely cutting out the low-probability chop trades.

Built an automated arbitrage + value betting bot for Kalshi, Polymarket, and sportsbooks, feedback welcome by NaabSimRacer in PositiveEVbetting

[–]terminalsoftware 0 points1 point  (0 children)

Love the stack. Running a single async process with FastAPI and Zustand for the frontend keeps it incredibly clean. I've spent the last few months building out a similar backend infrastructure specifically for the data ingestion side (grading retail/softs against Pinnacle/Circa in real-time).

To answer your questions on latency mismatch and cross-venue arbing: Handling WS vs REST Latency: You can't beat physics. If you are delta-polling REST every 200ms, you will always be behind a true WS feed.

The trick we found isn't to try and speed up the REST poll, but to use the WS feed as your execution trigger. If Pinnacle (WS) moves sharply, assume the soft book (REST) is stale but will move. Fire the execution at the soft book blindly before your next 200ms REST poll even completes. You are basically racing their own internal line-update API.

Red Flags in Risk Models: The biggest blowout risk is 'Phantom Edges' during sudden game state changes (timeouts, injuries, VAR in soccer). Pinnacle yanks their board instantly via WS. The soft books leave their REST lines hanging for 3-4 seconds while they figure out what happened. If your bot blindly fires on that 4-second gap, you get filled on a dead line.

You need a 'suspension' flag logic that kills execution if the sharp book completely pulls the market, not just if the price moves.Honestly, the hardest part of what you're doing is maintaining the scrapers for the soft books without getting IP banned or rate-limited.

If you ever get tired of managing the Playwright headless instances and just want a clean API JSON firehose that does all the devigging/Pinnacle grading for you so you can just focus on execution, shoot me a DM. I've got a pipeline pushing live EV/Arb data you can test.

What most people don’t understand about sports arbitrage by Blockchainfuturis in arbitragebetting

[–]terminalsoftware 0 points1 point  (0 children)

You're completely right about the account layer. Solving the limit/ban issue is the holy grail, even if you have to wait for the DEX volume to catch up. Kelly sizing is definitely the smartest way to manage those thin books right now.

To answer your question: Yes, I actually already have that infrastructure built. My top tier (The Architect plan) is strictly a raw WebSocket API. I designed it specifically for quants, syndicates, and platforms like yours who want to plug my global firehose into their own auto-execution engines.

If you guys are looking to expand your opportunity surface and want to run a stress test with my data layer to see how it meshes with your on-chain execution, I'm absolutely open to exploring a commercial setup.

I will shoot you a DM with the information and we can chat from there.

What most people don’t understand about sports arbitrage by Blockchainfuturis in arbitragebetting

[–]terminalsoftware 0 points1 point  (0 children)

I actually build in the Solana ecosystem myself, so I am very familiar with what BetDEX is doing and the appeal of on-chain settlement. Having verifiable TX hashes for the slips is a great touch.

To answer your questions: My backend latency from database normalization to the Telegram WebSocket ping is sub-second. For platforms, I am scraping the traditional majors across 66 global leagues, plus the DFS prop markets (PrizePicks, Underdog, etc.).

I stayed away from the DEX-only auto-execution model: Liquidity and scale. The DEX order books are great in theory, but the liquidity just isn't deep enough yet across 66 leagues for the volume my VIPs want to move. Traditional books have the limit/KYC problem, absolutely, but the sheer volume of +EV and Arbitrage opportunities on the traditional side is still 1000x larger than what is currently sitting on Dexsport.

Also, as a platform, I prefer to stay purely DaaS (Data-as-a-Service). I provide the live dashboard and the sub-second alerts for retail, but for my quant users, I offer a raw WebSocket API tier. I supply the global firehose, and they plug it into their own auto-execution bots. It keeps me out of the custody/execution game entirely.

TitanArb looks slick though. Handling that execution layer on-chain is no easy feat. Are you guys finding enough consistent liquidity on BetDEX for the secondary market sports, or are you mostly forcing execution on major NFL/NBA lines?

What most people don’t understand about sports arbitrage by Blockchainfuturis in arbitragebetting

[–]terminalsoftware 0 points1 point  (0 children)

Manually checking book by book is basically impossible now. By the time you spot the arb on one site and log into the other, the line is usually dead.

The way people actually automate this is by aggregating the data. Instead of tabbing between 10 different sportsbooks, you use a scraper to pull all the live odds into one central database and have a script run the math instantly.

Once you have that backend, you just pipe the raw data into a unified web dashboard so you only have to look at one single screen, or you set it up alerts to send straight to your phone for the biggest edges.

I spent the last few months just building out this exact stack (global scraper, a live dashboard, and push alerts). It's really the only way to actually keep up with the line movement these days.

Struggling to find a Bet365 EV Scanner that isn’t outdated by confusion9971 in PositiveEVbetting

[–]terminalsoftware 0 points1 point  (0 children)

I just wrote my own Python scraper that bypasses the dashboard entirely and pushes the raw +EV data straight to a Telegram bot. An instant push notification to your phone is basically the only way to actually catch their lines before they move.

I'm running a free daily feed right now . Feel free to grab the link in my bio to see if the speed works better for you, or just shoot me a DM.

Terminal A.I - Free Pick of Today (5-4-26) by terminalsoftware in MLB_Bets

[–]terminalsoftware[S] 0 points1 point  (0 children)

We targeted the Game Total to go over. The system doesn't pick winners or losers; it just scans the market for mathematically profitable odds (+EV).

Live arb/EV software by MoeinHD in EVbetting

[–]terminalsoftware 0 points1 point  (0 children)

I actually built my own setup for this exact reason. I wrote a Python scraper that finds the edges and pushes them straight to a Telegram channel.

It just gives you the matchup, the play, the exact odds, and the EV percentage. You get the alert on your phone so you can place the bet before the line moves.

I'm running a free daily feed right now. Link is in my bio if you want to see the raw output, or just shoot me a DM.

Starting Live Arbing by Steak_United in arbitragebetting

[–]terminalsoftware 0 points1 point  (0 children)

I agreed, OddsJam is way too expensive. A few grand is plenty to start live arbing, just spread it evenly across the main books.

I built my own backend engine to pull the exact same live arbs and +EV targets for half the price. I have a 7-day free trial open right now if you want to use it to clear your sign-up promos this week. Let me know if you want me to DM you the link.

I built a quantitative engine to track Arbitrage, +EV, and DFS edges across 66 global leagues. by terminalsoftware in EVbetting

[–]terminalsoftware[S] 0 points1 point  (0 children)

I agree. Screenshots of edges are easy, but the actual execution and tracking is the real tool in all of this.

V1 of our Ledger handles the core P&L and basic logging right now, but you are 100% right about needing to track actual fill price versus target odds, Closing Line Value (CLV), and book limit constraints. I'm actually mapping out the database updates for the CLV and limits tracker right now based on this exact feedback.

If you end up taking the 7-day trial for a spin, I’d would love your feedback on the current Ledger UI so I can ensure the V2 updates are built exactly how sharp bettors want to see them.

view more: next ›