DEV Community: 0xGollum

I cloned my equity options scanner for crypto — the same 3 rules, a completely different data source

0xGollum — Tue, 28 Jul 2026 19:26:51 +0000

A while back I built a scanner that flags "unusual options activity" on US equities — the kind of signal where a contract suddenly trades on way more volume than its standing open interest, backed by real dollar premium, not just noise. Three gates: liquidity, freshness (volume vs open interest ratio), and money behind the trade.

Someone asked me: could the same idea work for crypto options? My first instinct was "sure, just swap the data source." That instinct was mostly right, but not entirely — here's what actually changed.

The data source is a different shape

Equities options data (I was pulling from a public CDN) comes back per-ticker: one call, one full chain for that symbol. Crypto options don't work that way — there's really one dominant venue for BTC/ETH options, and its public API returns every strike and expiry for a whole currency in a single call. So the "loop over tickers" became a "loop over currencies" — structurally similar, but the unit of iteration changed.

No fixed contract multiplier

US equity options are always 1 contract = 100 shares. That "x100" was hardcoded in my premium calculation. Crypto options are 1 contract = 1 unit of the underlying (1 BTC, 1 ETH) — no multiplier. I ended up parameterizing the premium function instead of hardcoding the multiplier, which also made the pure signal-logic module reusable as-is between both versions. Same detection math, same tests, different constant.

Prices aren't in USD

Crypto options are quoted in the base currency (a BTC option's price is itself a fraction of a BTC), not in dollars. So every price has to be converted using the current index price before any of the USD-premium thresholds make sense. Easy to get right, easy to silently get wrong if you forget it in one code path.

The bug that actually mattered

While writing tests for the instrument-name parser (something like BTC-28AUG26-59000-P), I'd assumed the date chunk was always a fixed length. It's not — a 1-digit day ("7AUG26") is shorter than a 2-digit day ("28AUG26"). My first length check silently rejected every single-digit-day contract as unparseable. That's roughly 10% of live instruments gone, quietly, with no error — and they skew toward near-dated (often the most actively traded) expiries.

Nothing caught it until I wrote a dedicated test for the parser itself, separate from the end-to-end "does it produce output" test. The lesson isn't really about crypto or options — it's that a parsing function deserves its own unit tests with real edge-case inputs, not just a smoke test that happens to pass because your sample data avoided the edge case.

Same three rules, same pure detection logic, ported across a genuinely different market — most of the actual work was in the boring conversion layer, not the "signal" part.

The crypto version is live on Apify if you want to poke at it: https://apify.com/0xgollum/unusual-crypto-options-activity

Turning a Public Market-Transparency Dataset Into a Volume-Anomaly Scanner

0xGollum — Tue, 28 Jul 2026 12:30:24 +0000

Every week, publicly listed stocks in the US have their off-exchange ("dark pool") trading volume disclosed per symbol, per venue, under a market-transparency rule that predates most people's interest in market data APIs. The catch: it's published as raw, paginated compliance data, not a friendly product. Nobody looks at it directly.

I spent an afternoon turning that into a signal: is this week's off-exchange volume for a given ticker unusual compared to its own recent history?

The interesting engineering bits

Partition-key gotchas. The API enforces that any sort operation must filter ALL its partition keys with an exact-match comparator, or you get a 400 - though the error message thankfully tells you exactly which keys are missing. Once you know that, filtering instead of sorting sidesteps the whole problem.

Comparator naming isn't obvious. "greater or equal" isn't spelled the way you'd guess - it's a short enum name you basically have to discover by trial. A handful of curl calls with different guesses got there faster than reading the docs end to end.

JSON vs CSV by header, not URL param. Same endpoint, same body - send an Accept: application/json header and you get typed JSON back instead of a quoted-CSV text blob you'd otherwise have to parse by hand.

The actual signal

Rather than an absolute threshold (which punishes small-caps and ignores mega-caps equally), each ticker's most recent reported week gets compared against its OWN trailing average over the prior weeks. A stock trading 3x its own normal off-exchange volume is a much more useful signal than "over 1 million shares," which means something completely different depending on the ticker.

Only tickers that clear both a minimum volume floor and a minimum spike ratio get returned. Empty runs are never billed, so there's no incentive to pad results with noise - a design pattern I try to keep across everything I ship.

Packaged it as an Apify actor (pay-per-result): Dark Pool Pulse - https://apify.com/0xgollum/dark-pool-pulse

Always curious what data-anomaly patterns other people are scanning for - drop them in the comments.

Signal Hub MCP: Plugging Trading Signals Directly Into AI Agents

0xGollum — Mon, 27 Jul 2026 18:15:53 +0000

If you're building an autonomous trading or betting agent, you've probably hit this friction: your data source is a dashboard, but your agent lives in a chat loop. You end up writing glue code to bridge the two.

I just shipped Signal Hub MCP, a small Apify Actor that closes that gap for two data sources I already maintain: unusual options activity (volume/open-interest anomalies on US equities) and horse racing odds-movement signals.

What it does

It's a standard MCP server, deployed as an Apify Actor in Standby mode (Streamable HTTP, not stdio). Two tools exposed:

get_unusual_options_activity(tickers, min_vol_oi_ratio, max_results)
get_horse_racing_signals(max_races, only_signals)

Your agent just calls the tool mid-conversation. No dashboard, no manual actor runs, no dataset parsing.

Why Standby mode + Pay-Per-Event

Apify's Actor Standby mode keeps the server warm and reachable over HTTP instead of spinning up per-request. Billing is Pay-Per-Event, charged per tool call, not a subscription. That mapped cleanly onto the MCP tool-call model: one Actor.charge() per tool invocation.

Internally, each tool call triggers a run of one of my existing standalone actors (Unusual Options Activity Scanner, Horse Racing Pulse) and returns the dataset. No duplicated scraping logic — the MCP layer is purely a thinner, agent-friendly interface on top of what already existed.

Try it

https://apify.com/0xgollum/signal-hub-mcp

More tools from the same portfolio (crypto funding rates, prediction markets) are next in line for the same treatment.

Why I only track one bookmaker for my odds-movement signal (and it's not the popular one)

0xGollum — Fri, 24 Jul 2026 18:29:38 +0000

Most odds-comparison tools I looked at blend prices across 20, 30, sometimes 40+ bookmakers. More books, more data, right?

For a movement-detection signal specifically, I don't think so — and building an odds-movement tracker for soccer taught me why.

The problem with averaging books

A "steamer" (implied probability jumping fast) or a "drifter" (fading) is supposed to mean one thing: real money is moving the market. But most retail-facing bookmakers move their lines reactively — copying the sharper books, adjusting for their own promotional exposure, or just lagging by minutes to hours. Blend 30 of those together and you average out the signal along with the noise. A steamer detected on a consensus feed is often just one popular book catching up, not new information.

Why one specific bookmaker

Pinnacle is built differently: low margins, no betting limits for winners, and a business model that depends on the line staying accurate rather than protecting the house. Professional bettors treat it as the closest thing to a "true" market price precisely because it reacts fastest and cleanest to real money. If you want a movement signal that means something, you want the reaction, not the consensus.

What that means in practice

One source, key-less, no proxy — the bookmaker's own guest API is public
Leagues aren't hardcoded: every run pulls whatever's actively being priced, so it tracks domestic leagues most of the year and auto-picks up World Cup / Euro matches during a tournament without a code change
steamer/drifter rows fire only on the delta between two runs — no history table to maintain yourself

I'm 0xGollum, I build small data actors on Apify — mostly scrapers and monitors for signals I found annoying to track by hand. More of what I ship: linktr.ee/0xGollum

Getting past Binance and Bybit's datacenter IP blocks without overpaying for proxies

0xGollum — Fri, 24 Jul 2026 18:08:54 +0000

I've been building a small actor that compares perpetual futures funding rates across exchanges to flag arbitrage spreads. Most exchanges (OKX, Gate.io, KuCoin, Bitget, MEXC) have clean, key-less public APIs that just work from any server, including cloud/datacenter IPs.

Binance is not one of them. Hit its public funding rate endpoint from a datacenter IP and you get a flat HTTP 451 — geo-blocked, no way around it with a direct connection.

I'd shipped without Binance for months, figuring that wall was permanent. Then, while extending the actor to more exchanges, I noticed something I hadn't planned for: Bybit — which had worked fine from day one — started returning HTTP 403 from the exact same server. Same code, same IP range, different day. No announcement, no changelog entry I could find. It just started blocking.

That's the actual lesson here: an API block you hit once isn't necessarily permanent, and a block you've never hit isn't necessarily safe either. Both directions can change without warning.

The fix: proxy only what actually needs it

The obvious fix is "route everything through a residential proxy." The problem: residential proxy bandwidth costs real money, and 5 of my 7 exchanges don't need it at all. Paying proxy rates for every single request when only two exchanges are blocking would be wasteful — and slower, since residential circuits add latency direct connections don't have.

So the actual fix is per-exchange:

Detect the blocked ones by status code (451 for a hard geo-block, 403 for the softer anti-bot flavor)
Only those two calls get an explicit proxy URL
Everything else keeps hitting the exchange directly, fast and free

async def _get_json(client, url, params=None, *, proxy_url=None):
    if proxy_url:
        async with httpx.AsyncClient(proxy=proxy_url) as proxied:
            r = await proxied.get(url, params=params, ...)
    else:
        r = await client.get(url, params=params, ...)
    ...

One conditional client, one proxy URL passed down only where it's needed. The other 5 exchanges never touch the proxy at all.

Worth re-testing what you gave up on

The bigger habit change: I'd marked Binance as "permanently excluded" in my own notes and never looked back. That was fine for Binance (still 451, still needs the proxy). But I would have shipped Bybit broken silently if I hadn't happened to be touching that code again for an unrelated reason.

If you maintain anything that scrapes or calls third-party APIs long enough, the honest move is to periodically re-run the sources you've already integrated, not just the ones you're adding — blocks appear on a schedule you don't control.

I'm 0xGollum, I build small data actors on Apify — mostly scrapers and monitors for signals I found annoying to track by hand. If you're curious what else I'm shipping: linktr.ee/0xGollum

I added a new feature to a live paid actor — the data was already there, I just wasn't reading it

0xGollum — Wed, 22 Jul 2026 12:14:17 +0000

Horse Racing Pulse has been running for a few weeks now, tracking live PMU odds and flagging steamers/drifters as money moves the market. It found a real paying user early on, which made me nervous about touching it — the classic "don't fix what isn't broken" problem.

But a user having a working tool doesn't mean the tool can't get more useful without breaking what already works. Here's what I did.

The realization

The actor calls one PMU endpoint per race to get live odds. I was only reading a handful of fields off each participant: name, number, jockey, odds. Out of curiosity I dumped the full raw response for one horse, and it turned out I'd been ignoring most of the payload the whole time — career starts, wins, places, this-year vs last-year earnings, whether the jockey changed for today's race, whether this is the horse's debut. All of it was already coming back on every single call I was already making. Zero extra requests.

Turning raw fields into something worth reading

Raw numbers aren't a feature. "12 starts, 0 wins" only means something if 12 is enough starts for that to be a real pattern and not noise. I picked a minimum sample size (10+ starts) before flagging a winless streak, and a minimum swing (50%+) before flagging a year-over-year earnings change, specifically to keep the signal-to-noise ratio honest.

The bug that would have shipped wrong

While testing against live races, the earnings numbers looked absurd — a modest PMU trotter apparently earning several million euros a year. Turns out PMU returns these amounts in centimes, not euros. A silent off-by-100 that would have made every earnings message wrong, caught only because I ran it against real live data instead of trusting the field name.

Lesson I keep re-learning: field names lie, or at least don't tell you the unit. Test against production data before you ship.

Not touching what works

The new patterns live behind one boolean input, off by default. The existing paying user sees zero change unless they opt in. Old tests still pass unmodified — I added new ones for the new behavior, didn't touch the old ones.

If you're sitting on a scraper or API integration that's "done," it might be worth checking what you're actually parsing out of the response versus what's available in it. Sometimes the next feature isn't a new source — it's a field you never read.

Actor: apify.com/0xgollum/horse-racing-pulse

I scraped live betting odds from 9 countries and never once hit a real anti-bot wall

0xGollum — Mon, 20 Jul 2026 14:28:45 +0000

I just shipped a horse-racing odds tracker across 9 countries. Four totally different site architectures, zero paid proxies, zero headless browsers, zero CAPTCHAs solved. Every "protected" data source I hit turned out to be a public API hiding in plain sight. Here's what actually worked.

1. Curl before you Playwright

The instinct when you see a modern-looking racing site is to reach for a headless browser. Don't. First move is always a plain curl with a real User-Agent and a look at how much of the page is actual text vs markup:

import re
text = re.sub('<[^>]+>', ' ', html)
print(len(text), '/', len(html))

A high ratio usually means server-side rendering — the data's already in the HTML, a JS engine was never going to be necessary. This alone ruled out headless browsers for 3 of the 4 sources I ended up using.

2. Official public APIs are more common than you'd think

One source runs on a pari-mutuel model, and it turns out the operator ships a fully public, key-less JSON API for its own web/app clients — no login, no proxy, nothing. If a market has a state-run or monopoly tote operator, check whether their own site calls a JSON backend before assuming you need to scrape HTML at all.

3. Read the NEXT_DATA / JSON-LD blob before you write a single CSS selector

Two of my four sources are Next.js apps. Both ship the entire page's data as a JSON blob in a <script> tag — __NEXT_DATA__ on one, schema.org SportsEvent JSON-LD on the other. No DOM parsing needed for the core fields; just find the tag and json.loads() it.

Gotcha: if the JSON has nested objects, don't reach for a regex like \{.*?\} to extract it — non-greedy matching stops at the first inner }, not the real end. I burned twenty minutes on this exact bug before switching to a proper brace-counting extractor:

def extract_json_object(text, start):
    depth = 0
    for i in range(start, len(text)):
        if text[i] == '{':
            depth += 1
        elif text[i] == '}':
            depth -= 1
            if depth == 0:
                return text[start:i + 1]

4. Client-side config files sometimes ship real API keys

The most surprising find: one source is a GraphQL app, and the frontend's own JS config file contained a working AWS AppSync API key — meant for the public site to call directly. Introspection was even enabled, so I could enumerate the whole schema and find the exact query I needed (turned out to be getRaceForm, not the more obvious-looking getOdds, which silently returned nothing for reasons I never fully nailed down).

Lesson: view-source a site's own JS bundles before assuming an API is closed. If the frontend can call it with a static key, so can you.

5. Country/region filters on aggregator sites can lie to you

One aggregator site shows "next races" for a country page even when nothing's actually happening in that country right now — it silently falls back to showing whatever's soonest site-wide. First pass of my scraper mislabeled tracks from one country as belonging to another because of this. Fix was trivial once caught (cross-check against the actual structured-data field for country) but the failure mode was quiet — no error, just wrong data. Worth an explicit assertion for any "listing page defaults to something unexpected" pattern.

Built as a new Apify actor, World Turf Pulse — tracks steamer/drifter odds movement across nine countries. Happy to answer questions on any of the four scraping approaches above.

What breaks when you scrape Steam Community Market at scale

0xGollum — Mon, 20 Jul 2026 08:38:22 +0000

CS2 Skin Pulse tracks price and volume signals on CS2 skins from the Steam Community Market. No official API, no key required — but the public JSON endpoints behind it were built for a browser making occasional requests, not a cloud worker hitting them on a schedule. Here's what actually broke, and what fixed it.

1. Datacenter IPs get rate-limited hard

Steam doesn't just slow you down. On Apify's shared IP ranges, priceoverview starts returning 429s on nearly every request, even at low volume — direct requests basically never succeed from there. The fix is routing through Apify's residential proxy, which resolves as normal consumer traffic instead of a flagged datacenter block. On top of that, requests are throttled deliberately (a semaphore capped at 4 concurrent calls, ~350ms sleep between price fetches) instead of relying on the proxy alone to absorb the load.

2. There's no historical price endpoint if you're not logged in

Steam has a pricehistory endpoint, but it requires an authenticated session — not viable for a public actor. So instead of asking "what's the trend," the actor asks "what changed since last time": every run persists each item's price and volume to a named key-value store, then diffs against the previous run to compute price_spike / price_drop / volume_spike signals. Same pattern already used in Bitcoin Pulse for funding-rate history — once you build a "diff against last run" primitive, it works for any source that has no history API at all.

3. Retry logic has to know the difference between "try again" and "give up"

429/500/502/503/504 get retried with backoff. A 403 is a hard block — hammering the same IP again wastes the run's time budget for nothing. And when even priceoverview (rate-limited harder than plain item search) comes back empty after retries, there's a fallback to a lighter search/render call that still returns a current sell price. No median, no volume, but enough to keep the signal alive instead of silently dropping the item for that run.

None of this is specific to CS2 skins — it's the shape of any public JSON endpoint sitting behind a site built for a browser, not a script. Source's public on the Apify Store if you want to see the actual code: https://apify.com/0xgollum/cs2-skin-pulse

What it actually takes to turn a Python scraper into a real Apify actor

0xGollum — Thu, 16 Jul 2026 19:02:50 +0000

A scraper that works on your machine and an actor that survives in production are two different things. I found this out the hard way shipping ten of them on the Apify Store. Here's what actually breaks, and what fixes it.

Pinned dependencies, or the build silently breaks

Crawlee and Apify's SDK move fast enough that an unpinned apify or pydantic version can break the import at build time, with an error message that points nowhere useful. The fix is boring: pin everything (apify==2.7.3, pydantic==2.10.6, browserforge==1.2.3, httpx==0.27.0), and build on Python 3.11, not whatever your local machine runs. I lost an afternoon to this before pinning became a habit.

The default key-value store does not persist

If your actor needs to remember anything between runs, deduplicated items, a rolling window for trend detection, whatever, the default KV store gets wiped every run. You need Actor.open_key_value_store(name="something-persistent") explicitly. Easy to miss once, annoying to debug when your "new item" detector fires on the same item every single run.

Bare except blocks hide the real failure

Early on, a source going down looked identical to a source returning zero results: both produced an empty dataset, silently. The only fix is boring discipline: log the HTTP status on every request, and retry on 429/5xx with backoff instead of swallowing the exception. Once I added this everywhere, actors that used to fail invisibly started failing loudly and correctly, which sounds worse but is much better.

Datacenter IPs get blocked even when residential IPs don't

One actor scraping a big marketplace worked fine from my laptop and returned 429 on every single request from Apify's cloud IP range, on two different endpoints. Not a bug in the code, a block on the IP class. The fix was routing through Apify's own residential proxy (Actor.create_proxy_configuration()), which resolved it completely. If a scraper mysteriously works locally and dies in the cloud, check the IP class before you touch the code.

Sometimes the obvious source blocks you outright

I built an actor around Yahoo Finance's options data, then discovered its crumb-authentication endpoint flatly rejects datacenter IPs, no workaround, no proxy fix. The move was pivoting to a different public source entirely (CBOE's delayed-quotes endpoint, no auth required) rather than fighting a wall that wasn't going to move. Delayed data that actually loads beats real-time data that never does.

Resource defaults quietly eat your margin

Apify actors default to fairly generous RAM and timeout settings. On a pay-per-result actor, that default can mean you're burning more in compute than you're earning per run, silently, for weeks. Tuning RAM down (in one case from 4096MB to 512MB) cut the cost per run by 4-8x and turned a marginal actor profitable without changing a line of scraping logic. Worth checking before you assume a niche "doesn't work."

Every input field needs a description, or the build fails

Small one, but it costs real time the first time you hit it: Apify's input schema validation requires a description on every property. Skip one and the build fails with a message that doesn't always point at which field.

None of this is exotic. It's the difference between "I wrote a script that scrapes a thing" and "I shipped something that keeps working when the site changes, the IP gets flagged, or the traffic spikes." That gap is most of what people are actually paying for when they hire someone to build a scraper instead of writing one themselves.

If you'd rather not deal with any of the above yourself, I take on custom Apify actor builds. My existing actors are live on the Apify Store, not just a portfolio of screenshots: check my profile. Custom build requests go through my Fiverr gig.

How I verify B2B emails without sending a single message

0xGollum — Wed, 15 Jul 2026 13:13:00 +0000

Most "verified" B2B lead lists still bounce on the first send. Here is the actual technique behind a real deliverability check — without ever sending an email — and why honest confidence labels beat a fake "100% verified" badge.

The core trick: talk to the mail server, then hang up

Every domain that receives email publishes MX records. To check whether a mailbox exists, you:

Resolve the domain's MX hosts (DNS).
Open an SMTP connection to the top MX host on port 25.
Walk the handshake: HELO -> MAIL FROM -> RCPT TO for the target address.
Read the server's response code to RCPT TO, then QUIT before DATA.

You never send a message. You just ask "would you accept mail for this mailbox?" and listen — the same no-send probe the commercial verifiers use.

with smtplib.SMTP(timeout=6) as smtp:
    smtp.connect(mx_host, 25)
    smtp.helo("checker.local")
    smtp.mail("probe@checker.local")    code, _ = smtp.rcpt(address)   # the answer lives here
    smtp.quit()                    # QUIT before DATA: nothing is sent

Why "valid" is never fully ironclad

Catch-all domains accept every local part, so a 250 on RCPT TO does not prove that exact mailbox exists. Detect it by probing a random bogus address on the same domain — if that is accepted too, it is catch-all.
Gmail / Outlook / M365 often return an ambiguous accept up front and only reject at final delivery. "The server did not reject it" is not "guaranteed deliverable."
Greylisting returns a temporary 4xx — not a no, just "try again later."

The honest move: tiers, not a badge

Instead of stamping everything "100% verified," label each address by how confident the check really is:

valid — MX exists, RCPT accepted, not catch-all
catch_all — accepts anything, cannot confirm this exact mailbox
published — the address is published on the company's own website (a real human contact) even when SMTP stays inconclusive
unknown — the server blocked or greylisted the probe

A buyer who sees the label knows exactly what they are getting. That honesty outperforms an inflated number that bounces.

One speed lesson

If a domain's mail server never answers the probe at all, do not retry five guessed patterns against it — each one eats a full timeout for nothing. Detect "unreachable domain" once and bail. That single change cut a run from minutes to seconds on niches whose mail hosts refuse port-25 probes.

I build data and automation tools, and I just opened a Fiverr gig doing exactly this — verified B2B lead lists with honest confidence labels, filtered by industry and location. If dead-inbox lists annoy you as much as they annoy me: it is right here.

I shipped 10 paid data scrapers in one week: what actually worked (and what quietly lost money)

0xGollum — Sun, 12 Jul 2026 18:27:27 +0000

A week ago I had zero products. Today I have 10 paid scrapers ("actors") live on the Apify Store, all pay-per-result. Total revenue so far: modest. Total lessons: enormous. Here are the ones I wish someone had told me on day one.

1. "Zero competitors" is not a green light

My first instinct was to hunt for empty niches. Zero competitors means zero proof: it is not evidence of an untapped market, it is the absence of evidence of any market. A niche actor I studied had 2 users after 7 weeks.

The niche that actually performs for me (crypto funding rate arbitrage) had two established competitors with 20+ paying users each. That was the real signal: money already flows here, and the pie is not locked up.

2. Your platform defaults are eating your margin

This one hurt. On pay-per-event pricing, YOU pay the platform usage of every run out of your earnings. The default memory allocation was 4096 MB. My actors are simple HTTP fetchers that finish in 5 seconds.

One of my actors was literally losing money: $0.0161 platform cost per run vs $0.015 revenue. Negative margin on every single sale, invisible unless you check run stats via the API.

Dropping memory from 4096 MB to 512 MB cut per-run cost by a factor of 4 to 8. One API call. Biggest ROI of the whole week.

3. Sources will block you, and your datacenter IP is the problem

What works from your laptop will not necessarily work from a cloud IP:

Binance geo-blocks datacenter IPs with HTTP 451. OKX serves them fine. Same data.
Steam rate-limits its price endpoint so hard from cloud IPs that every request 429s. Fix: route through a proxy and keep a fallback endpoint.
Yahoo Finance blocks its crumb endpoint from datacenter ranges. CBOE serves the same options data with no auth at all.

The lesson: pick your data source for its reachability from cloud infra, not just for its data quality. Always have a plan B endpoint.

4. Silent failure handling is a trap you set for yourself

Every fetch helper I wrote originally swallowed exceptions and returned None. Clean, defensive, and completely blind. When a source started failing, my actor shipped empty datasets with a green SUCCEEDED status. A paying customer gets zero rows and you get zero idea why.

Now every helper retries on 429/5xx with backoff and logs the status code on final failure. The first day this was live, the logs immediately told me exactly which source was blocking which endpoint. Debugging went from "rerun and guess" to "read one log line".

5. Never ship an empty dataset

If your scraper found no signals today, that is information. Push a baseline snapshot row, or a top-N fallback, anything structured. Empty datasets get your actor flagged as "under maintenance" and kill buyer trust. A customer who pays for 5 rows of "nothing unusual today, here is the current state" is happier than one who pays for nothing.

What the portfolio looks like

10 actors, all pay-per-result ($0.002 to $0.005): funding rate arbitrage across 4 exchanges, a Bitcoin market pulse score, new-token momentum with anti-rug filters, news trend acceleration, odds movement for soccer and horse racing, CS2 skin prices, prediction market comparison (Polymarket vs Kalshi), unusual options activity from CBOE, and an address-history lookup.

All of them: https://apify.com/0xgollum

Happy to answer questions about any of this, especially the pricing/margin math, which nobody seems to write about.