De-LINKed Randomness

Every team shipping a game, a raffle, an NFT mint, or a fair-allocation mechanism on chain ends up at the same fork in the road. The contract needs a number it can't predict and a counterparty can't manipulate, and the default answer the ecosystem reaches for is Chainlink VRF. VRF is a perfectly good piece of cryptography sat behind a perfectly real economic problem: it's an oracle service, you pay for it in $LINK, you wait on a separate network's liveness, and the proof your contract accepts is a signature from operators rather than a result you could have reproduced yourself.

We use a different primitive in our own products today. The reveal step of the Blobbs NFT mint runs on it, and so does the resolution of player-vs-player battles in Blobbs, and we think most teams reaching for VRF would be better off with the same one. We call it DER - Delayed Entropy Resolution - and under the hood it's iterated squaring in an RSA-2048 group, paired with a Wesolowski proof that lets the contract verify the result in constant time. Most of the engineering we've added on top is the operational layer around it, which we'll come to.

This isn't a Chainlink takedown. VRF is still the right answer for a small set of problems, and we'll tell you which ones. But the default has slid out from under most teams without them noticing, and the sticker price of "we'll just plug VRF in" is higher in 2026 than it looks.

What DER actually is

DER takes a seed that the user can't predict and the house can't backdate, and runs a deterministic delay over it. The seed is a hash of the user's commit (their address, their stake, their request id) concatenated with a future blockhash they couldn't have known when they staked. The compute itself is iterated squaring in an RSA-2048 group with unknown factorisation, which means the output is the result of T sequential steps and there's no parallelism shortcut to skip ahead. Whoever runs the squaring (it doesn't have to be us) emits a Wesolowski proof alongside the output, and the on-chain contract checks the proof in constant time before accepting the value as randomness.

The security argument is short, which is the bit we like. The user can't predict the seed because they have to commit before the future block is known, and the house can't fabricate the output because iterated squaring can't be run faster than its sequential delay regardless of how much hardware you throw at it. RSA-2048 factorisation is the standing assumption, which has held for decades and is the same assumption plenty of the rest of the cryptosystem you're already running depends on. Nobody needs to be trusted, nobody needs to be slashed, the contract just verifies the proof.

Where DER actually beats VRF

Cost is the obvious one, but it isn't the most important one. The fee profile of VRF in production looks roughly like 200,000-400,000 gas plus a per-request LINK premium that varies with subscription model, and you pay that on every roll regardless of value. DER moves the heavy compute off chain (the on-chain side is just proof verification, which is constant time and cheap) and removes the second token from the equation entirely. For a game settling a few thousand outcomes a day, the LINK line item alone is often the difference between "running" and "running profitably".

Trust is the more important one, because it's the thing that bites you only after you've shipped. With VRF you're trusting an operator network, with DER you're trusting the maths. There's no operator to go offline, no signing key to rotate, no governance vote that can brick your randomness, no minimum-balance alert at three in the morning when somebody forgets to top up the subscription. The output is reproducible by anyone with the seed and the patience to do the squaring, which is what "publicly verifiable" actually means in production rather than as a marketing word.

Latency is the third one, and it matters more than people credit. VRF is asynchronous - the response arrives whenever the operator network gets round to fulfilling, and the typical fulfilment window in production is several blocks, sometimes more under load. DER is a deterministic delay: you set T, you know exactly when the output is ready, and proof verification is constant time whatever else is going on. For any UX with a tight feedback loop (a card flip, a battle resolution, a mint reveal), "I know exactly when the result lands" is a noticeably better experience than "we're waiting on Chainlink".

Decentralisation is the fourth, and it's the one Chainlink themselves would push back on hardest. The network is decentralised in aggregate, but each individual VRF response in the moment comes from a single operator. With DER the proof is the only thing the contract trusts, and the proof can be submitted by anyone - us, you, a competitor, a passing botnet - because correctness is independent of who computed it. Open infrastructure beats closed infrastructure on this dimension every time.

Where VRF still wins

The clearest case for VRF is when you need entropy that isn't bound to a chain event - randomness for off-chain computation, draws scheduled by a clock rather than a transaction, or systems where the user shouldn't be the one supplying the commit. VRF's oracle model fits that shape cleanly because the oracle is precisely the thing you wanted: an external entropy source with a verifiable proof, on demand.

The other case is when you genuinely need T to be very small, sub-second resolution where a sequential-delay primitive is the wrong economics for you. In those situations the VRF round trip can actually win, especially if you're already paying for the oracle network for other reasons. We've never personally needed this, but we'll concede it exists.

Outside those two situations the default should be DER, and the burden of proof should be on whoever wants to add an external token dependency to the contract.

The Chainflo half

The thing nobody tells you about VRF is that the oracle network isn't the whole product, it's the visible bit. The actual product is the operational layer around it: the request that knows how to handle a delayed callback, the retry logic when the fulfilment never arrives, the listener that watches for the response and routes it to your business logic, the alerting when LINK runs low. That's where the integration cost actually lives, and that's the bit you keep paying for after you've shipped.

DER has the same shape. You commit, you wait the delay, somebody runs the squaring, the proof is submitted, your contract resolves. Each step is a place where production reality (RPC outages, chain reorgs, your worker crashing, a cosmic ray flipping a bit on the squaring machine) can ruin your day. We use Chainflo for exactly this layer in our own products, and it's why both Blobbs paths above run end-to-end with no operator on call.

The flow that ships the most often goes something like this: a contract event fires when a user commits a roll, Chainflo's workflow picks it up and waits for the target block to finalise, the squaring runs on whichever worker is free (we operate ours, but the architecture doesn't care who does), the proof is generated, the resolution function is called on the same contract or a sibling one, and the whole thing is recorded as a durable execution that survives anything short of the worker farm catching fire. From the contract's perspective it looks identical to "we asked an oracle and got an answer back", except the answer comes from a function we run, on a primitive we audit, with no separate token in the loop.

We're packaging this pattern as a Chainflo template that we'll publish alongside the contract verifier - the contract side is mostly boilerplate around the proof check, the workflow side is where the value is. The cost profile beats VRF meaningfully on per-roll gas plus fees, the latency is deterministic rather than oracle-dependent, and there's no LINK subscription to keep topped up.

What to do with this

If you're shipping randomness on chain right now and you reached for VRF without thinking too hard about it, that's a perfectly reasonable thing to have done two years ago. The maths has shifted, and the operational pattern around DER is mature enough that the trade-offs flip for the median use case. The useful test is to write down what your contract actually needs from a randomness primitive (cost ceiling, latency window, trust model, dependency tolerance) and check the result against the two designs above, rather than picking the one with the louder go-to-market.

If you'd like a hand running that comparison on a specific contract, or you'd rather wait for the Chainflo template and lift it directly, we should talk. The code's calmer than the post makes it sound.