Most people using DeFi today don't really think about oracles or indexers
They just expect the apps to work
Years ago, those were pretty obscure things outside dev circles. Then builders started finding uses for them, and suddenly they were everywhere
That's the part of this story that sticks with us
Counterfactual Execution probably looks oddly specific from the outside. Replaying real chain history with one input changed? Cool, but what do you actually do with that?
We have ideas, of course. But we're not spending all this time on RHOOK just to ship one more dashboard and call it a day
We want this to be something other developers can build with. Maybe someone takes our SDK and makes a product we never even considered. Honestly, that would be the best outcome
The less exciting part is getting the core solid enough for that. Reproducibility, verification, compatibility... all the stuff nobody wants to tweet about 😂
But if we get that right, the most interesting RHOOK applications might not even be ours
That's what we're building toward
Finally got the RHOOK Developer Alpha source on GitHub
Python API, CLI, Hookr adapter and tests are there. We also replayed a real Hookr block with LP Rewards changed from 100 to 50. One buyer got ~0.5% more RHOOK
Native replay kit isn't public yet, but we're getting there
github.com/USBVadik/rhook/tr…
Hookr made it to #1 on @TradePools . Now we want RHOOK to become #1 on @Hookrfun
And we want to earn that spot by building something genuinely useful. Counterfactual Execution, a solid SDK, and tools other devs can actually build with
149 pools already. We're just getting started
Anyone can figure out that lowering a fee component will probably give a buyer more tokens. You don't need a new protocol for that
But that wasn't the interesting part of our experiment with a @Hookrfun pool
We wanted to find out if we could take a block that already happened, change one rule, and actually execute the entire block again instead of just calculating what the difference should be
We took block 93251803 on Robinhood Chain and first replayed all 7 ordered arrivals through native Nitro, including the system transaction. The state root, receipts root and block hash matched the original chain
Then we went back to the same historical checkpoint, changed one parameter in Hookr's RulesConfig (LP Rewards: 100 → 50 bps), and executed those same arrivals again. The transactions, their order and the contract code were left untouched
The buyer's net $RHOOK output was 0.504% higher in the counterfactual branch
That's roughly what you'd expect from lowering the fee. But we didn't calculate the result from a formula. We got it from the new execution's Transfer events, along with its own receipts, gas usage and state commitments
Both native executions took about 1.27 seconds in total. Our unified Go/Nitro worker also reproduced the exact results of an earlier specialized experiment without needing a rebuild for the new parameter
Now imagine asking a less obvious question
What if a hook had been disabled during a real block? What if a liquidation threshold had been different? Would the same transactions still succeed? What would the resulting state look like?
Those are the kinds of questions we want developers to explore with RHOOK
We documented the experiment, results and execution commitments on GitHub if you want to dig into the details:
github.com/USBVadik/rhook/bl…
yeah yeah, we know 😅
we've been talking a lot about what RHOOK could do. fair enough. we're working on the part where we actually show it
but the rabbit hole goes pretty deep
what if LP rewards were turned off during a real swap? what if a buy limit never existed?
or here's one we really want to explore: take a real DeFi exploit, add a safety rule, replay the same transactions. does it actually stop the attack, or does something else happen?
that's the kind of stuff we want to find out
starting with @Hookrfun pools. we'll show the receipts when they're ready 👀
Replying to @WG1688
haha tell Boss Peng he doesn't have to wait anymore! 😂🤝
We've already addressed the old 0.004 ETH swap limitation by adding two new liquidity pools without the POT restriction
There are two ways to trade larger amounts now: through Uniswap, which can route swaps into the new pools, or directly through Hookr, which also supports larger swaps through the original legacy pool
Of course, actual liquidity and slippage still matter, but that old restriction is no longer the blocker 🙌
Replying to @caisheng1949
Good news, this is already fixed! 🙌
The old ~0.004 ETH swap restriction was caused by the POT hook on our original liquidity pool
We've since added two new pools without POT, so larger swaps can now go through them. You can use Uniswap to aggregate the routes, or swap directly through Hookr, where even the original legacy pool supports larger trades
Just keep an eye on price impact for bigger orders, as usual
No need to wait anymore 🤝
Blockchains tell you what happened
RHOOK asks a harder question:
Would a transaction still succeed if part of its history were different?
Replay the alternative. Verify the outcome.
The bigger idea? Make that answer a condition for execution
Counterfactual Execution 🪝
Small $RHOOK update 🪝
Enhanced Token Info on DEX Screener is paid for! ✅
Meanwhile, we're building the Counterfactual Execution SDK and analyzing real Hookr market transactions as we work toward our first integration.
Still early. Still building.
🌐 robinhook.tech
This is a recorded demo of one bounded historical experiment - not a live replay service or a public native SDK yet
Next we're building a better developer workflow: ask several questions about the same alternative world without replaying it every time
Why care?
Imagine asking: “Would my swap still work if something earlier had gone differently?”
That's what RHOOK is exploring
This is one recorded, bounded case - not a live tool for any transaction yet
Of 279 later transactions, exactly 1 changed its SUCCESS/REVERT status. The other 278 kept theirs.
Not a bigger domino effect than Genesis
The progress: 2 separate EVM engines agreed on the replay, and one Claim passed verification under fixed rules
We replayed real Robinhood Chain history, changing one earlier encoded amount to zero - in an alternative version, never on the live chain
Then we checked the next transaction:
✅ REAL: SUCCESS
❌ ALTERNATIVE: REVERT
Genesis: 16 of 317 later transactions changed their SUCCESS/REVERT outcome after one historical intervention
That was the domino-effect experiment
Counterfactual asks a different question:
Can we check whether ONE specific transaction would still work?
What if one action in a blockchain's past changed which later transactions still work? 👀
Genesis showed the ripple effect.
Now RHOOK's second public demo asks: which exact transaction breaks - and can we verify it?
robinhook.tech/counterfactua…








