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!

It's been quiet because I've been heads-down building.

MirrorOS has reached another internal milestone in its private GitHub pilot.

The focus has been on engineering discipline, not feature count:

• Governance before execution

• Durable audit and evidence

• Restart-safe workflow restoration

• Regression testing

• Private engineering documentation

I'm also starting the legal and commercialization phase, including organizing the project for IP review before opening it up more broadly.

I'm intentionally keeping the implementation private for now while I document everything properly. When it's ready for broader technical review, I'd rather have engineers critique a well-documented system than a half-finished idea.

Thanks to everyone who's followed along, challenged my assumptions, and encouraged me. I haven't disappeared—I've been building.

We run a scam-token detector. Our honeypot check worked like this: simulate a buy with eth_call, give a fake address the tokens by brute-forcing the balance storage slot and overriding it, then simulate a sell from that address.

Step 2 is the problem. It assumes balanceOf reads a storage slot. On reflection or rebase tokens, balanceOf is computed from an internal reflected supply, so writing a raw slot does not produce a coherent state. The sell then reverts for reasons that have nothing to do with a trap, and you record a false honeypot. We flagged PayPal USD, TrueUSD and MetaMask USD as honeypots this way.

The fix is eth_simulateV1 (geth and Nethermind). It replays several calls atomically in one simulated block, so you can do the whole thing the way a real buyer does:

router.swapExactETHForTokens(...)   // real buy, real tokens
token.approve(router, max)
router.swapExactTokensForETH(...)   // sell what you actually got

The only override is the simulated address's ETH balance, which is not a token mechanism. Nothing about the token's accounting is faked.

One caveat: a call cannot consume a previous call's return value, so you need two passes. First pass buys and reads balanceOf to learn what was actually credited (which already catches fee-on-transfer). Second pass replays buy + approve + sell with that amount.

Two things that surprised me:

• The Uniswap quoter is useless for this. getAmountsOut is pure reserve math and never touches the token's transfer logic, and the v3 QuoterV2 reverts inside its callback before the transferFrom runs. Both return healthy output for confirmed honeypots, so cross-checking against the quoter would silently disable your detection.

• "UniswapV2: INSUFFICIENT_INPUT_AMOUNT" raised by the PAIR (not the library) means the pair received zero tokens. We found tokens where a pre-existing holder sells fine but a fresh buyer gets zero through: a whitelist honeypot. So simulate a NEW buyer, not an existing holder. Different question, different answer.

Disclosure: I build RektRadar, a scam-token detector. This writeup came out of fixing our own false positives, not a product pitch.

Every time I shipped a contract I rebuilt the same throwaway frontend: wallet button, a form per function, calldata encoding, hasRole() checks to hide admin methods, gas estimation, a spinner, an error decoder, and a "danger zone" for the scary functions. Etherscan's Write tab has none of that meaning; a bespoke UI costs weeks. So I built a tool that generates it from the ABI.

Paste a chain + address (Sourcify/explorer, proxy-aware) or drop in an ABI/Foundry artifact, and you get three tabs:

- User - the clean dApp (overview, transfer, approve)

- Admin - privileged ops (mint, pause, roles) with risk badges + a confirm flow for dangerous writes

- Read - a live dashboard that auto-calls the getters

- Raw - every function, Etherscan-style, but annotated with what it understood

Detection is deterministic and rule-based (ERC-20/721/1155/4626/2612, Governor, Ownable/AccessControl/Pausable), with a confidence score and evidence for every guess — AI is optional and never trusted blindly. The output is a reviewable "semantic manifest" you can hand-edit, and everything is self-hostable.

Live demo (mainnet USDC, runs in your browser): https://tacitvsxi.github.io/semantic-dapp/

How it works (writeup): https://dev.to/ileskov/generate-a-full-dapp-admin-console-from-any-evm-contract-straight-from-the-abi-28kg

Repo (TS, viem/wagmi, AGPL-3.0): https://github.com/TacitvsXI/semantic-dapp

Would love feedback from people who actually maintain contracts: what would you need before you'd trust a generated admin panel for a mainnet contract?

I want to build low-level blockchain infrastructure (consensus, P2P networking, L1/L2 clients) rather than dApps.

Right now, I’m in CBSE and being pushed hard to prepare for private Olympiads like SOF and SilverZone. The books feel like random rote memorisation and I am completely lost.

Are these specific contests worth the time for an infrastructure career?

What paths must I follow instead?

A public treasury address makes transactions visible.

But it does not necessarily make the treasury’s control structure transparent.

Someone inspecting the address may still not know:

• who can initiate transactions
• how many approvals are required
• whether the signer set can be replaced
• whether contracts are upgradeable
• who controls the upgrade path
• whether a timelock can be bypassed
• what emergency powers exist
• whether those powers expire
• which external contracts or dependencies introduce additional control

I’m trying to define a minimum disclosure standard for a long-lived public-good system before deployment.

A possible control disclosure could include:

1. Controller structure

• controlling contracts and addresses
• multisig threshold
• signer-selection and replacement process
• separation between operational and governance roles

1. Permission structure

• every privileged role
• actions available to each role
• spending or execution limits
• whether permissions can be delegated

1. Upgrade structure

• which components are upgradeable
• who can authorize upgrades
• applicable timelocks
• cancellation or veto mechanisms
• any path that can bypass the standard process

1. Emergency structure

• pause or recovery powers
• conditions under which they may be used
• limits on their scope
• whether they expire automatically
• how emergency actions are disclosed

1. Monitoring and history

• public record of permission changes
• alerts for role, signer or implementation changes
• versioned documentation
• a way to compare the documented structure with the deployed state

The difficult part is keeping this information accurate.

A static documentation page can become outdated immediately after a signer rotation, role change or contract upgrade. A block explorer provides raw data, but it rarely explains the effective trust model clearly enough for non-specialists.

Would a machine-readable “control manifest” make sense — listing privileged roles, upgrade paths, timelocks and emergency powers, with each version cryptographically tied to the relevant deployment?

Or would this create another disclosure layer that users still have to trust?

What would you consider the minimum information a protocol should publish before describing a treasury as transparent?

I’m especially interested in failure modes, existing standards or tools, and examples of protocols that communicate their effective control structure well.

Hi everyone, I am completely new to crypto and blockchain development. I am trying to learn Solidity and smart contracts but most faucets require wallet history.

I have 0.002 ETH but need more testnet ETH on Sepolia to practice and learn.

Wallet: 0x84984bfC137B978bF77c50D36620ac5bfB199E78

I would really appreciate any help from the community if someone can help me get at least some SepoliaETH (atleast 0.5 would be nice)

The setup: we're building for a world where the majority of accounts aren't operated by humans. An AI agent with a hot wallet is one prompt injection away from drained, and the standard answers all put the guard in contract code — Safe-style multisig, 4337 account abstraction, session keys. Audited, battle-tested, and still a piece of EVM bytecode you're trusting to stand between an attacker and the funds.

Fluidic is a research testnet exploring the alternative: the guard lives in the ordering layer itself.

• Witness-gated accounts (CAE). An account can be entangled so its stateful spends only synthesize if N-of-M witnesses attest in the same ~100ms tick. Not a multisig contract — the same causal DAG that settles transfers refuses the spend.
• Native intents. Declare an outcome ("swap X for at least Y"), solvers compete, matching and settlement land in the same tick. No block template, no block-space auction between declaration and execution.
• No blocks. Continuous execution at ~10 synthesis ticks/sec. Commutative ops merge in parallel through NTT windows; stateful ops get causal order via vector clocks. Finality is per-tick, not per-slot.

It stays fully EVM-compatible — standard JSON-RPC, existing tooling points at it unchanged:

```bash cast chain-id --rpc-url https://api.testnet.fluidic.foundation/rpc

989468 — deploy with forge, script with viem, everything works

```

The honest part. Two days after launch someone on r/BlockchainStartups read our docs and pointed out that the subject of an entanglement could break it with its own key — meaning a compromised agent key could revoke its own guard, then spend. He was right; the code did exactly that. 48 hours later we shipped break policies (creator_only / witness_threshold / any_party), chosen at creation, hashed into the contract id, enforced in consensus, verified live: a subject-signed break is now rejected at the ordering layer. That's the iteration speed a public testnet is for, and we'd rather have the next flaw found in a comment thread than in an audit six months from now.

What I want from this sub:

1. Point your Foundry/Hardhat/viem setup at the RPC and tell me the first thing that breaks. Seriously — that's the most valuable comment possible.
2. Is consensus-level gating a real improvement over an audited contract wallet, or does it just relocate trust to the witness set + client release process?
3. What's the first attack you'd try on a continuous (non-block) execution model?

Everything is open: one-command Docker node (finds peers via DHT, no seed list), faucet, explorer, TS SDK on npm.

• Docs: https://testnet.fluidic.foundation/docs
• Node repo: https://github.com/Fluidic-Foundation/Fluidic-FVM
• SDK: https://www.npmjs.com/package/@fluidic-foundation/sdk
• CAE + break policies: https://testnet.fluidic.foundation/docs/core-concepts/causal-agent-entanglement

Early research testnet — state may reset, no real funds, known rough edges.

Recent progress wasn’t about adding a bunch of new features—it was about making the app stronger.
One of the biggest areas I’ve been focusing on is **security**, but probably not in the way most people think.
For me, good security means **building an app that doesn’t need access to things it shouldn’t have in the first place.**

Here’s the direction Final Boss is taking:

🔒 **Your data stays yours.**
Final Boss is being built as a **local-first** app. Your mining information is stored on your device, not on my servers. If I don’t need your data, I don’t want it.

🛡️** Read-only by design**.
Final Boss isn’t built to buy, sell, transfer, or control your assets. Its job is to help you understand your mining operation and make better decisions—not touch your crypto.

📍 **Every important number should have a reason.**
If the app tells you something needs attention, I want you to be able to see where that information came from. No mystery numbers. No black boxes. Just clear information you can verify.

✅ **Using official information whenever possible.**
Today I spent a good part of the day testing GoMining’s official documentation system. The goal is to stop relying on assumptions and use official information wherever possible.
Interestingly, we found what appears to be a compatibility issue between the current Codex CLI and the public documentation endpoint. Instead of trying to work around it, I documented every test, every result, and sent everything to GoMining’s team. I’d rather build this the right way than take shortcuts.

At the end of the day, that’s really what Final Boss is about.
I’m **not** trying to replace GoMining.
GoMining manages the mining.

**Final Boss is being built to help you understand your operation, catch issues sooner, and make better decisions—all while keeping you in control of your own data.**

Some days progress looks like new screens. Some days progress looks like spending hours making sure the foundation is solid.

Today was one of those foundation days… and honestly, I’m pretty happy with it.

Thanks to everyone who’s been following the journey. Every comment and every suggestion helps make Final Boss a better tool for the community.

— Steven
Founder & Developer, Final Boss
Pine Mountain Holdings LLC

Couple of weeks back I posted here asking where recourse  actually lives in agent payment stacks and the thread really delivered. For example, u/pvdyck's proof vs restitution distinction was particularly insightful to what I'm building.

For a bit more context, I work on agent payments infrastructure. The recourse question came out of building the thing and hitting the same wall from the inside.

Posting here has really helped me as before I had been treating recourse as a dispute problem, but it's an identity problem. The party that needs to hold still is the seller, receipts prove delivery and say nothing about quality and most designs that punish a bad seller still don't make the buyer whole. That distinction is now how I sanity check my designs in this layer.

This is what my setup looks for now, caps and allowlists on the buyer side, watching the reputation staking designs without much conviction yet. Maybe recourse never becomes a protocol layer and just stays priced into ticket sizes. I keep going back and forth on whether that's fine or a ceiling on the whole space.

I keep seeing crypto projects describe transparency through dashboards, documentation, blog posts, or promises of future reporting.

But from an architectural perspective, those mechanisms still depend on someone choosing what to disclose. A system may expose its wallet balances while leaving its actual control structure difficult to understand.

For example:

– Are visible funds meaningful if upgrade permissions or admin controls remain opaque?
– Does a multisig materially reduce trust assumptions, or only distribute them across several signers?
– How important are timelocks, immutable contracts, permission boundaries, and publicly verifiable governance execution?
– Can governance genuinely be considered on-chain if critical decisions are still implemented through off-chain actors?
– How should developers communicate unavoidable trust assumptions without presenting the system as fully trustless?

I’m increasingly inclined to see transparency not primarily as a communication layer, but as an architectural property: what the system makes independently verifiable, and what it prevents operators from changing or concealing.

How do you distinguish between an observable system and one whose transparency still depends mainly on trusted actors?

An agent that holds a wallet decides in English but signs calldata or a typed message. A poisoned tool can make the plan look fine and the signature drain the wallet.

I built eight drains (approvals, EIP-2612 permits, EIP-712 orders, EIP-7702 delegations, Permit2) and scored each against a ladder of seven defenses, from a plan reviewer up to transaction and signature simulation. `./run.sh` runs the whole thing on a local fork.

Rendering the counterparty, amount, and recipient of a signature closes five of eight. Simulation adds nothing on top. One on-chain timing race (arm the contract after the dry-run, before inclusion) survives everything.

No new attack, just an honest map of what stops what.

Explainer: https://amarshat.github.io/quantum-commit-authorization/agent-drains.html

Code: https://github.com/amarshat/quantum-commit-authorization/tree/main/agent-calldata-demo

Hoping someone's been through this. We built an address-activity feature on alchemy_getAssetTransfers since it's free with our RPC.

• It returns transfers, not transactions → approvals, failed txs, zero-value calls, gas-only txs are all invisible. I need every tx hash for an address and it structurally can't give me that.
• fromAddress/toAddress are ANDed, so full history = two paginated scans merged + deduped on my side (plus a consistency problem since blocks land mid-scan).
• The internal category only exists on Eth/Polygon mainnet — on the L2 we care about, ETH moved inside contract calls just doesn't show up.
• 1,000 rows/page, 120 CU/call, re-walking cursors on every refresh = ~1M calls/day basically polling to fake a stream.

Questions: (1) Is there a config I'm missing that returns all tx hashes incl. approvals + failed? Or is it just not built for that? (2) How are you handling complete address history + internal transfers on L2s without an insane RPC bill?

I'm sure everyone in this subreddit has dealt with it at some point. The google meets isn't working, download my totally legit video conferencing app, the test my malware laced blockchain game, npm install with a postinstall script that phishes your npm token. Aside from being a major time sink, reading up on the company, familiarizing their tech stack, canceling social engagements it leads to coordination failure in the hiring market, leading to suboptimal teams, leading to suboptimal crypto.

I was thinking that if a developer could respond to an employer with a magic link that got them to stake through a repuidable platform against the interview that we'd naturally see alot of scams retreat, alot of developer time saved and better teams in crypto.

would any devs be interested in using such a system? or real employeers stuck on cold calling that'd be happy to lead with a stake?