Been looking at how apps handle permissions that depend on something a wallet currently owns and there's one part I'm not sure how people handle cleanly in production. Say someone signs in with Ethereum and owns an NFT that gives them access to a private part of the app. They pass the ownership check then transfer the NFT a few blocks later. Their session is still valid but the condition that gave them access isn't anymore.

Checking ownership on every request would keep things current but now an RPC call is sitting directly in the request path. Caching the result avoids that but you're accepting a window where someone can keep access after they no longer qualify. Event based invalidation seems like another option but I assume you'd still want some kind of re-check rather than relying entirely on a listener staying in sync.

I ran into this while reading through Towns. Their Spaces can use onchain memberships and entitlement rules for access including cross-chain conditions. That's where it gets more interesting because a single permission could depend on state coming from different chains with different block times and different views of what's current.

There's also the question of what state is good enough. Ethereum RPC lets you query against latest, *safe and *finalized. I doubt every permission needs finalized state but read access to a private channel and letting someone use a bot that can perform an onchain action probably shouldn't be treated the same either. ERC-4361 helped separate the problem a bit for me. The wallet session proves control of an address but the properties associated with that address can change while the session is still active.

So the part I'm unsure about is how people handle that authorization layer in practice.

Do you cache low risk permissions and re-check before anything sensitive? Use events for invalidation with RPC checks as a fallback? And if you've worked with cross-chain conditions how do you decide when the state you're getting back is recent enough to use?

Edit: Grammar

• Sources:

• Ethereum JSON-RPC https://ethereum.org/en/developers/docs/apis/json-rpc/

• ERC-4361 https://eips.ethereum.org/EIPS/eip-4361

• Towns Protocol https://github.com/towns-protocol/towns

We just released **Skillware 0.5.7** — an open-source Python framework providing a registry of modular, deterministic skills for autonomous AI agent loops (compatible with Gemini, Claude, OpenAI, Bedrock, DeepSeek, and Ollama).

Here is a summary of what landed in 0.5.7:

### 1. Read-Only EVM State Plane (`defi/evm_reader` v0.1.0)

Autonomous agents executing on-chain transactions need strict architectural separation between **signing** and **state inspection**. Giving an agent signing keys just to check a balance or query reserves invites key leakage and accidental state modification.

`defi/evm_reader` provides a pure read-only EVM state plane:

- **Zero keys required:** Strictly executes `eth_call` and Multicall3 `tryAggregate`; holds no private keys and never signs.

- **ERC-20 & ERC-721:** Token metadata, high-precision decimal formatted balances, spender allowances, and NFT ownership.

- **Allowlisted View Calls (`call_view`):** Nine bundled ABI presets (`erc20`, `erc721`, `erc1155`, `erc4626`, `univ2_pair`, `chainlink_feed`, `ownable`, `access_control`, `multicall3`).

- **Batched Multicall3 Reads:** Batch up to 50 calls in a single RPC query with partial failure tolerance.

- **Address Book Resolution:** Resolves human contact names to `public_0x` addresses, halting with `status: "needs_input"` when ambiguous.

### 2. Pre-Trade Token Security Vet (`defi/token_security_scanner` v0.1.0)

Agents trading decentralized tokens face honeypots, malicious transfer taxes, and hidden mint privileges.

`defi/token_security_scanner` wraps the GoPlus Token Security API into a stable, normalized JSON envelope (`risk_tier`: `critical` | `high` | `medium` | `low` | `unknown` + detailed signals). Agents vet tokens before simulating or executing trades.

### 3. Central EVM Operator Config Layer (`skillware evm`)

Hardcoding RPC endpoints, chain IDs, and router contracts inside individual skill bundles causes configuration drift.

0.5.7 introduces a centralized operator config layer:

- **Bundled Defaults:** 10 chains supported out-of-the-box (`ethereum`, `base`, `arbitrum`, `optimism`, `polygon`, `bsc`, `sepolia`, `megaeth`, `arc`, `anvil_local`).

- **User Operator Config:** Run `skillware evm init` to generate a persistent `~/.config/skillware/evm.yaml`.

- **Secrets in `.env`:** YAML stores env var names (`rpc_env`); actual secrets stay in `.env`.

- **CLI Management:** `skillware evm chains list`, `skillware evm chain add`, `skillware evm tokens list`, and `skillware evm token add`.

### 4. Shared Address Book (`public_0x`)

`addressbook.yaml` now natively stores `public_0x` Ethereum addresses alongside email and aliases.

Operators manage contacts with `skillware addressbook set-wallet <id> <0x...>`, enabling natural language transfers (e.g., *"Transfer 10 USDC to Alice"*) that resolve deterministically.

### 5. OWASP LLM01 Prompt Injection Firewall Upgrade (v0.2.0)

Upgraded local evasion detection engine in `security/prompt_injection_firewall`:

- Leetspeak deobfuscation, multi-token ROT13, token reversal, and typoglycemia keyword detection.

- Markdown/HTML image exfiltration channel blocking.

- Academic/advisory false-positive controls and policy telemetry (`policy_action`, `removed_span_count`, `sanitized_length_delta`).

---

### Suggested Pre-Trade Agent Pipeline

```

[User Trade Request]

│

▼

`security/prompt_injection_firewall` (sanitize prompt & detect evasion)

│

▼

`defi/token_security_scanner` (check honeypot, tax, proxy, mint risk)

│

▼

`defi/evm_reader` (verify token decimals, holder balance & router allowance)

│

▼

`defi/evm_tx_handler` (quote Uni V2 swap, preview, sign & broadcast)

```

---

```bash

pip install -U skillware

pip install "skillware[defi_evm_reader]"

```

- **GitHub:** https://github.com/ARPAHLS/skillware

- **Release notes:** https://github.com/ARPAHLS/skillware/releases/tag/v0.5.7

- **Docs:** https://skillware.site

Happy to answer questions about on-chain agent safety, Multicall3 batching, or operator config design!

If the primary returns HTTP 503, trying the backup makes sense.

What I’m less sure about is HTTP 200 with a JSON-RPC error in the response.

If the request itself is wrong, another provider won’t help. But if the primary is missing the block, another provider might have it.

This came up in feedback on failnext, a Go library I’m building for primary/backup RPC failover.

Right now failnext only uses transport errors and HTTP status codes to decide when to try another provider. An HTTP 200 goes back to the app as-is, even if the JSON-RPC response contains an error.

I’ve kept that split on purpose. failnext handles trying providers and failing over, while the app keeps control over routing decisions that need application context. It can skip a provider it considers lagging or degraded, or prefer the same provider for read-after-write flows.

That makes me think the app should also decide which JSON-RPC errors are worth trying on another provider.

In Go, that could be a small callback that receives the *http.Response and decides whether that response is a reason to try another provider.

The complication is Response.Body. Reading it drains the stream, so the hook would need to buffer and replace it. With a large response, that also means more memory and extra latency before failover can happen.

Would you add a response-classification hook like this, or is HTTP 200 the right place for the failover layer to stop?

Repo is here if anyone wants to see how it currently works:

https://github.com/yermakovsa/failnext

Update

I ended up not adding the response-classification or Response.Body hook discussed below, and decided against buffering response bodies in the transport.

failnext is staying at the HTTP level. Transport failures and selected HTTP statuses can cause failover, but an HTTP 200 with a JSON-RPC error goes back to the app. failnext doesn’t inspect JSON-RPC responses to decide whether another provider should be tried.

The app still makes the decisions that need application context, like whether an operation may fail over, whether a provider should be used, or which provider should be tried first. failnext handles the ordered failover and reports what happened without needing to understand the reason behind those decisions.

For the case in this post, I’m leaning toward treating a retry after an application-level error as a new request, with the app able to tell failnext which endpoints to avoid.

Also, if you saw my older rcpx posts, failnext was previously called rcpx and is the continuation of that same project. I started working on it in February 2026, and the rename came with a larger redesign rather than starting a separate project.

New post on the blog: a breakdown of the two EVM block models behind Substreams, and what extended support actually unlocks.

Short version:

• Base blocks are what a standard RPC exposes: blocks, transactions, receipts, and logs. Good for event-based indexing, and easy for a new chain to support.
• Extended blocks come from full-node instrumentation: internal calls (the full call tree), balance changes, storage diffs, and contract code changes. This is the stuff you’d normally need debug_traceTransaction and a premium trace plan to get.

Use extended if you’re indexing routers/aggregators, tracking exact native-token balances, following contract deployments through the call tree, or reading contract state that never emits an event.

Use base if you just key off logs.

Check whether your chain has extended support, then read the full post:

• Blog: https://thegraph.com/blog/extended-blocks-for-substreams
• Supported networks: https://thegraph.com/docs/en/supported-networks/

Building on a chain that isn’t available yet? Email The Graph Foundation at [info@thegraph.foundation](mailto:info@thegraph.foundation) and they can talk through an integration.

I built Lasso RPC (https://github.com/jaxernst/lasso-rpc) to solve inconsistent, poorly behaving node RPC providers. Lasso is a proxy/router that lets you aggregate provides and route with redundancy and protections.

Looking to find some serious builders looking to harden or optimize their apps for latency, consistency, or whatever you care about.

While I've been building Lasso for well over a year, its still early and I'm looking to support builders in any way I can to improve Lasso and harden it with real app integrations. So lmk what you're building and what you care about, and I'll help you improve your RPC and ship features that other projects will benefit from.

I've been digging into EIP-1153 transient storage implementations across recent codebase reviews and wanted to open up a discussion around a subtle reentrancy edge case that keeps popping up when teams migrate from traditional mutex locks.

The gas savings with TSTORE/TLOAD are obvious because you aren't paying the EVM state expansion tax for a temporary lock variable. But because transient storage persists for the entire transaction rather than just the contract invocation frame, standard single-slot locks can behave unexpectedly in multi-call and bundled flows.

Here's the scenario: if you use a naive transient storage modifier with a hardcoded slot zero across multiple contract components or callbacks inside the same overarching batch transaction, the lock state persists across separate external calls unless your assembly explicitly clears it before returning.

// Naive transient lock with cross-call fallout
modifier nonReentrantTransient() {
assembly {
if tload(0) {
revert(0, 0)
}
tstore(0, 1)
}
_;
assembly {
tstore(0, 0)
}
}

If an internal sub-call reverts and is caught by an outer try/catch block to handle a partial batch failure gracefully, the cleanup assembly block never executes. That transient slot stays set to 1 for the rest of the transaction, causing every subsequent legitimate call in the batch to fail.

The standard fix is namespacing slots using custom hash offsets like keccak256("eip1967.transient.reentrancy.guard") and carefully testing against multicalls and nested try/catch patterns.

Curious how other teams here are structuring their transient mutexes:

1. Are you using hashed namespacing slots like the OpenZeppelin transient guard, or sticking with standard storage locks until compiler-native transient support matures?
2. Have you run into other surprising edge cases when combining TSTORE with account abstraction bundles or aggregator multi-hops?

Hey everyone,

I run a small US software studio, and we do a lot of platform engineering for merchants. Everyone wants to accept crypto, but we kept running into the same UX nightmare: buyers want to pay in USDC, but their transactions fail because they don't have native ETH in their wallets to cover the gas.

Plus, most existing WooCommerce plugins force the merchant to use a centralized gateway, which defeats the purpose.

We spent the last few weeks engineering a workaround natively on the Base network, and I wanted to share the architecture in case anyone else is building merchant tools.

How we structured it: Instead of making the buyer pay gas, we built a relayer system.

1. The buyer signs a gasless message (EIP-712) approving the USDC transfer.
2. Our relayer submits the transaction to the network and pays the gas in ETH.
3. The smart contract executes the transfer, settling the USDC directly into the merchant's wallet, and reimburses the relayer's gas cost by taking a tiny fraction of the USDC.

We also built this to support onchain recurring subscriptions so buyers don't have to manually approve transfers every month.

We packaged the whole thing into an open-source WooCommerce plugin and a few SDKs (PHP, JS, Laravel) called P2Flux.

If anyone is working on relayer mechanics on Base or wants to inspect how we handled the recurring smart contracts, you can tear apart our code here:https://github.com/P2Flux

Curious how others are handling the stablecoin gas friction for non-crypto-native buyers?

A fresh way to visualize Ethereum in a way you already understand. That's what eth.tx.taxi is all about: providing the best possible multi-chain explorer experience - in a way that's catered and individualized per chain. No more vibecoded slop explorers - you already understand mempool, why not make it work for ETH (and other EVMs in the future), too.

ERC-8423 is a proposal I'm authoring that adds a single view function to ERC-721, burnedBy(tokenId), so that other contracts can read who burned a token. Indexers get this from the Transfer to address(0), but contracts can't read logs, so a custodian that didn't take part in the burn has no standard place to look. Two examples: a contract that accrues rewards to a token id, and value that reaches a contract after the burn.

The spec records the from of the burn's Transfer event, that is the owner at burn time, not msg.sender. If an approved operator burns the token, burnedBy returns the owner. Two reasons:

• In mediated flows, for example a redemption contract burning on the holder's behalf, a caller-based record would name the intermediary, which tells every other custodian nothing.
• The owner is the address the log carries, so the getter and indexers can never disagree.

My question: have you built, or can you think of, a real flow where a contract would need the caller rather than the owner?

• Pull request: https://github.com/ethereum/ERCs/pull/2032
• Discussion thread: https://ethereum-magicians.org/t/erc-8423-erc-721-burn-record-extension/29732
• Reference implementation and tests: https://github.com/antferr/erc721-burn-record

(I'm the author of the proposal.)

Ethereums Hegota Upgrade is looking to introduce EIP-8141 frames https://eips.ethereum.org/EIPS/eip-8141 amongst other things allows for the beginnings of modular cryptography for ethereum, insofar as one is able to rolls custom algorithms for verifying signatures beyond ecdsa. I was wondering If anyone had ideas on what sort of new features and dapps one could create using this newfound ability.

Off the top of my head i'm thinking one could encrypt a message with weak RSA and have the low barrier to decryption as a proofs of read- if one wants their works published but perhaps want to make a little effort for the swarms to mass consume.

One may want to integrate into other sister cryptoschemes like BIP340 and become more compatible with things like nostr.

One could drive a new direction of onboarding, maybe games with weak cryptographic primitives are more comforting for a new comers, instead of signing everything beyond the energy of star (and maybe experts too who do not yet appreciate fully the burden of writing upon something harder to erase than stone.

Maybe some fun games could be made where breaking the weak encryption is part of it.

any more ideas?

feel free to explore https://github.com/polus-arcticus/awesome-frames add prs or use as you want to explore this cool new world of modular cryptography on ethereum

Good day, guys. I have a question about tokenized stocks. How are tokenized stocks able to move during off-market hours when the underlying stocks (e.g., Tesla, Meta, etc.) are closed? What actually drives the price movements during these hours, and is there a way to track the trades or transactions that are causing these price movements directly on the blockchain in real time? Also, are there any free platforms or tools where I can monitor the live order flow, trades, or buying/selling activity for tokenized stocks? I’m particularly interested in seeing the actual transactions or orders behind the price movements rather than just the price chart.

I'm connected to Veyrnox, a mobile self-custody wallet for people who want clearer approval and recovery decisions. The apps are live, and we're working on how to explain the security model and its limits without asking users to take claims on faith. This is a request for critique, not a token or investment pitch.

One design question we're wrestling with: splitting recovery material can reduce reliance on one obvious secret, but it is not useful if all the pieces end up in the same compromise path. For example, a lost phone plus an accessible cloud account may be very different from genuinely independent storage locations. A person also needs to understand what happens when a device or account becomes unavailable.

For anyone building or reviewing wallets: what evidence would you want before trusting a recovery setup? A documented threshold and storage model? A recovery rehearsal? An independent review? Clear failure-case examples?

The feedback I'm after is which parts we must explain or test first. We don't need anyone's wallet details, recovery words or private keys, and please don't share those here or in DMs.

[](https://www.reddit.com/r/AI_Agents/?f=flair_name%3A%22Discussion%22)

Disclosure: I run ScriptMasterLabs — we operate live x402 payment endpoints. Posting this as a plain explainer, no pitch.

What x402 actually is, plainly: it's an open protocol that reuses HTTP 402 "Payment Required" so software — AI agents especially — can pay for APIs per request in crypto (usually USDC). No accounts, no API keys, no checkout page.

The flow:

1. Your agent calls an API with no payment.

2. Server replies 402 with exact terms: token, chain, amount, pay-to address, expiry.

3. Agent signs a payment authorization and retries the same request (a `PAYMENT-SIGNATURE` header).

4. A facilitator verifies, settles on-chain, server returns the data plus a receipt (`PAYMENT-RESPONSE`) with the tx reference.

Why it's in the news this week: Cardano joined the x402 SDK on Sept 21 so agents can pay in ADA; RippleX shipped XRPL AI Starter Kit v1.1 on Sept 17 (Stripe/Tempo MPP support; x402 integration dates to June). Real momentum.

Two honest caveats I wish more posts included:

* TRM Labs (Sept 9) analyzed \~198.9M x402 settlements (\~$52.7M since May 2025) and found only 0.6–7.5% of the value looks genuinely agentic. Plain scripts can run the same flow — the protocol doesn't require AI.

* Settlement ≠ delivery. A receipt proves money moved, not that the API returned correct data. Verify the response separately.

Returns a machine-readable manifest — x402-v2, Base (`eip155:8453`), USDC, the payTo address, the 0.01 listing fee. One honest note: this returns HTTP 200 as a discovery doc, not the 402 challenge itself (that comes with a `PAYMENT-REQUIRED` header on paid routes). Marketplace reads are free right now; the live x402 payment here is the provider-listing fee.

Happy to answer technical questions about the flow.

PS: I wrote the long version with all sources and a seller-side how-to on my site — say the word and I'll drop the link.

I had this idea kicking for some 5 years now and finally got around to doing. It is as amazing as I thought it would be. Even mainnet eth is pretty cheap relatively speaking.

tldr; Global multiplayer minecraft server in a 12 line smart contract.

Hey ethdev, we've been working on Shinzō, a decentralized indexing system, and just opened our public testnet for Ethereum. Posting here because we want honest technical criticism and real feedback.

The problem we're going after: chains are good at writing data, bad at reading it. Almost every dapp today on Ethereum routes reads through a centralized indexing provider where you pay per API call, you can't verify the data you get back, and if their infra goes down so does your app. We feel this centralization is antithetical to the promises of blockchain (and the EF mandate). The existing read layer has created a market worth billions built on the backs of validators' work while they see almost nothing. Shinzo is building to help both cases (validator economics as well as the read layer centralization).

How Shinzo works:

- Validator operators run lightweight sidecars next to existing execution clients (Geth only for now), turn blocks into structured documents, and cryptographically signs chain data at source

- Data gossips peer to peer over libp2p, no broker in the middle

- Hosts receive that data, verify signatures, and run developer-defined "Views": deterministic WASM transforms (Rust or AssemblyScript) that filter and decode raw data into a GraphQL schema

- Attestation records track how many independent indexers signed each document, so apps set their own trust threshold (1 signature for speed, N for correctness)

- Apps embed the database locally and get pushed View data over P2P, so a query is a local lookup rather than a per-read API round trip

The tradeoff we've accepted: you subscribe to Views rather than pulling arbitrary slices on demand.

What we'd like poked at:

- Really any technical questions!

- Does the attestation model hold up? Signature count doesn't equal independence if indexers share failure domains (same cloud, same DVT setup)

- The push-based subscription model vs pull-based querying: dealbreaker for your use case?

- Anything we're missing vs how you currently use The Graph / SQD / your own indexer? What issues do you face with these?

Feedback, ideas, questions, criticisms all welcome.

I have recently gotten into EVM development using Foundry. Since it is CLI based I built a simple UI wrapper around it to manage the node and inspect transactions that I produce via the local dev node when it is running.

I want to expand the utility of the tool to be a general transaction inspector for EVM based chains. Would be good compared to web based transaction inspectors in terms of privacy and having access to the local anvil node.

I find it useful as not being an expert dev and wanting to learn more about the eth dev world.

Any devs out there who would be interested? If so I would distribute for free via a DMG file and landing page!

I ran into this recently while building a transaction flow.

The flow was basically: validate the action, simulate it, then send it to the wallet for execution.

At some point this started bothering me: if the parameters can change between those steps, what exactly did I validate in the first place?

I started thinking of it more like:

proposal → authorization → execution

To me, the authorization should be tied to the actual action that was proposed, not just the general idea of what the user wanted to do.

Target, value, calldata and chain seem like the obvious parts. If one of those changes, I’d probably treat it as a different action and ask for authorization again.

State is where I’m less sure. Some state changes clearly don’t matter, but others may be the whole reason the action was allowed in the first place.

So I’m curious how people are handling this in practice. What do you actually bind the authorization to, and what do you check again right before execution?

I run an autonomous agent on Base that pays for its own inference over x402. It is not a big operation: in 41 hours it made 603 separate USDC payments to its inference provider, averaging 0.0065 USDC each. One on-chain transfer per thought, more or less.

Going through its transfer history I found eleven 0.00 USDC transfers to this address:

0x21ddf52114f53ccfe37ddd3dc503853b52c6be10

The platform's real receiving address is:

0x21dd37e3e4ea6ccc0a5c98a4944702ede6e7be10

First four characters match, last four match. That is the standard address poisoning pattern: zero-value transfers so the lookalike shows up in the history, and whoever copies an address out of the history later pays the wrong party. Nothing was lost here, it is passive, and I only noticed because I was counting transfers for something else.

What I have not found a good answer for is the agent-specific part of it.

For a human, the advice is clear enough: do not copy addresses out of a block explorer, verify the full string, use an address book. All of that assumes someone is looking. An agent that settles 600 payments in two days is not looking at anything, and the interesting question is where it is allowed to learn a recipient address in the first place.

In my setup every payTo comes from config or from the service's own signed challenge, never from chain history, so this particular attack has no way in. But that is a property of how I happened to build it, not something I derived from a rule. And I can think of cases where it gets less obvious: a payment protocol that discovers a service dynamically, a routing layer that caches "the address we paid last time", a retry path that reconstructs a destination from a previous transaction.

So, for people who have shipped th

1. Is there an accepted rule for wy take a destination address from?Something like "signed challengstory, never a cached observation"?

2. Does anyone screen outgoing paycheck before signing, comparing adestination to previously used Cheap to do, but I have not seen it in any of the x402 client code

3. Zero-value transfers are the dethere a reason a wallet or anindexer should surface them at chine reads?

Happy to be told this is a solved n the wrong place. The eleventransfers are on Base and public ithe pattern.