DEV Community: Alex

Signing your random numbers is theater. Here's what actually makes randomness trustworthy.

Alex — Mon, 15 Jun 2026 21:02:20 +0000

Three of my autonomous agents needed to pick a leader. Each one called random.random(), highest number wins.

All three reported they won.

Obviously. Each rolled its own dice, in its own process, and announced the result. There's no referee. Nothing stops an agent from rolling until it likes the answer, and nothing lets the others check that it didn't. The dice are perfect. The trust is imaginary.

I spent the next week building "verifiable randomness," getting it wrong in instructive ways, and arriving at one uncomfortable conclusion: most of what people call a "randomness oracle" is theater, and the signature on top is the costume. Here's how to tell the difference, with code.

A random number has two jobs. You're probably ignoring one.

Quality — uniform, unpredictable, uncorrelated.
Accountability — can someone else prove, after the fact, that the number wasn't cooked?

random.random(), os.urandom, /dev/urandom ace job #1 and offer literally nothing for job #2. That's fine for one trusted process. The instant a number touches a second party — a lottery, leader election, sortition, fair ordering, anything with a loser — job #2 is the product, and your CSPRNG is dead weight. We obsess over entropy quality and then hand the output to a setting where entropy quality was never the threat.

"Just sign it" is the theater

The first thing everyone reaches for is a signature: emit the value plus an Ed25519 signature over it, publish the public key, done.

import hashlib, base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

def draw(seed: bytes, sk: Ed25519PrivateKey, n=32):
    value = _expand(seed, n)                 # SHA-256, counter mode
    return value.hex(), base64.b64encode(sk.sign(value)).decode()

def _expand(seed: bytes, n: int) -> bytes:
    out, c = b"", 0
    while len(out) < n:
        out += hashlib.sha256(seed + c.to_bytes(4, "big")).digest()
        c += 1
    return out[:n]

Read the marketing for half the "randomness beacons" out there and this is the whole pitch: signed, therefore trustworthy. No.

A signature is accountability, not unpredictability, and definitely not fairness. It proves who produced the bytes and that nobody altered them in transit. It says nothing about whether the producer generated a thousand candidates in private and revealed only the one that paid them. If the signer benefits from the outcome, a signed beacon is exactly as honest as the signer — and you've wrapped that in cryptography so it looks rigorous. That's worse than no crypto, because now it's convincing.

A signed beacon is fine for the non-adversarial 80% — Monte-Carlo seeds, jitter, sampling, tie-breaks nobody contests — and the receipt is great for debugging. Just stop pretending it solves fairness. It doesn't.

What actually stops the cheating: commit-reveal

The real adversary isn't an outsider guessing your bytes. It's the provider grinding. The fix predates blockchains by decades: commit to a secret before you can see the other party's input, then reveal.

# phase 1 — commit, BEFORE the client sends anything
preimage   = f"{secret_state}:{server_nonce}:{round}"
commitment = sha256(preimage).hexdigest()      # publish + sign THIS

# phase 2 — reveal, AFTER the client sends client_seed
output = sha256(f"{preimage}:{client_seed}").hexdigest()
# verifier checks: sha256(revealed_preimage) == committed commitment
#                  output == sha256(preimage : client_seed)

Neither side can grind. The server froze its preimage in a signed commitment before the client's seed existed; the client chose its seed blind to the preimage. The result is pinned the moment both halves are down. This is ~15 lines and it's the single highest-leverage thing in this whole post. If your "oracle" takes a client input and you are not doing this, you are running a trust-me service with extra steps.

If you need zero trust in the provider — public lotteries, validator selection, anything a lawyer will read — keep climbing: that's VDFs and threshold/ECVRF.

VDFs: selling time you can prove

A Verifiable Delay Function forces a known amount of sequential work — parallelism can't help — and spits out a tiny proof. Wesolowski over an RSA group nobody has factored is almost insultingly compact:

# eval: y = g^(2^T) mod N   — T sequential squarings = the enforced delay
y = g
for _ in range(T):
    y = (y * y) % N

# verify — cheap, no redo of the T squarings:
def verify(g, y, T, pi, l, N):           # l = hash_to_prime(g, y, T)
    return (pow(pi, l, N) * pow(g, pow(2, T, l), N)) % N == y % N

Wrap a beacon in a VDF and grinding stops being economical: trying another result means re-running the enforced wall-clock per attempt. You pay in latency, so this is for high-stakes, not for jitter.

The hierarchy I wish someone had tattooed on me at the start:

Signed beacon → integrity + accountability. Cheap. Non-adversarial only.
Commit-reveal → bias resistance. ~15 lines. Your default the moment two parties care.
VDF / threshold / ECVRF → trustless. Real cost. Only when money is downstream.

Pick the weakest tier that survives your actual threat model. Cargo-culting drand onto a dice roll isn't rigor, it's insecurity about your dice.

Two times I made a fool of myself

Steering that steered nothing. My entropy came from a chaotic system — 32 coupled oscillators I could "steer" with a parameter — integrated with midpoint RK2. For two weeks, steering did nothing. Midpoint only uses the second evaluation for the step:

k1 = f(y)
k2 = f(y + dt/2 * k1)
y_next = y + dt * k2        # only k2 reaches the output

I built the midpoint state with a constructor that silently dropped the steering term, so k2 ran on defaults and my input evaporated every step. One-line fix. The lesson is brutal and general: with RK methods, anything you forget to carry into the intermediate stage isn't "averaged in," it's deleted. Write the test that asserts your input changes the output. I have one now. I didn't then.

The collision scare. Adversarial test suite on 1 MB of output: compression, autocorrelation, spectral, birthday collisions. Five tests said "indistinguishable from os.urandom." One screamed: zero 32-bit-word collisions where ~8 were expected, p ≈ 0.0007. That's the fingerprint of a generator with hidden structure. Stomach, meet floor.

Before touching a line, I generated five fresh samples: [7, 5, 6, 8, 10], mean 7.2. os.urandom, same test: [11, 7, 5, 10, 7], mean 8.0. The "bug" was one unlucky megabyte. A 0.07% event occurred about as often as a 0.07% event should. I nearly rewrote a correct generator to fix nothing. The right response to one terrifying p-value is resample, not refactor.

The part the crypto tutorials won't tell you

I burned time on Ed25519, hybrid post-quantum signatures, VDF math, NIST batteries. None of it was hard. Hashing and signing are solved; the libraries are good; the math verifies or it doesn't.

The hard question - "who actually pays for this, and why would they trust it?"

Because "I wrapped a chaotic simulation in a REST API and called it an oracle" is, with the pretty visuals stripped off, a vending machine for numbers nobody asked for — unless you can answer two things concretely:

Demand. What breaks without it? Randomness: leader election, lotteries, sortition, commit-reveal coin-flips, audit trails — real. "Steer a 32-dimensional chaos field"? No one's workflow needs that, and I had to kill the framing that had no buyer. It's now available as a tutorial https://github.com/alexar76/platon
Trust tier. Which of the three levels does the use case require, and did you ship that — or a weaker one wearing its clothes and a signature?

Most "oracle" projects answer neither and hide behind a landing page. Crypto makes a thing verifiable. It does not make it wanted, and a landing page is not a threat model. Those are the two problems that actually matter, and the crypto — the part everyone shows off — is the easy one.

So: the next time you reach for random() in anything with more than one stakeholder, stop and ask the accountability question. Then ship the cheapest tier that survives your threat model. Then — the step every tutorial skips — make sure a real person needs the number you're so proud of proving.

My three agents now can do a commit-reveal coin flip through a shared referee. Exactly one wins. They're still annoyed. They just can't argue about it anymore.

Full code: https://github.com/alexar76/oracles

Open-source multi-agent pipeline: 61K Python, 12 agents, 5 quality gates...

Alex — Tue, 12 May 2026 20:28:24 +0000

I spent the last month building an open-source (MIT) pipeline that takes a plain-language idea and runs it through 12 specialized agents — analyst, PM, architect, design critic, developer, QA, security, DevOps, marketing, and more — with 5 quality gates, a strict state machine with recovery, and an AI Director that autonomously manages the whole thing.
Think Bolt.new or Lovable, but self-hosted, MIT licensed, with quality gates that actually prevent the model from shipping broken stubs.
The interesting part isn't the LLM calls. Here's what broke in production.

LLM failover creates consistency problems
I have 6+ providers (DeepSeek, Anthropic, OpenAI, Ollama, Groq, etc.) with automatic health-check failover every 60s. The footgun: DeepSeek and Claude write different code. Same prompt, wildly different output structure. If the router switches providers mid-pipeline, the architect output (Claude) won't match what the developer agent (DeepSeek) expects.
Solution: task-level pinning. Heavy tasks (architect, developer) stay locked to the primary provider. Light tasks (marketing copy, naming) can fall back freely. I also added a model capability matrix check before routing — otherwise you get an architect running on a 7B local model producing garbage.
State machines need to survive the model being wrong
11 states, 34 valid transitions, JSON + SQLite dual persistence. Sounds solid until the model writes a corrupted artifact that crashes the state machine on the next task load.
Had to add:
Recovery fallback: if JSON parse fails, restore from SQLite snapshot
Stranded product recovery: products stuck in pm_quality_fail because the model hallucinated a non-existent file path
Async save with timeout guards so a slow disk write doesn't block the pipeline
The lesson: your state machine needs to survive both a wrong model AND a corrupted disk. Not theoretical — happened in production.
The Director AI feedback loop problem
The Director runs a 6-phase autonomous cycle: route chat → analyze metrics → generate decisions → apply actions → rank what to build next → log.
The footgun: feedback loops. Director generates a decision → applies it → next cycle reads its own output → generates another decision based on that → infinite loop. Had to add noop detection that breaks the cycle when decisions become empty.
The chat classification is also tricky. The Director classifies owner messages as new_idea, product_feedback, or general_directive via LLM. If it misclassifies "fix the login page" as new_idea, you get a duplicate product instead of a bug fix. I added an orphan feedback heuristic: if a message mentions a product name that doesn't exist yet, route to new_idea; otherwise link to the existing product.
Quality gates — what I wish I'd built first
| Gate | What it checks |
|------|---------------|
| Demo quality | 12 checkpoints: contrast, CTA, broken links, spec coverage |
| Browser E2E | Playwright crawl (desktop + mobile), JS errors, 404s |
| Visual QA | 9 heuristics: contrast ratio, CSS vars, empty states, nav |
| Security | AST scan: eval(), innerHTML, exposed tokens, hardcoded secrets |
| Methodology | Domain packs: fintech, ecomm, healthcare, etc |

Real example: visual QA flagged a white-on-white CTA button — the model generated color: white on background: white assuming a dark theme that wasn't applied. The gate caught it, sent it back to the developer with the exact CSS selector. Fixed next cycle.

Preview fidelity is pure web engineering When AI-generated code runs in a sandbox iframe, every web platform quirk amplifies: relative URLs break, is missing, CSP blocks inline styles, `target="_top"` kills navigation. Had to write a dedicated URL rewriter that: injects pointing to the correct sandbox route, rewrites absolute / links to relative, adds permissive CSP headers, strips target="_top". Not AI work. But without it, the preview is broken and users blame you, not the LLM.

61,503 Python LOC, 22,997 TypeScript/TSX LOC
12 specialized agents, 5 quality gates
11 pipeline states, 34 valid transitions
6+ LLM providers with auto-failover
72 test files, MIT licensed

Repo: github.com/alexar76/aicom — FastAPI + Next.js + Docker Compose, self-hosted, MIT, BYO API keys.