DEV Community: Cristian Lungu

Check if a crypto is about to get rekt — in 3 lines of Python

Cristian Lungu — Tue, 18 Aug 2026 11:05:45 +0000

By the time a hack, depeg, or exchange delisting shows up in your Twitter feed, the price has already moved. That's especially brutal for trading bots, which happily buy the dip straight into a coin that's actively on fire.

I got tired of finding out after the candle, so I built a small API that answers one question in a single request:

"Is this coin dangerous right now — and can you prove it?"

It's free to start, and the demo endpoint below needs no key. Copy, paste, run.

The 30-second check

import requests

r = requests.get("https://crypto-intel-api-rulu.onrender.com/risk",
                 params={"symbol": "BTC"})
print(r.json())

Live response (your numbers will differ — this is real-time data):

{
  "symbol": "BTC",
  "risk_score": 60,
  "chg_24h": 0.88,
  "funding": 4.9e-05,
  "danger_event": {
    "event": "breach",
    "verified": true,
    "confidence": 1.0,
    "source_count": 3,
    "sources": ["BitcoinMagazine", "CryptoSlate", "Decrypt"],
    "headline": "SafePal Bitcoin Wallet Data Breach Stokes Fears of Physical Attacks"
  },
  "global_risk": "NORMAL"
}

That's the whole point: a risk_score from 0–100, plus the actual event driving it, with the headline and the sources so you can verify it yourself. No black box.

Why the score is trustworthy

Most "crypto sentiment" APIs will happily flag a coin because one no-name blog used the word hack. This one only marks a danger event as verified: true when at least two independent sources report it. One rumor isn't an event.

Per-coin, not global — risk_score is specific to the symbol you asked about, not a market-wide mood ring.
Cross-verified — source_count >= 2 before anything is "confirmed", so you don't get faked out by a single clickbait headline.
It tells you *why* — event (breach / depeg / delist / legal), plus the headline and sources.

A clean coin just comes back quiet:

{ "symbol": "PEPE", "risk_score": 0, "danger_event": null, "global_risk": "NORMAL" }

Drop it into your bot as a pre-trade gate

Here's the part that actually saves money — a safety gate you call before opening a position:

import requests

def is_safe_to_trade(symbol, max_risk=50):
    """Return (ok, reason). Blocks trades on verified danger events."""
    data = requests.get(
        "https://crypto-intel-api-rulu.onrender.com/risk",
        params={"symbol": symbol}, timeout=15,
    ).json()

    ev = data.get("danger_event")
    if ev and ev.get("verified"):
        return False, f"{ev['event']}: {ev['headline']}"
    if data.get("risk_score", 0) >= max_risk:
        return False, f"risk_score {data['risk_score']} >= {max_risk}"
    return True, "clear"

ok, reason = is_safe_to_trade("BTC")
if not ok:
    print(f"⛔ Skipping trade — {reason}")
else:
    print("✅ Clear to trade")

Three outcomes, no guesswork: a verified breach/depeg/delist/legal event blocks the trade, a high score blocks the trade, everything else is clear.

Bonus: what did the Fed / SEC / Treasury just say?

Regulatory headlines move this market more than any indicator. One call gives you the official ones, tagged bullish/bearish:

r = requests.get("https://crypto-intel-api-rulu.onrender.com/us-movers")
for e in r.json()["events"][:5]:
    flag = "🏛️ official" if e["official"] else "press"
    print(f"[{e['lean_text']:>7}] {flag} — {e['headline']}")

[neutral] 🏛️ official — Federal Reserve issues FOMC statement
[bullish]   press — U.S. Treasury Department proposes GENIUS Act stablecoin rule
[neutral] 🏛️ official — SEC, CFTC Seek Public Comment on Derivatives Product Definitions

Sources are the real Fed / SEC / Treasury / CFTC feeds — not someone's newsletter.

Try it

Live demo (no key): https://crypto-intel-api-rulu.onrender.com/docs
Get it for your app (free tier + API key, 14 endpoints, per-coin risk, US market-movers, whale txns, funding, Fear & Greed): Crypto Intel on RapidAPI

The free tier is enough to wire the safety gate above into a real bot. If it saves you one bad entry, it's paid for itself. Feedback welcome — I'm still adding endpoints.

The input most MT4/MT5 trading bots get wrong: position size

Cristian Lungu — Tue, 18 Aug 2026 07:35:06 +0000

Ask someone why their trading bot blew up and they'll tell you about the strategy. The real answer is usually more boring: the position size was wrong, so a normal losing streak turned into a dead account.

Most EAs I'm asked to fix hardcode the lot size — lots = 0.10, forever. That's the bug. Here's why it kills accounts, and the handful of lines that fix it. It's MT4/MT5 here, but the logic is the same anywhere you place orders in code.

Why a fixed lot quietly kills an account

Two reasons.

Your risk swings with volatility. A 0.10-lot trade with a 15-pip stop and a 0.10-lot trade with a 150-pip stop are not the same trade — one risks 10x the other. With a fixed lot, your real risk per trade is whatever the market's volatility happens to be that day. You're not choosing your risk; the market is choosing it for you.

Losses compound against a fixed base. A hardcoded lot is sized off your starting balance. After a drawdown you're still betting the same absolute size on a smaller account, so your percentage risk climbs exactly when you can least afford it. That's the math that turns a rough week into a blown account.

The fix: choose the risk, derive the lot from the stop

Flip it around. You don't choose the lot — you choose the risk (say 1% of balance), and the lot falls out of the stop distance:

money at risk = balance x 1%
loss-if-stopped, per 1.0 lot = stop distance x tick value
lot = money at risk / loss-per-lot (then snap to the broker's volume step)

Now every trade risks the same 1%, whether the stop is 15 pips or 150. The size shrinks automatically when the stop is wide or the account is smaller. Nothing about the strategy changed — only the thing that decides whether you're still here next month.

Pair it with an ATR-based stop (stop = a multiple of Average True Range) and the whole system breathes with volatility: wider stops in fast markets, smaller lots to match, constant risk throughout.

Does the discipline actually show up in the numbers?

I put exactly this — trend filter, pullback entry, ATR stop, 1% risk-based sizing — into a sample EA and ran it through the MT5 Strategy Tester on a year of XAUUSD H1 data:

Return: +33.7%
Profit factor: 1.45
Max drawdown: 8.0%
114 trades, ~44% win rate at 2:1 reward-to-risk

The number that matters there isn't the return — it's the 8% drawdown. That's what risk-based sizing buys you: the account bends instead of breaking, so you're still around when the winners show up. Note the win rate is only ~44%; it's profitable purely because the size and the reward-to-risk are disciplined. Fixed lots would have made the same strategy a much rougher ride.

You can see the sample EA, its adjustable parameters and the equity curve here:
https://darling-kataifi-559215.netlify.app

The takeaway

Spend your time on the strategy — but the line that decides whether you survive long enough for the strategy to matter is the one that sizes the trade. If your EA has lots = 0.10 hardcoded anywhere, that's the first place I'd look.

I build and fix MT4/MT5 EAs and other execution software at Quiet Machines — risk-based sizing, clean stops, backtests you can actually read. If your bot's risk feels like a guess rather than a number you chose, that's the work I do.

— Cristian Lungu · https://contra.com/lungu_cristian_d7nm4wbh

Most trading bots break in the same four places — and none of them are the strategy

Cristian Lungu — Tue, 18 Aug 2026 07:23:20 +0000

Everyone building a trading bot pours their energy into the strategy. The entry logic, the indicators, the pretty backtest curve. Then they wire it to a live broker API and it quietly falls apart — not because the strategy was wrong, but because the layer underneath it lied about what actually happened in the market.

I've spent more time on that layer than on any strategy, so here are the four places it breaks, and how I stop it from breaking. Examples are on the Interactive Brokers API, but the failure modes are the same on any broker.

The four ways it goes wrong

1. The duplicate callback. The API sends you the same execution twice. Naive code adds the fill twice, and now your bot thinks it owns 200 shares when it owns 100.

2. The reconnect replay. Your socket drops for four seconds. On reconnect, the broker helpfully replays recent fills. If you treat them as new, you double-count everything that happened around the disconnect — which is exactly when you can least afford to be wrong about your position.

3. The out-of-order partial fill. A large order fills in pieces. The messages don't always arrive in order. If you just overwrite state with the latest message, a late-arriving early fill can rewind your average price or your filled quantity.

4. The stale status that rewinds a finished order. You get a Filled. Then, a beat later, a delayed Submitted for the same order shows up. Trust it and you've just un-filled a completed trade in your own books.

Notice what none of these do: crash. No exception, no stack trace, no red text. They silently corrupt state — phantom positions, double orders, wrong P&L — and you find out when real money is already on the wrong side. That's what makes them the expensive kind of bug.

The fix is boring on purpose

You don't beat these with clever code. You beat them with a few strict rules and a design that lets you prove they hold.

Make executions idempotent. Every fill has a unique id (execId on IB). Key on it. If you've seen it, it's a no-op. Replays and duplicates just do nothing.

Take truth from executions, not from status. Filled quantity is the sum of real executions you've actually seen — never a number you trust blindly from a single orderStatus. And state only moves forward: once an order is terminal, no late message drags it backward.

Aggregate partial fills properly. Accumulate the pieces and carry a quantity-weighted average price, so order matters less and a late fragment can't distort your basis.

Reconcile — don't overwrite. Periodically pull the broker's own open-orders and positions snapshot and compare it to your local truth. If they disagree, report the drift. Don't silently overwrite one with the other — the disagreement is the signal, and hiding it is how small errors become big ones.

Keep the fragile logic pure. The part that does dedup, aggregation and reconciliation has no broker I/O in it at all. That's deliberate: it means you can run the nasty scenarios deterministically in CI instead of hoping they behave on a live line.

Proof, not vibes

I put all of this in a small, tested engine. The offline suite fires every failure mode above at it and asserts the state stays sane — 8/8 checks passing: duplicate execution ignored, reconnect replay idempotent, partial fills aggregated to a quantity-weighted average, stale and stray statuses rejected, and reconciliation flagging any order/position drift.

Then I ran it against a live IBKR paper account over the TWS API — strictly read-only, it observes and reconciles, it never places orders. I placed a market order by hand in TWS and let the engine reconstruct the truth on its own: it tracked every transition (Submitted then Filled), summed the fill, derived the position, and matched the broker's own snapshot exactly — reconciliation clean.

The point

A strategy decides what to do. The execution layer decides whether what you think happened matches what actually happened. Get the second part wrong and the first part doesn't matter — you're trading on a fiction.

The whole thing is open. Read it instead of taking my word for it:
https://github.com/lungucristian1980-hub/ibkr-order-state-engine

I build execution reliability like this for a living — reconnect-safe order handling, kill-switches, reconciliation, clean handovers — at Quiet Machines. If your bot does something it shouldn't when the connection drops, that's the work I do. You bring the strategy; I make sure the plumbing tells the truth.

— Cristian Lungu · https://contra.com/lungu_cristian_d7nm4wbh

I built an insider-conviction screener for my watchlist in ~40 lines of Python (SEC Form 4)

Cristian Lungu — Mon, 03 Aug 2026 09:17:57 +0000

Corporate insiders — CEOs, CFOs, directors — have to report every time they buy or sell their own company's stock on SEC Form 4, within two business days. Insider buying on the open market is one of the few market signals that's both public and hard to fake: people rarely put their own cash into their own stock unless they mean it.

The problem: Form 4 is filed as XML, thousands of times a week. Reading it by hand is hopeless, and parsing the XML yourself is a weekend gone.

So I built a small screener that ranks my watchlist by insider conviction. Here's the whole thing.

Disclosure: I use my own API for this (SEC Intel). The Form 4 parsing + scoring is the tedious part it removes; the screener logic below is yours to keep.

The idea

For each ticker on my watchlist, pull the parsed Form 4 summary.
Read the insider-conviction score (0–100) — it weighs how many insiders bought, whether the C-suite is involved, and buys vs. sells.
Rank so the real buying floats to the top.

The code

import requests

HOST = "sec-intel-filings-financials-insider-trades.p.rapidapi.com"
HEADERS = {"X-RapidAPI-Key": "YOUR_KEY", "X-RapidAPI-Host": HOST}

WATCHLIST = ["NVDA", "AAPL", "MSFT", "TSLA", "AMD", "META", "AMZN", "XOM"]

def get(path, **params):
    r = requests.get(f"https://{HOST}{path}", params=params, headers=HEADERS, timeout=30)
    r.raise_for_status()
    return r.json()

rows = []
for ticker in WATCHLIST:
    summary = get("/insider", query=ticker)["summary"]
    rows.append((summary["conviction_score"], summary["signal"], ticker, summary["net_usd"]))

# rank: strongest insider conviction first
for score, signal, ticker, net in sorted(rows, reverse=True):
    print(f"{ticker:6} conviction {score:>3}  {signal:8}  net ${net:,.0f}")

Live output when I ran it:

TSLA   conviction  70  bullish   net $879,654,993
XOM    conviction   0  neutral   net $0
AAPL   conviction   0  bearish   net $-111,739,341
MSFT   conviction   0  bearish   net $-2,843,905
META   conviction   0  bearish   net $-10,063,533
AMZN   conviction   0  bearish   net $-51,643,529
AMD    conviction   0  bearish   net $-167,076,160
NVDA   conviction   0  bearish   net $-410,446,401

One insider put ~$880M into TSLA on the open market while the rest of mega-cap tech shows insiders selling. That's the whole point: the buy is the rare signal, and it floats straight to the top. No XML, no CIK lookups, no Form 4 field decoding.

Make it an alert

Wrap it in a loop and ping yourself when conviction crosses your threshold — Slack, Telegram, email, whatever:

def scan_and_alert(threshold=50):
    for ticker in WATCHLIST:
        s = get("/insider", query=ticker)["summary"]
        if s["conviction_score"] >= threshold:
            notify(f"Insider buying: {ticker} ({s['conviction_score']}/100, {s['signal']})")

Bonus: want the whole market instead of a watchlist? GET /insider-signals returns the newest open-market insider buys across all filers (Form 4 code P), sorted by size.

Feed it to an agent instead

The same JSON drops straight into a prompt or a tool call — or connect the API as an MCP server (Claude Desktop, Cursor, VS Code) and just ask "any strong insider buying on my watchlist today?". The data comes back structured, so the model doesn't guess.

Notes on using this responsibly

Insider buying is a signal, not a crystal ball — people buy for many reasons, and this isn't investment advice. But as a filter to surface where informed people put their own money, a conviction-ranked screen beats scrolling filings by hand.

Try it

Free tier (1,000 calls/mo, no card): SEC Intel API on RapidAPI
Try every endpoint in the browser: live docs
More on the API: secintelapi.netlify.app

What would you screen for? Drop your watchlist + threshold in the comments.

Give your AI agent real SEC data (financials + insider signals) in 5 minutes

Cristian Lungu — Fri, 31 Jul 2026 11:35:06 +0000

Ask an LLM "What was Apple's revenue last quarter?" or "Are insiders buying NVIDIA right now?" and you'll often get a confident, wrong answer. Financial numbers are exactly the kind of thing models hallucinate - and the ground truth (SEC EDGAR) is not something you can just paste into a prompt.

If you've tried, you know the pain:

A single 10-K is megabytes of XBRL and HTML. It blows your context window instantly.
Parsing XBRL by hand is a second job.
Insider trades live in Form 4 XML that nobody enjoys scraping.

So your agent needs structured SEC data, not raw filings. Here's how to wire that up in about five minutes.

What we'll build

An agent tool that, given a ticker, returns clean JSON: company profile, XBRL financials (revenue, net income, EPS), recent filings, and parsed insider trades with a 0-100 conviction score. Then we'll hand that JSON to an LLM and ask it a real question.

We'll use the SEC Intel API - it wraps official SEC EDGAR data (US public domain) and returns exactly the shape an LLM can reason over. There's a free tier, no credit card.

Disclosure: I built this API. But the technique below works with any structured-data source - the point is don't feed raw filings to your model.

Step 1 - one call, everything

import requests

HOST = "sec-intel-filings-financials-insider-trades.p.rapidapi.com"
HEADERS = {"X-RapidAPI-Key": "YOUR_KEY", "X-RapidAPI-Host": HOST}

def sec_company(query: str) -> dict:
    r = requests.get(
        f"https://{HOST}/company",
        params={"query": query},   # ticker, CIK, or company name
        headers=HEADERS,
        timeout=30,
    )
    r.raise_for_status()
    return r.json()

data = sec_company("AAPL")
print(data["profile"]["name"])          # Apple Inc.
print(data["financials"]["revenue"])    # latest revenue from XBRL

/company bundles profile + financials + insider summary + recent filings in one response, so your agent doesn't have to orchestrate four calls. Want just one slice? There are focused endpoints too: /financials, /filings, /insider, /search, /latest.

(No key yet? You can hit the live interactive docs and try every endpoint in the browser first.)

Step 2 - the part most APIs don't give you: insider conviction

Ten insiders each filed a Form 4 last week. Which company are they actually betting on? Raw filings won't tell you - you'd have to weigh how many insiders bought, whether the CFO/CEO were among them, and how buys compare to sells.

/insider does that math for you and returns a single conviction_score (0-100):

def insider_conviction(query: str) -> dict:
    r = requests.get(
        f"https://{HOST}/insider",
        params={"query": query},
        headers=HEADERS, timeout=30,
    )
    r.raise_for_status()
    return r.json()

nvda = insider_conviction("NVDA")
print(nvda["conviction_score"], nvda.get("signal"))
# e.g. 82 strong_accumulation

Now your agent reads intent, not XML.

Step 3 - hand it to the model

The whole point: put clean JSON in the context, then let the LLM reason. Here's the pattern with Claude (works the same with the OpenAI SDK):

import anthropic, json

client = anthropic.Anthropic()  # ANTHROPIC_API_KEY in env

facts = sec_company("NVDA") | {"insider": insider_conviction("NVDA")}

msg = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=400,
    messages=[{
        "role": "user",
        "content": (
            "Using ONLY this SEC data, summarize NVIDIA's latest "
            "fundamentals and whether insiders are accumulating.\n\n"
            + json.dumps(facts, indent=2)
        ),
    }],
)
print(msg.content[0].text)

Because the model is grounded in real, structured numbers, it stops guessing. This is the same idea as RAG - just with a financial data source instead of a vector DB.

Turn it into a tool the agent can call itself

If you're using function/tool calling, expose it as a tool and let the agent decide when to pull data:

tools = [{
    "name": "get_sec_company",
    "description": "Get SEC financials + insider conviction for a ticker.",
    "input_schema": {
        "type": "object",
        "properties": {"ticker": {"type": "string"}},
        "required": ["ticker"],
    },
}]
# when the model calls it, run sec_company(ticker) and return the JSON

Why not just parse EDGAR yourself?

You can - EDGAR is free and public domain. But you'll spend your week on XBRL taxonomies, Form 4 XML quirks, CIK/ticker resolution, and rate-limit etiquette before you write a line of agent logic. A structured wrapper turns all of that into one HTTP call, and the data stays resale-safe because it's public domain.

Try it

Free tier (1,000 calls/mo, no card): SEC Intel API on RapidAPI
Poke the endpoints in your browser: live docs

If you build something with it - an earnings summarizer, an insider-buying screener, a due-diligence agent - I'd love to hear about it in the comments. What SEC data would make your agent smarter?

Stop trading on fake crypto signals: a free API with cross-verified danger scores + Fed/Trump tracking

Cristian Lungu — Wed, 29 Jul 2026 14:12:10 +0000

If you build trading bots or dashboards, two failure modes are expensive.

The problem

Fake danger signals — a single tweet or low-quality feed claims a hack or depeg, your bot reacts, and it wasn't true.
Blind spots on macro and regulation — a Fed decision or an SEC action moves the market and your news pipeline is late.

Most crypto APIs give you one global sentiment number and call it a day. I wanted something that (a) refuses to report an event unless multiple independent sources agree, and (b) watches the people and institutions that actually move crypto.

What Crypto Intel API does

Per-coin DANGER score (0-100). Hacks, exploits, depegs, delistings and lawsuits are only reported when 2+ independent sources confirm them. Each event ships with a confidence and the source list.
US market-movers feed. Real-time signals from the official Fed / SEC / Treasury / CFTC feeds plus Trump, each tagged bullish/bearish for crypto.
Per-coin sentiment, Fear & Greed, whale transactions, prices and keyword news search — from 60+ sources.

Try it (free tier)

Per-coin risk and the confirmed event behind it:

curl "https://crypto-intel-api-rulu.onrender.com/risk?symbol=BTC"

{
  "symbol": "BTC",
  "risk_score": 45,
  "chg_24h": 1.26,
  "danger_event": {
    "event": "legal", "confidence": 0.75, "verified": true,
    "sources": ["CoinDesk", "Decrypt"], "source_count": 2
  },
  "global_risk": "NORMAL"
}

What the Fed / SEC / Treasury / Trump are doing to crypto right now:

curl "https://crypto-intel-api-rulu.onrender.com/us-movers"

How the cross-verification works

Each source has a trust weight. For a coin, the engine collects danger-keyword hits across all sources, counts the distinct sources, and marks an event verified only when at least 2 independent sources agree — with a confidence derived from how many sources and how trusted they are. That single rule is what keeps rumors out.

Where to get it

Free plan on RapidAPI — grab a key and you're calling it in a minute:

https://rapidapi.com/lungucristian1980/api/crypto-intel

Feedback welcome, especially on the risk model.