Hey everyone.

I shared an EVM reading path here before. This time I wanted to bring one small exercise from the same area, something you can check against actual logs.

Say you want to track an ERC-20 wallet’s incoming and outgoing transfers. In the topics filter, putting the wallet in both address positions looks reasonable:

[TransferSignature, wallet, wallet]

But that matches transfers from the wallet to itself.

Topic positions are combined with AND. To find activity in either direction, use two filters:

Outgoing: [TransferSignature, wallet]
Incoming: [TransferSignature, null, wallet]

Here, TransferSignature means the event signature hash, and wallet is the address padded to 32 bytes. These are schematic filters, not literal JSON requests.

Use the same token contract and block range for both queries. Combine the results and remove duplicates, since a self-transfer matches both. For that fixed set of logs, (blockHash, logIndex) identifies each entry.

Another useful variation:

[TransferSignature, [walletA, walletB]]

That matches transfers from either wallet. The inner array gives you OR within one position.

Try predicting the results before running the queries. It is a small exercise, but it makes the filtering rules much easier to remember.

I collect my free Ethereum articles and accompanying code examples on 0xByteBeetle. They cover EVM execution, transactions, events, deployments and proxies, with examples you can run and inspect alongside the explanations.

If you try one, I’d be interested to hear where the explanation or setup needs more detail.

Hey auditors,

I’m doing a research about the most difficult part of auditing smart contracts and would like to get your thoughts on it.

What’s the hardest part of auditing smart contracts? Is there something you spend a lot of time doing while you do your audits? Would appreciate your thoughts.

Thanks

Our network will be centralized, utilizing eight external servers (rented space). In the event of a node loss, data is immediately replicated. The design draws inspiration from Delegated Proof-of-Stake (DPoS) and early versions of Proof-of-Authority (PoA). Naturally, users also have the option to create their own assets by setting up an open observer nodes.

The goal? The rationale? Behind such a solution? To reduce network overhead for post-quantum solutions.

VillaMoney

Hi everyone,

I’m sharing NexusDAO, an open-source prototype for transparent collective investment governance. It connects public proposals, snapshot-based voting, executable investment mandates, and Safe multisig validation in one workflow.

The goal is to make DAO treasury decisions more traceable and structured.

You can try the public demo here: https://vlight7432.github.io/investment-dao/

I’d really appreciate feedback on the interface, governance flow, and features you would find useful..

Adrat177

Hi everyone, I’m sharing NexusDAO, an open-source prototype for transparent collective investment governance. It connects public proposals, snapshot-based voting, executable investment mandates, and Safe multisig validation in one workflow. The goal is to make DAO treasury decisions more traceable and structured.

You can try the public demo here: https://vlight7432.github.io/investment-dao/

I’d really appreciate feedback on the interface, governance flow, and features you would find useful.

Adrat177

I wrote some of the Uniswap v4 guides in the official docs, so I've been following hooks since before v4 shipped.

Since 22 Oct Uniswap's router also routes through aggregator hooks, hooks that wrap Curve, Fluid or PancakeSwap so the router sees them as a v4 pool. So a hook isn't only custom logic on a pool anymore, it's a route, and the router only picks routes it trusts.

I read Uniswap's "Routing for hooked pools" page and the allowlist form. Most hooks get picked up automatically, but if yours uses beforeSwap, afterSwap, either return-delta flag or dynamic fees it goes to manual review. That's basically any hook that does something on a swap.

And most of that review is design, not paperwork. No proxy that lets you upgrade the hook. No custom calldata the router can't produce, so a signed price in hookData is out. Verified source matching the bytecode, a repo link isn't enough. Permissions live in the address bits, so you choose them once when you mine it. If your plan was an upgradeable hook, you find out at review time.

The page also says allowlisting is not a security review. It asks whether swappers can be routed through you, nothing about your LPs or your delta math, and with a hook that returns its own delta one wrong sign gets paid on every swap the router sends you.

If you've shipped a v4 hook or you're close, what was the part you were least sure about before putting it on mainnet?

Build-in-public update. Sigui is a security layer for autonomous AI agents that manage real capital: a 5-layer risk engine (behavior analysis, a 7B vision model trained on a 1M-sample attack dataset, memory) that returns ALLOW / BLOCK / ESCALATE in <50 ms, built on top of ERC-8259 — our on-chain standard for agent identity, tiered verification (Bronze → Silver → Gold → Platinum), trust scores and a threat registry.

Changelog, Nov 1 → 8 (every item commit-dated in the repo):

• Nov 1 — canonical npm package erc-8259 + ERC8259Guard for Solidity: a 2-line integration with onlyVerifiedAgent and minTrustScore(700) (= 70%) modifiers for gating high-value operations. Starknet Cairo 2.8.4 contracts: 8/8 tests passing (explicitly a non-normative reference implementation).

• Nov 2 — incident lifecycle in the spec (PR #2137 merged upstream): IncidentStatus, retractAttack / resolveAttack, T7 invariant.

• Nov 3 — deprecated our own pre-#2137 Sepolia deployment with loud warnings + CHANGELOG. Better us than an attacker.

• Nov 4 — internal audit found isActive unchecked in getEffectiveTier / isVerified / calculateTrustScore; fixed and merged upstream the same day (PR #2142). Added the adversarial attack test suite (phase C4).

• Nov 6–8 — Groth16 (Circom) circuit proving trust-score computation off-chain, real prover integrated into the gateway; npm v1.3.1; docs integrity pass (removed unverifiable testnet claims — we'd rather under-claim).

Asks — this is why I'm posting:

• Solidity/EVM devs: review the guard modifiers and the T8 trust-score expiry rule. What breaks them?

• Anyone building AI agents (trading bots, orchestration frameworks): would pip install sigui + a 2-line guard hook fit your stack? What's missing?

• Security folks: in a tiered-verification + threat-registry design, what do you attack first? We'll turn every answer into a GitHub issue.

Python SDK: pip install sigui · Vision model (Imina-Na-V2, 7B, LoRA r=16): https://huggingface.co/Ibonon/Imina-Na-V2 · Dataset: https://huggingface.co/datasets/Ibonon/sigui-depin-1m

Repo: https://github.com/ibonon/Sigui — every piece of harsh feedback gets an issue and a response

We maintain ERC-8259 (on-chain identity, tiered verification and a threat registry for autonomous AI agents). During an internal audit of our reference implementation last week, we found a critical bug. Sharing the post-mortem because every ERC author will hit this eventually: your reference implementation becomes a footgun the moment the spec moves.

The bug (two parts):

1. Registration accepted verification_tier directly at registration time — self-assigned privilege escalation.

2. isActive was not checked in getEffectiveTier, isVerified, or calculateTrustScore. A deactivated agent kept verified status and trust-score benefits. Picture deactivating a compromised agent — and its accumulated reputation still passes a minTrustScore(700) gate on someone else's contract.

What we did, in order (all commit-dated in the repo):

• Nov 2 — incident lifecycle landed in the spec (PR #2137 merged upstream): IncidentStatus, retractAttack / resolveAttack, T7 invariant. Threats can be retracted, not just forever-append.

• Nov 3 — deprecated our own pre-#2137 Sepolia Vyper deployment, loudly: README warning banner, deprecation headers on legacy contracts, CHANGELOG + security upgrade notice. It lacks verification_expiry, get_effective_tier and the incident lifecycle. Redeployment tracked in Issue #2.

• Nov 4 — fixed the invariant in the repo (2824257), pushed the spec change upstream as PR #2142, merged the same day. Added an adversarial attack test suite for the registry (phase C4), runnable with forge test from the repo root.

• Nov 6–8 — implemented the trust-score Groth16 circuit (Circom), integrated a real prover into the gateway, sanitized ZK over-claims in docs/UI, published npm [email protected].

Lessons, if you're maintaining an ERC:

• Ship the spec as an npm package with versioned interfaces + NatSpec, not as a gist people copy-paste. A stale interface outlives every blog post.

• Write the deprecation warning the day you know, not the day someone asks.

• Adversarial tests belong in the repo, executable by anyone who clones it.

Repo (Sigui — the agent-security layer this ERC is part of): https://github.com/ibonon/Sigui

What we'd love review on: the T8 trust-score expiry rule and the tier-verification invariants. And if you've maintained an EIP/ERC: how did you handle "already deployed, spec changed"? Genuinely curious what the norm is.

Been digging into the Lean Ethereum roadmap and the post-quantum transition plans, and there is a specific account migration edge case I keep coming back to.

Right now, the cleanest way for existing EOA holders to get quantum resistance without abandoning their current address and DeFi positions is delegating via EIP-7702 (or moving to native AA once EIP-8141 lands) to a smart wallet contract that verifies a lattice or hash-based signature.

The catch is that with EIP-7702, the underlying secp256k1 private key still retains root control over the account. Even if your daily transactions are verified through a post-quantum delegate contract, an attacker with a strong enough quantum computer could theoretically derive the original ECDSA private key from your public key on-chain and sign a fresh authorization transaction pointing your EOA to their own malicious delegate contract.

At the protocol level, how are core devs planning to let existing EOAs permanently burn or brick their underlying ECDSA key once they migrate to a post-quantum scheme? Would that require a dedicated opcode or transaction type in one of the upcoming forks before L*, or is the assumption that everyone eventually sweeps funds to fresh native AA addresses?

My brother and I are building Twirl, a prediction-market platform, and one thing we’ve been working on is what happens when the happy path breaks.

Example:

A user places an order.

Their internet drops.

Now what?

Did the order go through?

Should the UI let them place it again?

Should their funds be released?

That kind of ambiguity can turn into duplicate orders or incorrect balances pretty quickly.

So we changed the flow.

Twirl now checks the backend to confirm what actually happened before allowing a replacement order.

We also improved recovery across page refreshes and multiple browser tabs, so orders and balances remain tied to backend records rather than just whatever the current browser session thinks happened.

We also tested partial fills:

• The completed part of the order stays recorded.

• Unused reserved funds are released correctly.

• Balances refresh after fills and cancellations.

• Unresolved requests stay preserved.

• Instant orders are blocked when market data is stale.

The local browser-to-backend rehearsal passed all 10 recovery scenarios, and the frontend test/build/type checks are passing too.

What’s interesting to me is how much of financial UX is really about handling uncertainty.

A polished UI means nothing if the app guesses wrong when the network gets messy.

For people who’ve built trading, payments or financial products:

What recovery-state bug caused the most pain for you in production?

Refreshes? stale data? retries? auth expiry? multi-tab conflicts? something else?

My understanding is that one way to minimize the risk of losing crypto assets to future quantum computing or super AI attacks (e.g., having private keys derived from public addresses cracked) is to transfer and store assets in wallets whose addresses have never been used in any blockchain transactions.

My understanding is also that once you send any crypto or NFT from such an address, its public key becomes exposed, making it potentially vulnerable to these future threats.

I have a few questions:

1. How exactly does this mechanism work?

Wouldn't the receiving address still be visible on the blockchain? Front-end platforms like Etherscan and OpenSea also retain and display transaction histories, including the sender's and receiver's public addresses.

If that's the case, why does having no previous transaction history actually reduce the risk? Is the key distinction that a wallet address is publicly visible, but its actual public key is not necessarily exposed until it initiates a transaction?

2. What happens when multiple addresses are generated from the same seed phrase?

Let's say multiple public/private key pairs are generated from a single seed phrase. If one of these previously unused addresses makes its first on-chain transaction (e.g., sending cryptocurrency or an NFT), would the other addresses derived from the same seed phrase also become compromised?

I'm trying to understand whether the exposure is specific to the individual address/key pair or whether it could potentially extend to other addresses derived from the same seed phrase.

For example, if I transfer my crypto assets to a hardware wallet, but the exposure of one address could compromise all other addresses derived from the same seed phrase, wouldn't that mean people would need to maintain multiple hardware wallets (and separate seed phrases) to achieve meaningful protection?

3. What are some reasonable and practical ways to minimize these risks?

Given the potential future threats from quantum computing and super AI, what security practices would you recommend for an average crypto holder? How much precaution is actually warranted today, and what would be a sensible balance between security and practicality?

I’ve been building RiskLayer, an experimental protocol that explores how an on-chain vault can safely rely on an off-chain risk committee, and I’ve just open-sourced it.

How it works

• Providers deposit USDC into a LiquidityVault.

• A taker opens a payment intent against a provider, which reserves that provider’s liquidity.

• Four risk nodes independently score the intent and sign an EIP-712 assessment.

• The RiskOracle contract rebuilds the digest from the on-chain intent, verifies a 3-of-4 quorum of distinct authorized signers, and approves or rejects. A rejection releases the reserved liquidity.

Stack: Solidity 0.8.24 + Foundry, Python risk engine/signer/aggregator, FastAPI backend, React + ethers frontend. It’s deployed on Base Sepolia (testnet only).

Links

• Repo: https://github.com/Akshith985/risklayer

Where it’s honestly incomplete, and where I’d love help:

1. The four “independent” nodes currently run in one process, so the quorum isn’t actually decentralized yet.

2. Risk inputs (reversal rate, dispute rate, etc.) are supplied by the caller, not derived from verifiable data.

3. Approved intents have no settlement step; liquidity just stays reserved until expiry.

4. It needs fuzz/invariant tests, and it’s unaudited.

I’ve opened issues for these plus a set of good first issues (config hardening, CI, a payload bug in the CLI scripts), and there’s a CONTRIBUTING guide and SECURITY policy in the repo.

I’d especially value feedback on the trust model: is a signature-quorum oracle like this a sensible approach for gating liquidity, and what would you do differently for the node operator set and data sources? Happy to answer questions about the design.

Hi all, as you can see from the image above, MetaMask flags my app 20questions.lol as "malicious" when you try to connect to it.

it’s basically a crypto game where an AI picks a secret word and players pay to ask yes/no questions, and the first person to guess the word wins the whole pot. I use blockchain specifically for transparency, so the secret word is committed on-chain as a hash before the round starts and nobody (including me) can change it. The contract is live and verified on Base: 0xf0925993D00F5E2c5C7c5053eD67309a0a9beF8c

What the app actually asks your wallet to do:

1. Connect

2. Approve USDC for the 2 USDC buy-in plus up to 10 questions (so you don’t have to approve every question)

3. Sign each question, which the server then submits on-chain so players don’t pay gas

I’ve already reported it as a false positive to Blockaid. Has anyone gone through this? How long did it take, and is there anything else I should be doing? I’ve had the app live for about 2 weeks now and nobody will want to use it in this state.

Also open to feedback if there’s something in my flow I should change so it stops looking suspicious.

Hey r/ethdev,

Over the past few months, we've been building infrastructure for autonomous AI agents (ElizaOS, LangChain) that interact with smart contracts.

The biggest security hole we observed is that **most teams pass raw private keys or unconstrained session keys to LLMs**. If an agent encounters a prompt injection or hallucinates an input parameter, it can drain an entire contract or treasury in a single block.

To solve this, we deployed and verified **`SecurityGateOMSPolicy.sol`** on Polygon Mainnet to act as an on-chain economic circuit breaker.

### 🛠️ Architecture Highlights:

1. **Hard Spend Caps at Contract Level:**

   * Single Transaction Max: $5,000 USDC

   * 24-Hour Velocity Cap: $25,000 USDC

   * Any call violating these thresholds automatically reverts, completely bypassing whatever the LLM decided.

2. **EIP-712 Dual-Attestation:** All agent deliverables and truth oracle attestations require deterministic EIP-712 structured data signatures before releasing escrow funds.

3. **Pre-Sign AST Analysis (<5ms):** Before an agent signs an EVM transaction, its generated payload undergoes deterministic AST parsing off-chain to detect code injection or malicious parameters.

### 📜 Verified Contracts:

* **Polygon Mainnet Policy:** [`0x4A28F9A2E6D0DcB69791980560FC8364A514f205`](https://polygonscan.com/address/0x4A28F9A2E6D0DcB69791980560FC8364A514f205)

* **Universal Escrow Core:** `0x4Dbd77F4799816859a595f24a57A786516D2EAa8`

We’d love to get feedback from other smart contract engineers on how you're handling agentic wallet permissions and multi-sig fail-safes!

*(Open-source repos, packages, and architecture docs are in the first comment)*

Hi everybody, i wanted to know if anyone here ever worked with smart contracts in Go?

My main focus is to read the events(basically reading results) from my smart contracts, if anyone can recommend me some free resources would be great.

Well, you can check this repo, like I have build, it and like if this has any flaws, and like that, but according to, me till now it's perfect, but ready for test7ng, and like we should test it like, as new blockchain and like, that so, you can see the repo ?

I'm building Lasso RPC, an open-source EVM JSON-RPC router/proxy in Elixir/OTP. You drop in multiple RPC providers and it routes requests across them. There's also a hosted version w/ custom profiles at lasso.sh if you don't want to run the container yourself.

Two bigger updates shipped over the last couple weeks that I think other EVM devs might find useful:

1. Route transaction sends to private RPC relays (v0.8.0 + Custom profiles)

lasso-rpc v0.8.0 shipped today: https://github.com/jaxernst/lasso-rpc/releases/tag/v0.8.0

If you aggregate public RPCs + paid providers into one pool for cheap/fast reads, you don't want signed transactions going out to random public endpoints and leaking to the public mempool. You can now drop in private RPC relays and restrict transaction sends on a chain strictly to those routes:

transactions:
  providers: [my_private_relay]
  fallback: none   # or read_providers if you want a second-phase fallback

Reads, subscriptions, and block recovery keep using your wider pool like normal. Signed sends: eth_sendRawTransaction, private/bundle/cancellation/conditional/synchronous send methods, and any unknown method carrying signed tx bytes only go to the providers you name.

Methods are classified by what they actually do rather than just matching a hardcoded list of method names, so send policy follows signed tx bytes. It also defaults to fail-closed (fallback: none) so sends won't quietly spill into your public read pool if a relay errors. (Lasso doesn't pick MEV relays for you: you bring the endpoints and tell it where sends are allowed to go.)

Same transactions block is live on hosted Custom profiles: https://docs.lasso.sh/cloud/custom-profiles

2. Automatic provider learning from live traffic (v0.7.0)

Release: https://github.com/jaxernst/lasso-rpc/releases/tag/v0.7.0

Every RPC provider has slightly different plan quirks: refusing certain methods, pruning historical state, or capping eth_getLogs block ranges, and maintaining all of those limits by hand in YAML sucks.

Provider self-learning is now on by default. Without sending any extra probe spam, the router watches live traffic and learns three things on the fly:

• Method refusals

• Missing historical state

• eth_getLogs block-range caps

When a provider hits one of those limits, Lasso moves it behind your other providers for matching requests (while always keeping your last available route so you don't get cut off). Learned limits expire on their own, or clear when that upstream later serves what it refused. Anything you explicitly declare in config still wins.

Docs: https://docs.lasso.sh/concepts/provider-learning

Two smaller things on hosted (lasso.sh)

• WebSocket subscriptions survive a single-upstream reconnect with the same subscription ID — if your only eligible WS upstream blips, Lasso reconnects, backfills the missed blocks, and resumes live events without your app having to tear down and rebuild state. (If another WS provider is in the pool, it fails over there first.)

• One-shot agent setup: agents can provision an account and endpoint directly from https://lasso.sh/llms.txt (no signup form), and account creation now returns a claim_url in one shot if you want to pull that agent account into the dashboard later.

Self-host Core v0.8.0:

ghcr.io/jaxernst/lasso-rpc:v0.8.0

• Repo (Apache-2.0): https://github.com/jaxernst/lasso-rpc

• Hosted: https://lasso.sh

Still actively hardening all of this. If you're running multiple providers (especially public/paid reads + private relays for tx sends) and try this out, lmk how it behaves or what's missing!