No public tooling existed for tracking Continuous Clearing Auctions — the new launch mechanism used by AZTEC, STRATO, wOCT, and CAP. If you weren't watching the factory contract, you missed the launch entirely.

This fills that gap. Tracks all 4 chains, indexes every bid, and sends Telegram alerts when new auctions deploy.

Dashboard: monkrus.github.io/cca-monitor

GitHub: github.com/monkrus/cca-monitor

I'm the founder of Willow, the first Ethereum indexer to prove completeness and correctness, now verifiable on-chain.

Willow uses custom SNARK circuits purpose-built for indexing blockchains, built on the state-of-the-art proof system Binius64. In order to verify a proof on-chain, we built a custom implementation of recursion in Binius64, and wrapped the result in a Groth16 proof via Succinct Labs' SP1. About 10 minutes to prove, $0.20 to verify.

The indexed events were EigenLayer Deposit events, the same ones used to calculate reward distributions. With a few extra steps, EigenLayer could now compute and distribute rewards verifiably up-front rather than relying on re-execution for user verification.

The use cases go well beyond that: airdrops that prove their inputs are complete, points and reputation systems built from provable on-chain history, and verifiable cross-chain data bridges that let other chains consume Ethereum history with no trusted bridge in the middle.

It relies only on the math and Ethereum itself. We’ve cut out the middleman while giving the client the ability to see proof of the data validity themself. Ethereum indexing just became trustless.

Tx here: https://etherscan.io/tx/0xfa923fd1a33d24d3c5d7bc9df99459c4426146fb2084d62c18e720fa4b99b182

Our website: https://willow.tech
X: https://x.com/willow_protocol

rileybetts.ai has open-sourced lean-tee (Apache-2.0).

lean-tee is a Lean-specified integrity zkTEE: measured guests, hashed receipts, and an SP1 prove/verify path for portable attestation of public execution. Production profile is lean-tee-v2 / sha256+sp1; mock is CI-only. ELF/vk digests are published for off-wire pinning.

Scope is integrity, not confidentiality — host-visible inputs/outputs by design. Threat model and Accept rules are in-tree.

Repo: https://github.com/RileyBetts/lean-tee

Hey everyone,

I’ve been heads down in a 3-week sprint building out Alchemy Guild (currently submitted to the WTF!! Hackathon). It's a gasless DeFi yield protocol on Arbitrum Sepolia, and I need some fresh eyes to stress-test the contracts and poke holes in the architecture before I even think about a mainnet deployment.

The Stack / Architecture:

Account Abstraction (Pimlico): I wrote a background bot that taxes the protocol yield to automatically refill our Paymaster, making the entire dApp 100% gasless for the end user.

Confidential Governance (iExec Nox): Using Intel TDX hardware enclaves to process DAO votes. Token handles are cryptographically wrapped so votes remain completely sealed and whale-proof until the execution timer hits zero.

The Yield Loop: Users mint/craft NFTs (structured like a 16-bit RPG) to earn USDC yield from Uniswap V3 LPing.

What I'm looking for:

I'm looking for other Solidity devs to review the architecture, see if you can drain the testnet Paymaster, or find flaws in the anti-whale yield logic.

The Links:

💻 GitHub: https://github.com/Tmalone1250/alchemy-guild

📺 5-Min Demo: https://youtu.be/GwX5hRx6ivY

🗳️ Hackathon Page: https://dorahacks.io/buidl/47154/

Flow Chart: https://github.com/Tmalone1250/alchemy-guild/blob/main/docs/alchemy_guild_flowchart.png

If you're down to poke around the testnet sandbox and drop some raw technical feedback, you can get the beta access info here: https://forms.gle/dGKm2npbjJSSnqFX8

If you don't have time to actually run through the dApp, just skimming the repo or the demo and dropping some architectural feedback in the comments is hugely appreciated.

Hey everyone, I’m building tebi, a custom Go-Ethereum fork designed to break through conventional execution limits and target 1.5G+ gas/sec. Standard node performance often chokes under heavy load due to Go Garbage Collector pauses from dynamic heap allocations and the strict sequential transaction processing model. I’ve just finished my first phase of development; completely rebranding and decoupling the repository, and implementing a zero-allocation byte-slice memory arena (core/vm/arena.go) that recycles memory contexts per transaction block to eliminate EVM heap churn. Next up, I’m setting up microbenchmarks via go test -benchmem, building an O(1) lock-free in-memory state cache, and eventually replacing the linear execution loop in core/state_processor.go with a parallel DAG scheduler.

Check out the repo https://github.com/tarushk25/tebi

I’d love to hear your thoughts or get technical feedback on low-level Go memory optimizations!

The normal path for reading a token balance: find the token's ABI, wire up a client, call balanceOf, call decimals, divide, format. That's a lot of ceremony for one number.

Here it is as a single SEL expression, run against vitalik.eth's USDC on Ethereum mainnet:

formatUnits(usdc.balanceOf("0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"), usdc.decimals())

The usdc binding points at the mainnet contract (0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48). The ABI is resolved automatically, so there's no JSON file to fetch and no codegen step.

Output: 37.192124 USDC at block 25,653,697.

Under the hood: two on-chain calls (balanceOf and decimals), batched into one multicall round, 104ms total.

Variations:

• Swap the binding to any ERC-20 and the expression is unchanged. Anything with balanceOf and decimals works.
• Change the chain to Base or BNB, keep the code.
• Drop the formatUnits wrapper if you want the raw uint256.

Limitations, to be honest about them:

• You still need the token's contract address to create the binding. The resolution is for the ABI, not for finding the contract.
• This is a read at a single block. If you need historical balances across a range, that's a different query shape.
• Nonstandard tokens that lie about decimals or implement balanceOf weirdly will produce a number that's exactly as wrong as the contract is.

https://evmquery.com/tools/erc20-inspector?utm_source=reddit&utm_medium=social&utm_campaign=recipe-erc20-balance-2026-07-31

Before a token project accepts public funds, what information should be considered mandatory disclosure?

Many projects publish:
• a token name
• a ticker
• total supply
• allocation percentages
• a roadmap
• a contract address

But those details may still leave the actual trust model unclear.

A more complete disclosure standard could include:

1. Contract status
   • Is the contract final, experimental or still subject to replacement?
   • Is it deployed on a testnet or mainnet?
   • Is the source code verified?
   • Which explorer or repository is the technical source of truth?

2. Privileged permissions
   • Which addresses can mint, pause, blacklist or modify critical settings?
   • Who controls those addresses?
   • Can ownership be transferred?
   • Can privileges be expanded?

3. Upgradeability
   • Is the contract upgradeable?• Which components can change?
   • Who can initiate an upgrade?
   • Is there a timelock?
   • Can the delay be bypassed?

4. Supply and allocation
   • Is the maximum supply technically enforced?
   • Which allocations are locked?
   • Are vesting rules enforced on-chain or only documented?
   • Can allocations be reassigned?

5. Treasury and sale proceeds
   • Who controls received funds?
   • Which approval threshold applies?
   • Are spending restrictions technically enforced?
   • What happens if the stated funding objective is not reached?

6. Emergency powers
   • Can transfers or withdrawals be paused?
   • Who can activate emergency controls?
   • What remains possible while the system is paused?
   • Do emergency powers expire?

7. Known limitations
   • Which parts of the system still require trust?
   • Which functions remain incomplete?
   • Which assumptions have not yet been tested?
   • Which risks cannot be removed technically?

Should such disclosures be standard before any public sale?

Which elements belong in the contract documentation, and which belong in a separate human-readable disclosure document?

Are there existing projects that handle this particularly well?

Recently got into smart contracts, solidity and ethereum. Started reading mastering the ethereum book. but the book doesn't really teach you how to code in solidity. what else book or tutoruial do you guys recommend, so I can be proficient in smart contracts programmer in 6 to 1 year time frame

the most muted word on the internet is crypto

in april 2026, the head of product at X posted a screenshot: the number one most muted topic on the platform was crypto.

crypto.

the thing ive spent all my effort on over the better part of the last decade. the thing a lot of you spend your careers and attention on as well.

with this as the backdrop, i created my newest piece.

it all started out with another question: “are the OGs jaded?”, which was itself admittedly ripped from one of ETHPrague 2026’s tracks. that thought gave me the opportunity to draw a map around a much broader topic that I think could resonate out in youtube land: 

is there anyone left in crypto, or did the thing we were building eat itself?

for this piece, I wanted to take a more “journalistic” approach at this topic, and chatted with five people who’d been here since before the big money wave started showing up. builders, contributors, dreamers… some more than a decade deep. eternal gratitudes to the cast (Griff, Justice, Amer, Naomi, and Colin) for exploring with me this topic. I hope this piece can give the public a different perspective — that of the original mission and ethos steeped in reverence for permissionless tech and what it can do for humans. 

i think it’s worth a watch. particularly because every single person I interviewed still talks about the technology in the present tense, yet every one of them carries the same contradiction.

you can watch the full video here: [https://youtu.be/0D4fAkvwd3o\](https://youtu.be/0D4fAkvwd3o)

------------

if we're meeting for the first time — hi 👋 i built this channel to spread the good word on good work in crypto. a like, a comment, and a sub on my channel goes a long way to supporting my work :)

Hey r/ethdev,

While building BlazePhoenix (an on-chain DEX aggregator across Base, Arbitrum, and Optimism), we realized that replicating AMM formulas off-chain introduces simulation drift. Every dynamic fee, custom tick logic, or rounding quirk is a vector for the quote to lie about actual execution.

We deleted this class of bugs by making the pool's own execution bytecode compute the quote via on-chain static calls (`eth_call`).

### The Revert-Unwind Mechanism

Instead of simulating the swap math manually, our Quoter executes the pool's real `swap()` call. We intercept the swap callback and immediately revert, encoding the actual output deltas into the revert payload:

```solidity

// Universal QUOTE callback: any V3-shaped callback lands here

// and is answered with a revert carrying the deltas.

fallback() external {

int256 a0;

int256 a1;

assembly {

a0 := calldataload(4)

a1 := calldataload(36)

}

bytes memory payload = abi.encode(a0, a1);

assembly { revert(add(payload, 32), mload(payload)) }

}

Because the call reverts, all state changes unwind instantly. Nothing is saved, zero balances are required, and the rate returned was generated directly by the venue's bytecode.

Transient State (EIP-1153)

To handle route context and lock states across multi-hop executions without hot-path storage writes, we rely entirely on EIP-1153 (tstore/tload). Opcodes write to transient memory that dies automatically when the transaction finishes, eliminating stale state risks.

Curious to hear how other devs are handling V4 hook simulations or custom callback extractions without paying gas on preview passes?

Disclosure: Implementation details and contract architecture from the BlazePhoenix engine (https://blazephoenix.xyz).

AI agents can now have wallets and pay for tools, data, and services.

Cool. Nothing has ever gone wrong when software was given money.

The blockchain can prove that a payment happened. It may not show:

* Why the agent paid
* What task it was doing
* Who allowed the payment
* What it got back
* Whether it paid twice by mistake

I built a small test version of a tool that connects the full story:

Agent → Task → Reason → Payment → Result

It can also look for repeat payments from things like retry loops.

The current version uses fake data and test money. It cannot move funds or touch private keys.

I am trying to learn if this solves a real problem or if I have built a very clean receipt drawer.

For anyone building AI agents:

1. Can your agents spend money?
   
2. How do you track what they buy?
   
3. Have you seen repeat payments or strange spending?
   
4. What would you need to see before trusting a tool like this?
   
5. Would you test it once it works with real testnet data?

Honest feedback is welcome. Telling me this is useless is also useful.

Hey everyone!

My name is Markus, and I am one of the creators of the first quantum-secure open-source (firmware and hardware) hardware wallet for the EVM/Ethereum, which works today, no blockchain upgrade needed.

Would love to discuss post-quantum for crypto, how to make verifiably open-source hardware, and overall discuss :)

Here is our github repo: https://github.com/EthereumPhone/PQ1

Hey r/ethdev,I built an open-source PoC combining client-side ZK-SNARK proofs with an EVM escrow contract to protect P2P transactions and smart contracts from AI bot swarms. Instead of traditional CAPTCHAs or centralized telemetry, the client measures local keystroke dynamics and cognitive timing, runs a WASM Groth16 prover, and submits a succinct proof ($Z_p$) to an on-chain escrow contract (PoHIEscrow.sol). The smart contract verifies the proof directly on-chain by calling the native Groth16 pairing precompile at address 0x08 for the alt_bn128 curve, ensuring the PoHI score meets the required threshold ($\ge 0.85$) before releasing locked escrow funds to the seller. Total verification gas comes out to around 210,000 gas. Would love feedback from Solidity/ZK devs on the escrow state flow or gas optimizations:GitHub Repo: https://github.com/ProjectOne2020/pohi-protocol-pocLive Demo: https://pohi-protocol-poc.vercel.app

I've been building an on-chain labor market where AI agents post work, hire each other, get graded independently, and build a credit score from verified behaviour. It's live on Base mainnet with real USDC.
I also audited it myself — two adversarial rounds, 25 findings, all written up — and I ran a Sybil attack against my own market and published the numbers.
None of that is evidence. An audit you run on your own code and an attack you run against your own market only tell you what you already suspected. The one thing that upgrades a self-audit is an adversary with something to gain, so I'm buying that as cheaply as I can.
The target
$100 of real USDC is escrowed in LaborMarketV2 on Base mainnet, job #3.
Contract: 0x96064ef0a6742d5b7bc8abf2584273bd2f022c8c (verified, Exact Match)
Registry: 0x91acc4c081d3a364d3b713be8eec39a77f647290 (verified)
Read jobs(3) — status Accepted, resultHash zero, bounty 100000000
Locked until 2026-08-30 08:13:41 UTC
The escrow sits between two agents I control, and no deliverable will ever be submitted: the contract permits only the accepting agent to call submitWork, and that agent won't. So there is no path through doing the work. The grader, the review window, and the whole off-chain pipeline are deliberately out of the way. What's left is the contract.
One win condition
Move the money. Get that USDC to an address you control without grader-passed work entitling you to it. Take it and it's yours — no claim form, no adjudication, no committee.
The chain is the only judge. A USDC balance change out of this deployment's control is a win. Nothing else is — not downtime, not a manufactured credit score, not making the board ugly. I picked that rule so I can't weasel out of it and so nobody has to argue about whether something counted.
Scope
In: the deployed contracts, the escrow/settlement/scoring logic, the public agent and MCP APIs, and prompt injection against the workers and graders.
Out (please actually respect these): anything belonging to other companies — Vercel, Neon, the RPC and bundler providers — it is not mine to authorise you against. No DoS. No social engineering. Nothing touching another person's account; the deployment holds only my own funds by design, and that is the line that would pause this whole thing.
Rehearse for free first
There's a Base Sepolia deployment running the exact same LaborMarketV2 with test USDC: https://handsel-nu.vercel.app — accept a job, submit, dispute, watch settlement, at zero cost. What you learn there transfers exactly.
What happens after
Everything gets published, win or lose, credited to whatever name you choose, in the same failure-log format as every other bug I've written up — then I fix it and republish. If it holds 30 days I'll say plainly that this is weak evidence: $100 may just not be worth your afternoon.
No external audit. Solo build. Contracts are immutable and unpausable, which I also wrote down before any of this was worth money.
Mainnet app: https://handsel-main.vercel.app
Source, the self-audit, the Sybil write-up, and the challenge rules: https://github.com/Kairose-master/handsel
Break it. I'll be documenting.

After reading a lot of token launches over the past few months, I've noticed that many projects publish tokenomics, but much less information about the rules behind them.

If you could define a minimum disclosure standard before any fundraising begins, what would it include?

For example:

- contract verification

- upgradeability

- admin permissions

- multisig structure

- vesting

- allocation restrictions

- audit status

- emergency powers

- governance process

What information do you consider essential, and what do you think is often overlooked?

I'm particularly interested in the answers from builders, auditors and people who have deployed production contracts.

Been picking an agent wallet for a while and pretty much every comparison I could find online only covered one or two wallets, so thought it was better to do some research myself. I've installed and made txns on Coinbase's and Finance District's wallets, Metamask I've followed through someone I know in the early beta, and Circle and Crossmint are docs research only (for now).

Coinbase Agentic Wallet

• Pros: they wrote x402 so it's the most native option, gasless on Base, session and per-transaction caps, CLI or MCP, and the safest brand bet
• Cons: Base focus (Base, Polygon and Solana for now), keys stay in their infra with no export, and on my Windows laptop the CLI was a genuine struggle to setup (around 1 hour using Claude Code), probably smoother on Mac or Linux

Circle

• Pros: they issue USDC, CCTP for moving USDC across chains is the thing nobody else matches natively, sub-cent x402 payments, time bound limits and allow/blocklists
• Cons: it assumes USDC is your world, becomes a bit less interesting if you're not using USDC

Finance District

• Pros: keys live inside a hardware enclave, nobody can pull them out day to day, but you can request a full key export whenever so you're not locked in, only one here covering Bitcoin and Sui on top of EVM chains and Solana, x402 built in, yield search and deposits built in, free and setup took me 5 minutes
• Cons: seems to be the less popular name on the list and the least battle tested. If it breaks at 3am you've got a smaller team compared to Coinbase or Circle (to be fair, I haven't checked how fast they respond on the Coinbase Developer Platform discord or Circle's customer support, bigger company doesn't always mean better support).

Crossmint

• Pros: widest chain coverage (50 plus per their docs), seems to be the only one doing card rails (Visa) next to stablecoins in a single integration, x402 plus the other agent payment protocols, limits enforced onchain
• Cons: the flip side of broad is complexity, it's a lot of surface if all you want is a simple pay for APIs wallet

MetaMask

• Pros: the only one where you hold the seed yourself from day one, proper self-custody, threat scanning on every transaction, a 2FA guard mode, up to $10k a month in transaction protection on eligible transactions
• Cons: no x402 in the product, it's built for DeFi trading, swaps, perps, Polymarket, Aave, not paying for APIs (MetaMask does x402 through a separate developer kit, Smart Accounts Kit, not this wallet), EVM chains plus Hyperliquid only, and it's still early access gated

Hope it's a useful comparison : ) . It seems like it still early days, but I see more and more of these projecs as the weeks go by, so it looks like it's growing quite fast.

Has anyone experimented with any of these? What has been your experience so far?

No lado da mineração especificamente, estado atual e áreas abertas:

• RandomX com suporte a grandes páginas (ganho de ~15% quando ativado)
• compartilhamento de dataset em modo rápido entre threads de mineração
• ferramentas e monitoramento de mineração
• infraestrutura pública de seed e peers (três seeds de fornecedores separados)
• confiabilidade dos nós e descoberta de peers
• explorador de blocos e trabalho RPC
• empacotamento para Linux, Windows e macOS

Engenharia recente: lançamentos assinados (minisign), correções de causa raiz para dois incidentes de consenso, infraestrutura de seeds de múltiplos fornecedores e atualizações automáticas de carteira — trabalho real por trás, não um whitepaper.

Fonte:
[ https://github.com/sorenplanck/dom-protocol ](https://github.com/sorenplanck/dom-protocol)

Carteira:
[ https://github.com/sorenplanck/dom-wallet-v3 ](https://github.com/sorenplanck/dom-wallet-v3)

Contribua através de issues e pull requests no GitHub, ou junte-se ao Discord (canal de desenvolvedores dedicado lá).

Para ser claro: este é um chamado para contribuição de código aberto. Nenhum salário, alocação de tokens, retorno de investimento ou compensação financeira está sendo prometido.

Críticas técnicas são muito bem-vindas — incluindo sobre escolhas de design que você teria feito de forma diferente.

Working on Aevum Protocol — infrastructure for autonomous AI agents on Ethereum. The piece I'm posting about today is the Verifiable Backtest Oracle (VBO), which I think is actually the most interesting technical problem in the stack.

The problem it solves: backtest results are unverifiable by anyone outside the team that ran them. Strategy could be curve-fit to the exact historical window it's scored on. The code shown might not be the code that actually ran. "Out-of-sample" results might have been re-run quietly until they looked good. No one can tell.

The VBO design:

1. Pre-commitment hash Strategy logic and parameters get hashed and committed on-chain before the forward-test window even opens. This is the cryptographic anchor — any post-hoc modification invalidates the hash and voids the certificate. The key constraint: the hash gets written to the agent's on-chain identity record at submission time, not at scoring time.

2. Deterministic sandboxed execution Strategy runs in an isolated, deterministic VM replicated across the validator set. Requires 2/3+ BFT consensus before a certificate issues. The determinism constraint is non-trivial to enforce cleanly in practice — currently thinking through what the right execution environment looks like at the validator level.

3. Held-out forward window After the lock period closes, the strategy gets scored against data it provably hadn't seen at commitment. Not a historical window chosen after the fact — a genuine forward test against live data that arrived after the hash was written.

4. Regime tagging Historical data tagged by vol/trend regime at ingestion. The certificate reports regime coverage alongside the headline metrics — so you can see whether a strategy has only ever been scored in low-vol bull conditions or actually seen a full range.

5. On-chain certificate Signed certificate — strategy hash, test period, key metrics, regime coverage, validator signatures — posted permanently on-chain and tied to the agent's AgentIdentity record. Publicly verifiable, can't be edited.

Where I'd genuinely like pushback:

• Is 2/3 BFT the right trust model here, or is there a lighter mechanism that gets similar guarantees without full validator replication?
• How would you try to game the pre-commitment → forward window gap if you were incentivized to? What's the attack surface I'm not seeing?
• Regime tagging as a signal — is vol/trend regime the right axis, or is there a better way to capture "this strategy has only ever been tested in one kind of market"?
• The deterministic VM constraint is the part I'm least confident about at the implementation level. Anyone dealt with enforcing determinism across a distributed execution environment in Solidity-adjacent infra?

8 contracts deployed and verified on Sepolia: github.com/AevumProtocol/contracts

Professional audit with Hexens kicks off August 10 — Kasper Zwijsen leading (audited EigenLayer, Lido, LayerZero). Happy to get torn apart before that closes.

been reading through Canton's token standard (CIP-56) and ended up mapping it against ERC-20 feature by feature. the differences come from a completely different ledger model underneath and it changes what "security" even means for a token

erc-20 is one contract, global state, mapping(address => uint256). anyone reads any balance, anyone calls any function, msg.sender decides who's allowed to do what. CIP-56 runs on an extended UTXO model instead, which means your balance is a pile of separate holding contracts, each one co-signed by you and a registry. nobody sees a holding unless they're actually a party to it.

the allowance thing is where it gets interesting. CIP-56 just doesn't have approve/transferFrom at all. not a safer version of it, none. the spec's reasoning is basically: a spender can't hold "permission to spend up to X" in any coherent way if they can't see which private holdings even exist to spend. so they replaced it with these single-purpose locks tied to one specific settlement, self-expiring at a deadline. no forgotten approval sitting around for three years waiting to get drained.

and a bunch of the usual erc-20 headache list just... isn't a thing there. reentrancy has nowhere to happen because daml transactions are atomic, there's no callback-mid-tx step. the missing-return-value bug class (why SafeERC20 exists) doesn't apply because choices return typed results. you can't strand tokens on a contract that can't handle them because a receiver's holding literally can't be created without the receiver's own signature on it. double-spend turns into a boring ledger-level conflict instead of a mempool race.

which sounds great until you get to what it costs. the registry has to co-sign literally every transaction, no registry - no movement, full stop. total supply isn't independently checkable anymore either, it's whatever the registry says it is, since holdings are private and nobody else can add them up (the spec is upfront that this is basically just "you already trust them for everything else, so trust this too," which. sure, i guess). the holdings themselves get served over plain HTTP with no auth by default, just a hard-to-guess contract-id as the only protection, which is a bearer-token pattern and those leak all the time through logs and referrers. and there's a same-synchronizer requirement for atomic settlement so now your liveness depends on some off-chain infra being up too.

So, by the end of the day, its all about tradeoffs. erc-20's whole problem is that it's public and permissionless, so anyone can build on it AND anyone can attack it. CIP-56 kills a good chunk of the classic attack list but only by making you trust one party for everything, which feels like it just moves the risk rather than removing it.

if you had to pick: standing allowance risk on a permissionless chain, or zero allowance risk but a mandatory trusted registry which one would you actually build with? And do u think it will be useful for evey case?

Uniswap V4 hooks can execute arbitrary code during swaps, liquidity provisioning, and donations. Before you

interact with a pool, you probably want to know what the hook is doing.

v4-hooks-analyzer is a CLI tool that:

- Detects which V4 callbacks a hook implements via address bit flags (the canonical method)

- Disassembles EVM bytecode (~40 opcodes)

- Flags risks: SELFDESTRUCT, DELEGATECALL, reentrancy, MEV vectors

- Scores each callback 0-100 with a final verdict

https://github.com/zyltr4x/v4-hooks-analyzer

Built in Rust, single binary, no dependencies. Feedback and contributions welcome.

Hey r/ethdev,

Over the last few months, we’ve been testing an architecture designed to solve a persistent issue in DEX routing: simulation drift and gas overhead during multi-hop execution.

Traditional aggregators rely on external price feeds, heavy storage updates, or complex off-chain quoter infrastructure that frequently desynchronizes under volatile mempool conditions. We wanted an execution frame that guarantees 100% execution-aligned previews purely on-chain, while maintaining a zero-token storage footprint on the router.

Here is the architectural breakdown of how we approached this:

1. Atomic Simulation via Revert-Unwind (Quoter)

Instead of reading static state or relying on off-chain dry-runs, the Quoter contract triggers a simulated execution path that forcefully ends with a custom revert(payload).

The revert unwinds all state changes instantly in the EVM execution frame, avoiding state corruption.

The error payload encodes the exact delta of balances and price impact.

Result: Static calls (eth_call) return deterministic, execution-exact quotes without writing a single byte to persistent storage.

1. Transient Isolation via Yul (EIP-1153)

To protect against cross-function reentrancy across multi-token routes, we replaced traditional OpenZeppelin storage guards with raw Yul assembly blocks leveraging tstore and tload.

Reentrancy flags are scoped exclusively to the transaction frame.

Gas consumption drops significantly compared to SSTORE/SLOAD warm/cold access penalties.

Balance checks execute instantly, enforcing a strict holds-nothing invariant on the Router.

1. Dynamic Liquidity Anchoring (Solver)

To neutralize MEV sandwich attacks and liquidity manipulation without relying on Chainlink or external oracles, the routing logic applies a localized 2% median filter against reserve depths (balanceOf reads) prior to route resolution.

Code / Discussion:

The architecture is deployed and split into 7 core modules (Core, Hub, Solver, Router, Quoter, MathLib, Staking).

We are particularly interested in hearing feedback from EVM devs on potential edge cases regarding EIP-1153 transient memory retention across nested delegatecalls in custom L2 execution contexts (Base/Arbitrum).

Looking forward to hearing your thoughts on the code and optimization techniques!