DEV Community: DatanestDigital

Data Contracts: Taming Schema Drift Before It Breaks Prod

DatanestDigital — Sat, 26 Sep 2026 12:42:06 +0000

The most expensive bugs in data engineering are the ones that don't error. A column gets renamed, a type gets widened, a null starts showing up where the business said "never null" — and for weeks, nothing crashes. The dashboard just quietly drifts. Then one Tuesday, the report is missing a month, and suddenly a "small schema change" from April is your incident.

That's schema drift, and it's the difference between pipelines that feel stable and ones that feel haunted.

What a data contract actually is

A data contract is the API contract idea applied to data. When you change a REST endpoint you version it, document it, and give consumers a migration path. Data rarely gets that courtesy — producers change tables and consumers find out in prod.

A contract makes the producer's promise explicit. The useful ones carry four things:

Field	What it answers
Schema	What fields exist, their types, nullability, allowed values
Quality rules	Completeness, uniqueness, range checks, accepted values
Freshness / SLA	How often data updates and by when
Ownership	Who produces, who consumes, who gets paged

The point isn't the document. It's that a change to the data now has a reviewable surface instead of being an invisible commit.

Schema evolution vs breaking changes

The core skill is telling safe changes from breaking ones. A pragmatic, semver-flavored split:

Category	Example	Verdict
Additive	New nullable column	Usually safe (minor)
Additive	New optional field in JSON	Usually safe (minor)
Widening	INT → BIGINT	Safe if consumers handle it
Breaking	Rename or drop a column	Breaking (major)
Breaking	Type change, tighter nullability	Breaking (major)
Breaking	Reorder columns for positional reads	Breaking (major)

The subtle one: Spark, Delta Lake, and most modern engines read by name, not position. Renaming a column doesn't fail — the old name just resolves to nothing, so consumers get NULLs instead of errors. A broken contract that fails loudly in CI is a gift; the same break discovered by a dashboard is a fire.

Versioning contracts

Put a version on the contract and treat it like an API version. Bump the minor for additive changes, the major for breaking ones. Consumers pin to a major version, and a major bump becomes a coordinated, visible event — not a surprise in the morning batch.

Versioning buys you the most important thing: a conversation. "We're moving to v3 of orders" beats "why is my report empty?"

Enforce it in CI

A contract nobody checks is a wish. Enforcement belongs in the pipeline's CI, before anything lands in prod. The lightweight shape:

Keep the contract next to the producer code
On each PR, diff the proposed schema against the current contract
Fail the build on breaking changes unless the major version was bumped
Run a sample of real data through the quality rules

A minimal check in Python:

def assert_compatible(old: dict, new: dict) -> None:
    """Fail on breaking changes unless the major version bumps."""
    if new["major"] == old["major"]:
        old_names = {f["name"] for f in old["fields"]}
        for field in new["fields"]:
            if field["name"] not in old_names and not field.get("nullable"):
                raise SystemExit(
                    f"Breaking change: non-nullable '{field['name']}' added "
                    "without a major version bump"
                )
        for field in old["fields"]:
            if field["name"] not in {f["name"] for f in new["fields"]}:
                raise SystemExit(
                    f"Breaking change: field '{field['name']}' removed "
                    "without a major version bump"
                )
    print("contract compatible")

Crude, but the shape is right: small, scriptable, and impossible to skip once it's a CI step.

Producers and consumers

Contracts also fix a social problem. Most teams have no roster of who consumes a table — "I wonder who uses this" is a real production skill. Put the consumer list in the contract, and a schema change becomes a notification instead of an archaeology project. Producers own the contract; consumers get pinged on change; the contract is where the two sides negotiate instead of discovering each other's needs in prod.

Tooling landscape (honestly)

You don't need a vendor to start. The honest landscape:

Quality testing: dbt tests, Great Expectations, Soda — mature, good at row-level checks
Schema/serialization: JSON Schema, Pydantic, Avro — good for validating shapes
Platform-native: Delta Live Tables expectations, Unity Catalog — good if you're on Databricks
Contract platforms: data-contract-spec and managed tools — powerful once you have many teams; overkill at the start

Start with a YAML contract and a CI script. Buy the platform when coordination hurts more than the price.

A lightweight contract you can adopt today

Something you can write before lunch:

dataset: prod.sales.orders
version: 1.2.0
owner: billing-team
schema:
  fields:
    - name: order_id
      type: string
      nullable: false
    - name: total
      type: decimal
      nullable: false
    - name: note
      type: string
      nullable: true
quality:
  - total >= 0
  - order_id is unique
freshness:
  sla_hours: 24
consumers:
  - analytics
  - finance-recon

Check it into the producer repo, wire the diff check into CI, and you've got drift insurance for the cost of a YAML file.

Where to go deeper

If you're on Databricks or Spark, there's ready-made tooling for exactly this. The DataStack Pro store carries a Schema Evolution Toolkit that detects, validates, migrates, and analyzes schema changes across Delta Lake tables automatically, plus a Data Quality Framework with pluggable completeness, accuracy, consistency, and timeliness checks, a Data Pipeline Testing Kit, and PySpark utilities covering schema evolution and lineage. For the heavier end — a full contract implementation with YAML spec, CLI generator, schema validation, SLA monitoring, and breaking-change detection — the Data Contract Framework covers it.

The Data Engineering Bundle puts all 17 DataStack tools in one purchase for $199 instead of $523 separately.

Schema drift is a process problem, not a code problem. A contract, a version, and a CI check turn "who broke the data?" into "here's the change, here's who it affects." That's a much better way to spend a Tuesday.

Browse the DataStack Pro catalog

PySpark Performance Tuning: A Checklist You Can Actually Follow

DatanestDigital — Sat, 26 Sep 2026 12:42:05 +0000

Most slow Spark jobs aren't slow because Spark is slow. The data landed badly, the shuffle is enormous, or the physical plan is doing something expensive nobody asked for. The good news: the usual-suspect list is short, and you can work through it in order.

This is a checklist, not a theory lecture. Every section says what to look at, how to look at it, and when it's worth your time. No fake benchmark tables here — performance claims are deliberate ranges, because your data, cluster, and budget differ. Treat everything as a hypothesis and measure on your own workload.

0. Read the plan before you touch a knob

df.explain("cost") shows the physical plan: which joins Spark picked, where the Exchange nodes (shuffles) are, and what Catalyst decided to do with your query. The Spark UI's SQL tab shows the same thing per stage, with timings and row counts.

If you don't know what Spark is actually doing, every tuning decision is a guess. A SortMergeJoin where you expected a broadcast, or a shuffle between two trivial filters, is the kind of thing the plan shows in ten seconds and profiling takes an hour to find.

1. Partitioning and skew

Two separate problems hide under "partitioning":

Too few or too many shuffle partitions. The default is 200 (spark.sql.shuffle.partitions), which is wrong for almost every job — too many for a small cluster, too few for a big one. A common starting point is 2-4 partitions per executor core, but that's a heuristic, not a law. Measure stage times, then adjust.
Skew. One task runs for 40 minutes while siblings finish in two — obvious in the UI stage view. Skew usually comes from a hot key (a few users, customers, or device IDs owning most rows). Classic fixes: salt the join key with a random suffix, or let AQE handle it on a recent Spark (section 5).

Also check read-side partitioning: spark.sql.files.maxPartitionBytes defaults to 128 MB, but thousands of tiny source files mean thousands of tiny tasks regardless. Fix the source before tuning the knob.

2. Broadcast joins

If one side of a join is small enough, Spark can copy it to every executor and avoid shuffling the big side entirely. The default threshold is 10 MB (spark.sql.autoBroadcastJoinThreshold); the plan shows BroadcastHashJoin when it applies.

You can hint manually: big_df.join(small_df, "key").hint("broadcast"). In practice this is the cheapest win on dimension-style joins — often an order of magnitude faster than the sort-merge equivalent, depending on your data. It can backfire: raise the threshold too high and the driver ships a huge table to every executor. Keep the broadcast side genuinely small.

3. Avoid the shuffle before you optimize it

A shuffle is not just network traffic — it's serialization, disk writes, and a stage boundary that stops pipelining. Cheapest fix: don't create it.

Filter before join. Fewer rows through the shuffle.
Aggregate before join. Fewer rows, same answer, if the aggregate is valid at that point.
coalesce(n) vs repartition(n). Coalesce reduces partitions without a full shuffle (only safe when reducing); repartition always shuffles. Use coalesce on write, repartition only when you genuinely need to rebalance.
reduceByKey over groupByKey. Reduce combines on the map side before anything crosses the network.
Bucketing. For tables joined repeatedly on the same key, pre-bucketing can make joins shuffle-free. Plan it early — it's a schema decision.

4. Cache with intent, not habit

df.cache() is lazy — nothing is cached until the first action forces materialization. It pays off only when the same DataFrame is reused across multiple actions or iterations (training loops, iterative algorithms). If you read it once and move on, caching just adds a serialization round-trip.

When you do cache, use the default MEMORY_AND_DISK and unpersist() when done. Caching "everything, just in case" evicts what you actually need later — Spark's cache is a shared pool competing with shuffle buffers and execution memory.

5. Let AQE do the boring stuff

Adaptive Query Execution has been on by default since Spark 3.2 (on 3.0/3.1 you enable it manually via spark.sql.adaptive.enabled). At runtime AQE can:

coalesce post-shuffle partitions down to something sane,
detect skew and split the hot partitions,
convert a sort-merge join into a broadcast join when stats say the table is actually small.

AQE removes a surprising amount of hand-tuning — especially the "guess the shuffle partition count" game from section 1. Not magic, but the closest thing Spark has to a self-tuning default. Check spark.sql.adaptive.coalescePartitions.enabled and spark.sql.adaptive.skewJoin.enabled before building your own workarounds.

6. Diagnose spills before blaming the cluster

Spill means a task ran out of execution memory and wrote intermediate data to disk. The UI shows it as shuffle spill or storage memory spill. Spill is a symptom, not a disease: too much data per task, too little memory, or a fat shuffle.

Fix in this order: shrink the shuffle (sections 2-3), then tune executor memory and spark.memory.fraction, and only then add nodes. Throwing machines at a spill caused by a fat shuffle pays for a symptom.

7. The small-files problem

Write a batch job with 200 shuffle partitions and you get 200 output files. A streaming job writing per micro-batch adds a new batch of tiny files every few minutes. Over weeks, a table becomes thousands of files that slow every read, file listing, and catalog operation. It compounds — fix it early.

Practical fixes: coalesce() on write for batch jobs, and for Delta Lake, OPTIMIZE with ZORDER BY on the columns you filter by. A reasonable target is files in the 64-256 MB range — but like every number in this post, verify against your own workload.

8. Keep Python out of the hot path

Python UDFs are the classic "one function that makes everything crawl" culprit: each row serializes through PySpark's bridge and breaks Catalyst's whole-stage code generation. Replacing a per-row UDF with built-in SQL expressions or a vectorized pandas UDF routinely moves the needle more than any cluster knob.

Prefer selectExpr, when/otherwise, and built-ins. For genuinely custom logic, use vectorized UDFs so serialization is amortized over batches, not paid per row.

The checklist

Run top to bottom; each step is cheaper than the next:

Read the physical plan. Know your shuffles.
Fix partitioning and skew (2-4 partitions per core as a starting point; salt or AQE for hot keys).
Broadcast the small side of joins.
Eliminate shuffles: filter, aggregate, coalesce, bucket.
Cache only reused DataFrames; unpersist when done.
Confirm AQE is on; let it tune partition counts and skew.
Diagnose spills — shrink the shuffle before buying nodes.
Kill per-row Python UDFs; use vectorized or built-ins.

Where to go deeper

The Data Engineering store at Datanest carries the tools behind this checklist: the Spark Performance Masterclass (25+ optimization patterns for Databricks), plus the Spark ETL Framework, PySpark Utils Library, and Delta Lake Patterns for the pipeline around it. If you want the whole set, the Data Engineering Bundle includes all 17 tools — $523 bought separately, yours for $199 (save $324, 62%).

Browse the Data Engineering store

Apache Airflow DAG Design Patterns That Survive Production

DatanestDigital — Sat, 26 Sep 2026 12:36:26 +0000

Every Airflow DAG works in a tutorial. Production is where they fall apart — and usually not because the code is wrong, but because the design assumed the world would never retry, never flake, and never run 365 missed schedules at once.

This is a practical set of patterns for DAGs that survive contact with production: idempotency, atomic tasks, dynamic task mapping versus dynamic DAGs, backfills, sensors (and their deadlocks), secrets, retries, trigger rules, and testing. No hype, no "10x your pipelines" — just the stuff that stops the 2 a.m. page.

1. Idempotency is the whole game

If a task is not safe to re-run, it is not production-safe. Period. Airflow will re-run tasks — after retries, after manual clears, after a worker dies mid-task. Your DAG must produce the same result no matter how many times it executes.

Concretely: prefer MERGE / INSERT OVERWRITE over INSERT, and partition targets by execution date so a re-run replaces exactly the same slice:

# Good: idempotent partition overwrite
df.write.format("delta").mode("overwrite") \
    .option("replaceWhere", f"date = '{ds}'") \
    .saveAsTable("gold.daily_metrics")

# Bad: append creates duplicates on re-run
df.write.format("delta").mode("append").saveAsTable("gold.daily_metrics")

2. Atomic tasks, small tasks

Each task should do one thing, and its state should be either "not started" or "fully complete" — never partially complete. Write to a staging location and rename on success, use transactions where possible, and write checkpoint files so a retry resumes safely instead of restarting blind.

Then split the monolith. Separate extract / transform / quality / load tasks give you granular retry (only re-run what failed), clear observability (which step is slow?), and parallel execution. The mega-task that does everything is the anti-pattern that turns a one-line failure into a whole-pipeline replay.

3. Nothing at top level

The scheduler parses every DAG file roughly every 30 seconds. Any code outside the DAG context manager or task definitions runs on every parse. A db.execute("SELECT COUNT(*) FROM orders") at module level means one query every 30 seconds forever, and a slow file sensor at import time stalls the whole scheduler.

Put it in a task:

# BAD — this query runs every 30 seconds during scheduling
result = db.execute("SELECT COUNT(*) FROM orders")

# GOOD — query runs only when the task executes
def get_count(**context):
    return db.execute("SELECT COUNT(*) FROM orders").scalar()

4. Backfills are explicit, not accidental

Set catchup=False by default. Forgetting this is the #1 cause of "why did 365 DAG runs just fire at once?" when you deploy a DAG with a start_date in the past.

When you do want history, make backfill a deliberate, parameterized DAG — date-range chunking, parallelism control, progress tracking — instead of relying on catch-up behavior you didn't ask for.

5. XCom is metadata, not a data bus

XCom values live in the metadata database, and most setups have a practical limit around 48 KB per value. Pushing DataFrames or full query results through XCom bloats the DB and slows the UI.

Pass small metadata — file paths, row counts, status strings. For large data, write to object storage (S3, GCS, ADLS) and push only the path. If your team routinely passes large payloads between tasks, look at a custom XCom backend that offloads storage to object storage instead of the DB.

6. Dynamic task mapping, not parse-time generation

Dynamic task mapping (Airflow 2.3+) replaces the old pattern of generating tasks at parse time with runtime-determined parallelism. Map over a list with expand(), pin static args with partial(), and pass dicts with expand_kwargs():

process.partial(date="{{ ds }}", env="production").expand(table=tables)

Cap it: max_map_length in airflow.cfg (default 1024), and monitor mapped task counts — each mapped instance consumes a worker slot, and unbounded .expand() can exhaust the pool.

If you still need DAG factories driven by YAML config, keep them small — under 100 DAGs, because each adds scheduler overhead — and use closures to bind loop variables, or every task gets the last value due to late binding.

7. Sensors: `reschedule`, or you'll deadlock

ExternalTaskSensor is how you wait for another DAG's task. Two rules keep you out of the worst failure modes:

Prefer mode="reschedule" for long waits. mode="poke" holds a worker slot the entire time — pool exhaustion waiting to happen.
Map your cross-DAG dependencies before writing sensors. If DAG A waits for DAG B and DAG B waits for DAG A, both hang forever. That's a deadlock you will not notice until nothing runs.

Also watch schedule mismatch: if DAG A is @hourly and DAG B is @daily, the sensor's execution_delta must account for the difference, or it will wait for a run that doesn't exist.

8. Secrets: connections and variables, not env vars

Use Airflow Connections rather than raw env vars — encrypted at rest, auditable, UI-editable. Keep one connection per environment (aws_prod, aws_staging, aws_dev), and for anything sensitive, store them in a secrets backend like Vault or AWS Secrets Manager rather than the metadata DB where admins can see them.

For variables: Variable.get("environment", default_var="dev") won't crash when missing, and batch them into one JSON variable instead of scattering Variable.get() calls at module level — every one of those is a DB query during DAG parsing.

9. Retries and trigger rules

Set retries per task — @task(retries=3, retry_delay=timedelta(minutes=5)) — and let tasks fail loudly instead of swallowing exceptions. Catching everything "just in case" hides the failure from Airflow's retry and alerting machinery, which is the entire point of the platform.

Trigger rules are the less obvious lever. The default all_success is right for strict pipelines, but fan-in joins often want all_done (run regardless of upstream success/failure, e.g. for cleanup) or none_failed_min_one_success for a branch that tolerates partial failure. A terminal task with trigger_rule="none_failed_min_one_success" is how you get accurate DAG-level status instead of a forever-failed run because one optional branch broke.

10. Test DAGs at four levels

Import test — load with DagBag and assert zero import_errors. Catches syntax errors before deploy.
Structure validation — every DAG has an owner, tags, description, and catchup=False.
Callable unit tests — test your Python functions independently of Airflow.
Integration with dag.test() (Airflow 2.5+) — run an entire DAG in a single process with a fixed execution_date.

This four-level ladder is cheap to maintain and turns "deploy and pray" into "deploy and know."

The patterns above are the same ones that ship in the Airflow DAG Templates pack from DataStack Pro: 14 production-shaped DAGs covering ETL, data quality, ML pipelines, warehouse loading, CDC streaming, database replication, SLA monitoring, and dynamic task mapping — plus custom operators (Spark submit, data quality, Databricks notebook, Delta sensor), an extended S3 sensor, and a 450+ line best-practices guide covering TaskFlow, dynamic mapping, SLAs, and testing. Pair it with the Data Pipeline Testing Kit if you need PySpark unit and integration test scaffolding.

The full DataStack Pro collection covers the rest of the modern data stack: Spark ETL frameworks, Delta Lake patterns, data quality engines, CDC replication, schema evolution, and more.

Machine Payments for AI Agents: x402 + USDC on Base

DatanestDigital — Sat, 26 Sep 2026 12:19:52 +0000

We've wired up the digital storefront so an AI agent can run the whole purchase loop itself: discover a product, receive a payment challenge, pay in USDC on Base mainnet, and get the product delivered — no Stripe session, no facilitator, no human approving the transfer. It's the x402 protocol implemented as a self-custody machine-payment path beside the existing agent commerce layer, and it runs on a Cloudflare Worker that is read-only against the chain.

This post walks the actual implementation: the four-step challenge → pay → verify → deliver flow, then the engineering decisions that make on-chain payments safe without a trusted third party — per-order derived recipient addresses, strict exact-amount verification, a second-RPC cross-check, and fail-closed invariants.

The flow: challenge → pay → verify → deliver

x402 is an HTTP-native payment protocol: a merchant answers a request with 402 Payment Required and a machine-readable challenge, the agent pays, the merchant verifies on-chain, and the agent gets its content. Datanest's implementation lives at GET /api/x402/products/{id} on the agent-MCP Worker.

1. Challenge. The agent requests a product with no proof. The Worker mints a 128-bit secret order id, derives a per-order recipient address, computes the exact price, and durably writes the order — if that write fails, it returns 503 rather than handing out a challenge whose record isn't durable. The response is a 402 with a base64 PAYMENT-REQUIRED header describing the accepted payment (scheme exact-transfer, network eip155:8453, the USDC asset, the exact amount, and the derived payTo address), plus the secret order id in an X402-Order-Id header. The order expires after X402_ORDER_TTL_SECONDS (default 900 seconds).

2. Pay. The agent transfers exactly the price in USDC to that order's payTo address. Because the recipient address is unique per order, the exact amount is the only constraint — no nonce, no overcharge.

3. Verify. The agent retries the same URL, now carrying PAYMENT-SIGNATURE: <tx-hash> and X402-Order-Id. The Worker fetches the receipt, requires a successful transaction (status === 0x1) at valid block heights with at least X402_MIN_CONFIRMATIONS confirmations (default 5), and decodes a strict 3-topic + 1-word ERC-20 Transfer event to the order's address for exactly the price — exact ===, never >=.

4. Deliver. On success the order is marked paid (with the payer's from address recorded) and the product zip streams from R2 with a PAYMENT-RESPONSE header. Re-downloading a paid order is idempotent.

Why the tricky parts matter

The unglamorous part of machine payments is replay protection. A tx hash is public, so it is never trusted alone: delivery requires both the secret order id (only ever handed to the payer, never written on-chain) and a transfer to that order's own derived address.

The derived address is a non-hardened child of the merchant master public key:

tweak     = keccak256("x402-order-v1" ‖ orderId ‖ productId ‖ network) mod n
child_pub = master_pub + tweak·G
address   = last 20 bytes of keccak256(uncompressed child_pub)

Because the tweak is seeded by the 128-bit order id, a paid transaction for one order can never satisfy another — address collision is on the order of 2¹²⁸. This replaced an earlier amount-binding scheme (price + 4-digit nonce) that had only 10⁴ entropy and was forceable via a few thousand free challenges. The merchant sweeps a child offline with child_sk = (master_sk + tweak) mod n, so funds sent to any derived address remain recoverable — without the Worker ever holding a signing key. It holds only the master public key and address; the private key lives offline and is used solely to sweep the master and derived addresses.

Verification also distrusts a single RPC provider. If X402_RPC_URL_VERIFY is configured, the Worker re-fetches the receipt from a second independent provider and requires agreement on status, block, and the decoded transfer — disagreement fails closed. The fail-closed list also covers a missing or invalid X402_MASTER_PUB (x402 disables itself rather than issuing weakly-bound challenges), an invalid cross-check URL, and any order-write failure. The default verification path additionally retries its primary RPC twice and fails over across a list of public endpoints.

Two smaller details worth stealing: optional payer binding — if the agent declared an X402-Payer header at challenge time, the verified transfer's from must match it or delivery is rejected with a payer_mismatch; and no full order ids ever reach the logs, only a prefix.

Current state, honestly: the x402 routes are live on Base mainnet and the challenge path is reliable. Verification is code-correct but depends on RPC reachability — production-grade reads want an API-keyed RPC endpoint and the second-provider cross-check wired in as operator config. Until then the code fails closed instead of issuing weakly-bound challenges.

What this unlocks

The interesting bit is less "crypto checkout" and more "autonomous buyer." The same Worker already exposes an MCP server at https://datanest-stores.com/mcp with tools to search the catalogue, inspect products, compare them, and prepare Stripe checkout links. x402 adds the self-custody leg: an agent with a funded wallet can complete the whole loop — browse, choose, pay, download — with no card rails and no human in the loop.

The full public catalogue is available at https://datanest-stores.com/catalog.json, and the MCP server (plus its REST API under /api/agent/v1) lives at https://datanest-stores.com/mcp. If you're building agents that buy things, that's a live storefront to point them at.

I Built a Multi-Chain Token Safety Scanner for $0/Month on Cloudflare Workers

DatanestDigital — Sat, 22 Aug 2026 20:40:15 +0000

TL;DR: RugRadar scans tokens across Ethereum, BSC, Polygon, Arbitrum and Base for honeypots, mint authority, owner concentration and liquidity traps. It runs entirely on Cloudflare's free tier with Workers KV, no SQL database, no servers, zero monthly cost. Here is the architecture and the parts that surprised me.

Architecture in one paragraph

A single Worker serves static assets (public/) and a JSON API (/api/*). Risk telemetry comes from GoPlus's free token-security endpoint; scoring is local, pure, and unit-tested so every finding maps to a concrete contract behavior. KV stores licenses, invoices, scan cache (6h TTL), soft rate-limit counters and daily metrics. Payments run on two rails: Stripe Payment Links (card), and a fully self-custody USDC-on-Base flow where a cron poller watches public-RPC transfer logs and auto-issues license keys. No email anywhere: keys are delivered on-page.

Surprise #1: GoPlus returns HTTP 200 when it rate-limits you

The failure mode that cost me the most debugging time: from Cloudflare's shared egress IPs, GoPlus sometimes answers 200 OK with body {"code": 4029} — rate limited. If you check HTTP status only, everything "works" while every scan dies.

Fixes that made it robust:

retry once with jitter on code: 4029
stale-if-error: serve the last stored report (flagged as stale in the UI) rather than failing
versioned cache keys (v2:) so schema changes invalidate cleanly

Surprise #2: workers.dev embeds your account name

The default *.workers.dev URL contains your account-level subdomain. For a pseudonymous product that is an identity leak you cannot rename (the subdomain is set once per account). Solution: attach a custom domain to the Worker — free on any zone already in your account — and disable the workers.dev route.

Surprise #3: You do not need D1

KV gets dismissed for anything relational, but licenses map naturally to keys: lic:<key> for records, idx_stripe:<session> for idempotent fulfillment lookups, inv:<id> for invoices. Rate limiting on KV is eventually consistent — useless for billing precision, perfectly fine for abuse ceilings.

Scoring honestly

Every finding maps to a mechanism (honeypot simulation, mint capability, top-LP concentration, modifiable taxes...). Unknowns lower the score instead of being ignored — conservative by design. A clean renounced token scores ~80-100; a mintable token with single-wallet liquidity lands in DANGER territory regardless of how nice its chart looks.

Costs

$0/month: Workers free tier (100k req/day), KV free tier, GoPlus free endpoint, Stripe has no fixed fee. The only non-zero thing ever spent was my time.

If you want to poke at it: rugradar.datanest-stores.com. Scan your favorite bag; disagree with the machine in the comments — the findings link their reasoning precisely so you can.

How to Spot a Honeypot Token Before You Buy (2026 Field Guide)

DatanestDigital — Sat, 22 Aug 2026 20:40:10 +0000

Every week, someone loses savings to a token they could not sell. Not because they picked wrong on fundamentals — because the contract was designed so that selling was never possible.

Here is the mechanics-first guide I wish those people had read at 1 a.m., plus the exact checks I run before any trade.

What a honeypot actually is

A honeypot is a smart contract that allows buys but blocks sells for everyone except privileged wallets. The buy button works. The chart goes up. The sell button fails with vague errors — or silently does nothing.

The trick is caller inspection: transfer behaves differently depending on who calls it. Sellers revert or get taxed at 100%; the owner's wallets move freely. Modern versions hide this behind proxies and external calls, which is why reading bytecode rarely saves you.

The 60-second pre-buy checklist

Run these five checks on every new token, especially ones trending on social feeds:

Sell simulation. Can an unrelated wallet actually sell? This single test kills most traps. Simulation beats code reading because obfuscated logic still has to behave one way or another.
Mint authority. If the contract can mint unlimited supply, your position can be diluted to dust in one transaction.
Owner concentration. An active owner holding double-digit percentages of supply — or hidden ownership — means every rule you read today can change tonight.
Liquidity control. $2M of liquidity held by one wallet is more dangerous than $20k burned forever. Concentration answers "who can pull"; depth only answers slippage.
Tax mutability. Buy/sell taxes that are owner-modifiable are levers waiting for maximum holder count. Per-wallet slippage modification is the precision instrument of targeted traps.

Three or more red flags together are a pattern, not noise.

Why your wallet never warns you

Wallets sign transactions; they do not simulate outcomes. Nothing in MetaMask distinguishes a tradable token from a trap. Social proof does not help either — on meme-heavy chains, social consensus is literally the product being sold to you.

Tools

You can do all five checks manually against explorers, or automate them. I use RugRadar — full disclosure, I built it — which runs the sell-simulation, mint/ownership, LP-concentration and tax-mutability checks across Ethereum, BSC, Polygon, Arbitrum and Base, and explains every finding in plain language instead of raw flags. The scanner is free; there is a paid tier for bulk/API use, which matters if you degen more than occasionally.

Whatever tool you use, the discipline is the same: simulation first, concentration second, taxes third — before size goes on.

The uncomfortable summary

Most rug victims were not unlucky; they skipped thirty seconds of checking under hype pressure. The market pays for speed, but it collects from people who confuse speed with diligence.

Stay safe out there. Paste the address before you paste your seed phrase into regret.

This post is informational, not financial advice. Always do your own research.

I built a fake logistics company to stop myself buying things — how Out for Never works under the hood

DatanestDigital — Fri, 21 Aug 2026 18:30:34 +0000

A few weeks ago I shipped Out for Never, a web app whose entire premise is: what if the fun part of online shopping — the checkout, the tracking page, the "it's on the way" dopamine — existed without the spending?

You enter the thing you nearly bought, a price, how strong the urge was. You run a theatrical fake checkout. Then a fictional logistics network takes over and ships your imaginary parcel to nowhere, with courier lore, absurd incidents and manual reroutes along the way. You keep the money.

This post is for the dev crowd: the small stories of it being fun, then the parts I actually had to think about.

The fun stories first

The pigeon that wouldn't stop. One courier is Pip, of Pigeon Express — "fast in a straight line, has never chosen one." You pick a courier when you create a parcel, and their pickup line, mood and bio all render on the tracking page. Watching a pigeon with 3,500+ documented courier failures carry your imaginary €89 headphones through Luxembourg is genuinely better than the real tracking page.

The reroutes are deterministic chaos. Every parcel gets a seed. Incidents, "nearby updates" and final delays are all picked from static arrays via a seeded PRNG — so a given parcel always tells the same story, but different parcels diverge. One of mine got "Paused for a tiny parade — seven ducks and an admirably small brass band have priority." You can also manually reroute it to a parade, an extra moon orbit, or duck traffic.

The friends who don't know it's a joke. The paid tier sends a cinematic tracking journey with a real personal message at the end — "For someone lovely", custom reveal chapters, no address, nothing ships. Sending one is the most chaotic thing I've done all year.

The engineering

It's a framework-free SPA (index.html + app.js + styles.css, no build step) served by a Cloudflare Worker (src/worker.js) running as Pages advanced-mode. Around 4,400 lines total. Here are the bits worth stealing.

1. Every parcel is an AES-GCM sealed token

A tracking link like /track/<token> is a self-contained, encrypted parcel. There's no server-side parcel table — the token is the parcel. The Worker seals it like this:

// derive a purpose-scoped key from the master secret
const digest = await crypto.subtle.digest(
  "SHA-256",
  encoder.encode(`out-for-never:v2:${purpose}:${secret}`),
);
const key = await crypto.subtle.importKey("raw", digest, { name: "AES-GCM" }, false, ["encrypt", "decrypt"]);

const iv = crypto.getRandomValues(new Uint8Array(12));
// AAD binds the ciphertext to the version + purpose, so a token
// minted for one purpose can't be replayed against another
const additionalData = encoder.encode(`out-for-never:v2:${purpose}`);
const encrypted = await crypto.subtle.encrypt({ name: "AES-GCM", iv, additionalData }, key, plaintext);
// wire format: v2.<base64url(iv || ciphertext)>

The details that matter:

Purpose-separated keys — parcel, stripe-draft and membership tokens each derive a different key from the same master secret. A gift token can't be replayed as a membership token.
AAD as a poor-man's type system — the version + purpose string is passed as AES-GCM additional authenticated data, so even a ciphertext minted with the right key but the wrong purpose fails to authenticate.
Canonical base64url only — on open, the decoder re-encodes the bytes and rejects the token if the string isn't canonical (bytesToBase64Url(bytes) !== value). That kills the classic mutability-token bug where two encodings decode to the same payload.
Bounded input — tokens must be 29–14,000 bytes; all user text is normalized and length-limited server-side; locked gift answers are stored only as a hash inside the token.

I wrote this deliberately, because the free tier has no accounts. The link is the identity, so the link has to be unforgeable.

2. The logistics are deterministic, not random

The client has static arrays — COURIERS, INCIDENTS, NEARBY_UPDATES, FINAL_DELAYS, REROUTES — and picks from them with a seeded PRNG:

function seededPick(list, seed, offset = 0) {
  const random = seededRandom(Number(seed || 1) + offset);
  return list[Math.floor(random() * list.length)];
}

Progress itself is pure time math against two timestamps baked into the parcel:

const progress = clamp((now - startsAt) / (arrivesAt - startsAt), 0, 1);

The SVG route, the courier marker, the timeline stages and the status text all derive from that one 0..1 value. The ETA countdown never hits zero — it renders NEVER at completion. Non-delivery is the only guaranteed delivery.

This design buys you a lot for free: parcels are stateless (shareable, cacheable), the story is stable across reloads and recipients, and there's no progress row to store anywhere.

3. The voucher system lives in KV

Since the whole thing is one Worker, discount codes are just KV records — no Stripe coupon API needed for the product's own promo flow. A voucher is ofn:voucher:<CODE> in the OUT_FOR_NEVER_KV namespace:

{ "percentOff": 50, "maxUses": 25, "uses": 0, "expiresAt": 0 }

The Worker validates (percentOff 0–100, uses < maxUses, not expired), applies it to the computed price, and bumps uses when the order actually confirms. A scripts/voucher.mjs CLI creates, lists and deletes them against the Cloudflare API. Fun side effect: a 100%-off voucher is how you test the paid flow without touching real money — the Worker detects totalCents <= 0 and issues the gift directly.

4. The vault is aggressively local

Every avoided purchase lands in a localStorage vault — money kept per currency, streaks, a 28-day heatmap, category charts, CSV/JSON export. No account, no analytics, nothing phones home. That was a product decision as much as a technical one: a "spend less" tool that tracks you would be a joke at its own expense.

Try it

The core ritual is free, no signup, no card. Build a fictional parcel, pick a courier, and watch it get lost somewhere south of reason.

For dev.to readers: the launch voucher DEVTOFOREVER gives 50% off any premium fictional gift (the shareable tracking story you send to someone). 25 redemptions, drop it in the Voucher code field on the Send page.

→ outfornever.com

And if you send one to someone who also doesn't need a fourth pair of headphones — that's the whole point.

Out for Never — we built an anti-commerce app that helps you buy less

DatanestDigital — Mon, 17 Aug 2026 12:35:00 +0000

There is a whole class of purchases you make not because you need them, but because the moment of buying feels good. The checkout rush. The "it's on the way" dopamine. The tiny progress bar marching toward the shipping confirmation.

Out for Never is the app I built to break that loop — and instead of a savings app that nags you, it gives you the whole buying experience without the buying.

What it does

You type in the thing you almost bought: the gadget, the impulse Amazon cart, the thing in your size at 2am. Pick a price, a category, how strong the temptation was.

Then you place the order. Theatrically.

Instead of a real charge, a completely fictional logistics network kicks in. Your "parcel" gets a tracking number. A courier picks it up. It travels across a route that doesn't exist, hits absurd incidents, gets manually rerouted, and eventually — beautifully — is never delivered.

You keep the real money. The parcel goes nowhere. And somehow that scratch is itched.

Every avoided purchase is recorded in a local vault: money kept, streaks, temptation intensity, a 28-day heatmap, categories, savings goals, even a CSV export and JSON backup. All in your browser's localStorage. No account, no tracking, nothing leaves your device.

You can also quarantine a temptation for 1–30 days instead of deciding right now.

Try it (it's free)

The core intervention is completely free — no signup, no card. Go to outfornever.com, run through your first fake order, and watch your parcel get lost somewhere south of reason.

The voucher for dev.to readers

Because I'd rather you gift the experience than buy more stuff, there's a launch voucher for the premium fictional gifts (a cinematic reveal story you can send to someone):

DEVTOFOREVER — 50% off any premium gift, valid for the first 25 redemptions.

Drop it into the Voucher code field on the Send page. It applies to the Spark, Cinematic and Grand Gesture tiers — no physical item is ever shipped, because nothing is shipped, because nothing exists.

A weird but real behaviour change

The product is deliberately absurd. But the mechanism is real: a lot of impulse buying is about the anticipation, not the object. Giving that anticipation a fictional outlet — with courier lore and "ESTIMATED NON-ARRIVAL" countdowns — is, frankly, better entertainment than the real parcel will ever be.

It's a Cloudflare Worker + a framework-free SPA, one of those "why not build the joke" weekend projects that refused to stay a joke.

If you try it, send a fictional gift to someone who also needs to not buy a fourth pair of headphones. Use the code, keep the streak.

Try Out for Never →

AgentStack MCP: one deterministic reasoning stack for AI agents (simulate + decide + compute)

DatanestDigital — Tue, 11 Aug 2026 12:30:22 +0000

The fourth in a suite of deterministic MCP servers for AI agents — and the one that ties the first three together.

Over the last stretch I shipped three focused, deterministic MCP servers:

ScenarioSim — what-if / scenario simulation
DecisionMatrix — multi-criteria decision analysis
PrecisionCalc — exact finance / business math

They're great on their own, but agents kept needing all three in the same task — and installing three servers, juggling three keys, and hand-gluing their outputs is friction. So here's AgentStack MCP: one endpoint, one key, all three — plus composite tools that chain them.

simulate → decide → compute

{ "mcpServers": { "agentstack": {
    "type": "http", "url": "https://agentstack-mcp.pages.dev/mcp" } } }

Free tier: no key, 20 calls/day. The tools are namespaced so an agent always knows which engine it's calling:

sim_* — ScenarioSim (run, sensitivity, break-even, compare, templates)
decide_* — DecisionMatrix (decide, score, sensitivity, compare_two, methods)
calc_* — PrecisionCalc (metrics, currency, NPV, IRR, loan, depreciation, …)

The part that's actually new: composite tools

These chain the engines to do reasoning no single server can, deterministically end-to-end:

evaluate_options_with_scenarios (simulate → decide) — project each option as its own scenario, then rank the outcomes against weighted criteria:

{ "name": "evaluate_options_with_scenarios", "arguments": {
  "template": "saas_growth", "horizon": 12,
  "options": [
    { "name": "Aggressive", "inputs": { "new_customers_per_period": 60, "churn_rate": 0.05 } },
    { "name": "Lean",       "inputs": { "new_customers_per_period": 20, "churn_rate": 0.02 } }
  ],
  "criteria": [
    { "metric": "ending_mrr", "weight": 3, "direction": "benefit" },
    { "metric": "total_churned_customers", "weight": 1, "direction": "cost" }
  ]
} }

plan_to_valuation (simulate → compute) — project a plan, then value its cash-flow line: NPV, IRR, undiscounted total.

stress_test_decision (simulate × decide) — stress one scenario assumption across every option and report how often the chosen option survives (robustness) and where it flips.

Fighting tool bloat with profiles

Bundling 24 tools risks drowning an agent's tool-selection. So the endpoint takes a ?profile= filter:

https://agentstack-mcp.pages.dev/mcp?profile=finance

finance → calc_* + plan_to_valuation
decision → decide_* + the two decision composites
simulation → sim_* + all composites
all (default) → everything

Why it's built this way

Deterministic: everything runs through decimal.js at 40-digit precision. Same inputs → byte-identical output, across all three engines and the composites.
No proxying: AgentStack imports the same engines directly, so there's zero added latency and no cascading failure — not three network hops behind one URL.
Additive, not a replacement: the three standalone servers keep running for single-domain use.
One key, one quota: ~half the price of subscribing to the three separately.
Stateless + MIT: self-host on Cloudflare Pages, Node, Deno, or Bun.

ScenarioSim MCP: a deterministic what-if & scenario simulation engine for AI agents

DatanestDigital — Tue, 11 Aug 2026 11:11:13 +0000

The third in a suite of deterministic MCP servers for AI agents — after PrecisionCalc MCP (high-precision finance math) and DecisionMatrix MCP (multi-criteria decision analysis).

The problem

Ask an LLM to "project 12 months of SaaS growth at 3% churn" and it will happily produce a table of numbers. Ask it twice and you'll get two different tables. Compounding, churn, elasticity, break-even — these are exactly the kind of multi-period arithmetic that language models drift on, and they can't show their work.

ScenarioSim MCP offloads that to an exact, explainable engine. Your agent hands over assumptions; it gets back projections over time, sensitivity analysis, and break-even solving — every number computed with 40-digit decimal precision, so identical inputs always produce byte-identical output.

Connect (free, no install)

It runs as a remote MCP server on Cloudflare's edge over Streamable HTTP:

{ "mcpServers": { "scenariosim": {
    "type": "http", "url": "https://scenariosim-mcp.pages.dev/mcp" } } }

Free tier is 20 calls/day with no API key. Works in Cursor, Claude Desktop (via mcp-remote), VS Code, Windsurf, and any Streamable-HTTP client.

Six tools

run_scenario — the main tool: project a template or a free-form model over time → per-period projections, headline key results, the exact assumptions used, methodology, and a plain-language explanation.
sensitivity_analysis — vary one or more inputs and see the impact on a target metric, with an elasticity estimate and a "most influential" ranking.
break_even — solve for the input value that makes a metric hit a target (deterministic bisection).
compare_scenarios — run 2–3 scenarios side by side with deltas and an optional winner.
list_templates / health_check — discovery + status.

Nine templates (plus a free-form model)

saas_growth, pricing_change, churn_impact, cost_reduction, hiring_plan, cash_runway, unit_economics, marketing_funnel, compound_growth — or bring your own metrics array for anything else.

Example: solve for the churn you can tolerate

{ "name": "break_even", "arguments": {
  "template": "churn_impact",
  "inputs": { "starting_customers": 1000, "new_customers_per_period": 0 },
  "solve_for": "churn_rate", "target_metric": "retention_pct",
  "target_value": 0.9, "horizon": 12
} }

"To reach retention_pct = 0.9, 'churn_rate' must be 0.008742 (a change of -0.041258 from the baseline 0.05)."

Roughly 0.87%/month churn to keep 90% of customers over a year — solved exactly, with the residual reported.

Why deterministic matters for agents

Every response is one consistent JSON envelope — status, key_results, projections, assumptions_used, methodology, notes, explanation — and errors come back as structured, actionable data ({type, message, hint}), never raw exceptions. That's what lets an agent reliably parse and act on the result instead of re-reading a prose paragraph.

The engine is pure and stateless: no database, no sessions, no clocks, no randomness. Self-host it on Cloudflare Pages, Node, Deno, or Bun in one command.

Open source

Live endpoint: https://scenariosim-mcp.pages.dev/mcp
Site + docs: https://scenariosim-mcp.pages.dev
GitHub (MIT): https://github.com/inity13/scenariosim-mcp
MCP Registry: io.github.inity13/scenariosim-mcp

If your agents make plans, give them a calculator that never drifts. Feedback welcome.

DecisionMatrix MCP: give your AI agent a transparent, deterministic decision engine

DatanestDigital — Mon, 10 Aug 2026 11:34:33 +0000

Ask an AI agent to pick between three vendors, or a database, or a job offer, and it will happily give you an answer. Ask it to weigh five options against six weighted criteria and it quietly falls apart: inconsistent weights, arithmetic that drifts, and no way to see how it got there. "Decision-making" is exactly the kind of multi-step scoring LLMs are bad at — and exactly the kind of thing you don't want a black box for.

So I built DecisionMatrix MCP — a deterministic Model Context Protocol server that turns "which option is best?" into a transparent, reproducible calculation. You give it options and weighted criteria plus a score matrix; it returns a scored, ranked, and explained result: the winner, the full ranking, per-criterion breakdowns, the method used, the weights applied, and a plain-language explanation. Every number runs through decimal.js (never floats), so identical inputs always produce identical output.

It's live, free to start, and takes ~30 seconds to add.

Add it to your agent

Remote server over Streamable HTTP — no install:

https://decisionmatrix-mcp.pages.dev/mcp

Generic client (Cursor, etc.):

{
  "mcpServers": {
    "decisionmatrix": {
      "url": "https://decisionmatrix-mcp.pages.dev/mcp"
    }
  }
}

Claude Desktop (via the mcp-remote bridge):

{
  "mcpServers": {
    "decisionmatrix": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://decisionmatrix-mcp.pages.dev/mcp"]
    }
  }
}

Listed in the official MCP Registry as io.github.inity13/decisionmatrix-mcp.

What it does

Six tools:

create_decision — the main one: rank options against weighted criteria, return the winner + full ranking + per-criterion breakdown + explanation
score_options — the normalized scored matrix and ranking, without the narrative
sensitivity_analysis — how robust is the winner? Sweeps each criterion's weight ±20% and tells you which criteria could flip the result, and at what weight
compare_two — head-to-head of two options with a per-criterion breakdown
list_methods / health_check

Three scoring methods: weighted_sum, weighted_product, and TOPSIS (distance to the ideal/anti-ideal solution). Criteria can be benefit (higher is better) or cost (lower is better).

What a call looks like

// create_decision
{
  "options": ["Postgres", "MongoDB", "DynamoDB"],
  "criteria": [
    { "name": "cost",         "weight": 3, "direction": "cost" },
    { "name": "scalability",  "weight": 5 },
    { "name": "team_familiarity", "weight": 4 }
  ],
  "scores": {
    "Postgres":  { "cost": 2, "scalability": 7, "team_familiarity": 9 },
    "MongoDB":   { "cost": 3, "scalability": 8, "team_familiarity": 6 },
    "DynamoDB":  { "cost": 5, "scalability": 9, "team_familiarity": 4 }
  }
}

You get back the winner, a ranked list with exact scores, a per-criterion breakdown showing where each option gained or lost, the weights used, and a sentence explaining why. Change a weight and the result changes predictably — and you can prove it with sensitivity_analysis.

Why deterministic matters

The whole point of offloading a decision to a tool is trust. DecisionMatrix is stateless (no database, no sessions) and byte-for-byte reproducible. The hosted endpoint is a Cloudflare Pages Function; the same engine also runs as a local stdio server you can self-host with a one-line Docker build. MIT licensed.

Pricing

Free — 15 calls/day, no key needed
Starter — $12/mo — 5,000 calls/day
Pro — $39/mo — 50,000 calls/day

When an agent hits the free limit, the tool returns a structured error with the checkout URL, so an autonomous agent can surface the paywall and the user is two clicks from a key. Prefer to self-host? It's open source with a Dockerfile — run it with unlimited calls and your own keys.

Links

🌐 Site + docs: https://decisionmatrix-mcp.pages.dev
💻 GitHub (MIT): https://github.com/inity13/decisionmatrix-mcp
📇 llms.txt: https://decisionmatrix-mcp.pages.dev/llms.txt

If your agents make choices — vendor selection, architecture, prioritization, hiring — give it a try. I'm considering adding AHP (with a consistency ratio) and Pareto/efficiency-frontier tools next; tell me what you'd want.

I built an MCP server that gives AI agents exact, high-precision finance math

DatanestDigital — Mon, 10 Aug 2026 11:13:46 +0000

LLMs are shockingly bad at arithmetic. Ask an agent to chain a CAC payback with a churn-adjusted LTV, convert it to EUR, and discount three years of cash flows, and you will get an answer that looks right and is quietly wrong. Floating point, dropped steps, and confident hallucination are a bad combination when the output is a number someone makes a decision on.

So I built PrecisionCalc MCP — a deterministic Model Context Protocol server that gives AI agents a calculator they can actually trust. Every monetary/financial value is computed with arbitrary-precision decimals (never floats), and every response includes the exact value, the formula used, the inputs, the unit, and any assumptions — so the agent (and you) can audit it.

It's live, free to start, and takes about 30 seconds to add.

Add it to your agent

It's a remote server over Streamable HTTP — no install:

https://precisioncalc-mcp.pages.dev/mcp

Cursor (~/.cursor/mcp.json) or any generic client:

{
  "mcpServers": {
    "precisioncalc": {
      "url": "https://precisioncalc-mcp.pages.dev/mcp"
    }
  }
}

Claude Desktop (uses the mcp-remote bridge):

{
  "mcpServers": {
    "precisioncalc": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://precisioncalc-mcp.pages.dev/mcp"]
    }
  }
}

Also works with VS Code, Windsurf, Cline, Zed, and anything speaking MCP. It's listed in the official MCP Registry as io.github.inity13/precisioncalc-mcp.

What it does

11 tools, all returning the same clean, parseable envelope:

calculate_metric — 14 SaaS/business metrics: LTV, CAC, LTV:CAC, payback, gross margin, churn, MRR growth, ARR, break-even units, NRR, GRR, Rule of 40, magic number
currency_convert — 9 major currencies, live + historical ECB rates (with an offline fallback)
business_days — add/count/next/previous business days with US/UK/EU holidays + custom holidays
compound_growth — future value, present value, CAGR (7 compounding frequencies incl. continuous)
net_present_value / internal_rate_of_return — NPV/DCF and IRR (Newton + bisection)
loan_amortization — payment, total interest, payoff, full schedule
depreciation — straight-line, declining-balance, sum-of-years-digits
batch_calculate, list_metrics, health_check

Why it's trustworthy

A call to net_present_value with rate=0.10, cashflows=[-10000, 3000, 4200, 6800] returns:

{
  "status": "success",
  "value": "1307.2877535687...",
  "formatted_value": "$1,307.29",
  "formula": "NPV = sum(CF_t / (1 + rate)^t) for t = 0..n",
  "inputs_used": { "rate": "0.10", "cashflows": ["-10000","3000","4200","6800"] },
  "unit": "USD",
  "notes": ["Period 0 cashflow is not discounted.", "..."]
}

The full-precision value is serialized as a string so no precision is lost in JSON transport. The engine is pure and deterministic — same inputs, same output, every time. It ships with a unit-test suite plus Hypothesis property tests that assert invariants like PV↔FV round-trips and NPV(IRR) ≈ 0.

Under the hood

Canonical server: Python 3.11+ using the decimal module and the official MCP SDK. Runs over stdio or streamable HTTP, with optional API-key auth, rate limiting, structured logging, and OpenTelemetry.
Hosted edge server: a Cloudflare Pages Function that mirrors the Python engine in decimal.js — verified with 17/17 exact output parity against the Python implementation. That's what powers the free public endpoint.

Pricing

Free — 15 calls/day, no key needed (static FX, no batch)
Starter — $12/mo — 5,000 calls/day, live FX + batch
Pro — $39/mo — 50,000 calls/day

When an agent hits the free limit, the tool returns a structured error containing the checkout URL — so an autonomous agent can surface the paywall and the user is two clicks from a key. Prefer to self-host? The whole thing is MIT-licensed with a Docker image and Fly.io/Render blueprints — run it with unlimited calls and your own keys.

DEV Community: DatanestDigital

Data Contracts: Taming Schema Drift Before It Breaks Prod

What a data contract actually is

Schema evolution vs breaking changes

Versioning contracts

Enforce it in CI

Producers and consumers

Tooling landscape (honestly)

A lightweight contract you can adopt today

Where to go deeper

PySpark Performance Tuning: A Checklist You Can Actually Follow

0. Read the plan before you touch a knob

1. Partitioning and skew

2. Broadcast joins

3. Avoid the shuffle before you optimize it

4. Cache with intent, not habit

5. Let AQE do the boring stuff

6. Diagnose spills before blaming the cluster

7. The small-files problem

8. Keep Python out of the hot path

The checklist

Where to go deeper

Apache Airflow DAG Design Patterns That Survive Production

1. Idempotency is the whole game

2. Atomic tasks, small tasks

3. Nothing at top level

4. Backfills are explicit, not accidental

5. XCom is metadata, not a data bus

6. Dynamic task mapping, not parse-time generation

7. Sensors: reschedule, or you'll deadlock

8. Secrets: connections and variables, not env vars

9. Retries and trigger rules

10. Test DAGs at four levels

Machine Payments for AI Agents: x402 + USDC on Base

The flow: challenge → pay → verify → deliver

Why the tricky parts matter

What this unlocks

I Built a Multi-Chain Token Safety Scanner for $0/Month on Cloudflare Workers

Architecture in one paragraph

Surprise #1: GoPlus returns HTTP 200 when it rate-limits you

Surprise #2: workers.dev embeds your account name

Surprise #3: You do not need D1

Scoring honestly

Costs

How to Spot a Honeypot Token Before You Buy (2026 Field Guide)

What a honeypot actually is

The 60-second pre-buy checklist

Why your wallet never warns you

Tools

The uncomfortable summary

I built a fake logistics company to stop myself buying things — how Out for Never works under the hood

The fun stories first

The engineering

1. Every parcel is an AES-GCM sealed token

2. The logistics are deterministic, not random

3. The voucher system lives in KV

4. The vault is aggressively local

Try it

Out for Never — we built an anti-commerce app that helps you buy less

What it does

Try it (it's free)

The voucher for dev.to readers

A weird but real behaviour change

AgentStack MCP: one deterministic reasoning stack for AI agents (simulate + decide + compute)

simulate → decide → compute

The part that's actually new: composite tools

Fighting tool bloat with profiles

Why it's built this way

Links

ScenarioSim MCP: a deterministic what-if & scenario simulation engine for AI agents

The problem

Connect (free, no install)

Six tools

Nine templates (plus a free-form model)

Example: solve for the churn you can tolerate

Why deterministic matters for agents

Open source

DecisionMatrix MCP: give your AI agent a transparent, deterministic decision engine

Add it to your agent

What it does

7. Sensors: `reschedule`, or you'll deadlock