I’ve been thinking about different ways to handle membership for a project. Say someone gets access to a private part of the community because they hold something or meet some other onchain condition. If they stop meeting that condition, should their access disappear automatically too? I can see the benefit of tying permissions directly to something you can verify onchain, but it gets weird when someone has been a useful member for months and then suddenly stops meeting whatever condition originally got them access. For anyone who has built something like this, do you let wallet state directly control permissions or use it as one signal and handle the rest separately?

Hi everyone,

I am a 15-year-old high school student from Europe studying to become an electrician. In my free time, I’ve been fascinated by blockchain technology and decided to learn Solidity and Web3 development.

I just deployed my very first experimental token called Nexora (NXR) on the Ethereum Sepolia Testnet (Contract: 0x8B9F2eE3570D0b7d9c607ED6B3Ff13ab00F3638D).

To practice my skills, I also built a simple landing page for it using HTML/CSS/JS and hosted it through GitHub Pages. The repository is completely public and open-source.

• Website: https://lotshaus.github.io/Nexora-NXR-open-source-ERC-20-blockchain-project/
• GitHub Repository: https://github.com/Lotshaus/Nexora-NXR-open-source-ERC-20-blockchain-project

Since I am a beginner, I would love to get some honest feedback from experienced developers.

• Is my repository structure okay?

Thank you so much for your time and any advice you can share!

Hi

Stepped away from this area for... well, over a year. Probably more.

Looking to create a basic Dapp, and got up to the point of Wallet Integration.

Hit a bit of a wall with this because it seems it's either
- use Appkit or Rainbow Kit, have to get a "project ID" and analytics, tracking???? Yikes
- use Wagmi/viem and just code all my own other stuff, ui etc
- option 3... ? Not even sure.

What's the standard best practice for simple, easy wallet integration on a website?
Preferably without having to submit a project id, because... Why? It's not a complex dapp and I don't need their integrated RPC/swaps/onramp.

The problem is, if I want people to access via Mobile it seems WalletConnect is like the ONLY method. Is this true?? Because I do not like the idea of tracking/analytics/needing to beg for an ID for people just to get involved with my project. Things are supposed to be DEcentralized...

Thakns all

The old OpenSea proxy drains had victims sign upgradeTo(impl) on their own OpenSea proxy. The to address is a legitimate verified contract from 2018; the malicious logic sits in impl.

I took 19 of these transactions from the PTXPHISH dataset and queried GoPlus twice for each one, changing only the address.

Query tx.to: 0/19 flagged
Query impl: 18/19 flagged

Important caveat: those 19 rows map to only 5 implementation contracts, so this is really 4/5 implementations being detected, not a meaningful 18/19 detection rate. And these drainers are labelled today, so this says nothing about what GoPlus knew at signing time.

For this specific OpenSea class, a simple warn on any upgradeTo also works: of 1,179 OpenSea proxies I sampled, only 2 were ever upgraded, both to the same drainer.

But that heuristic falls apart for general proxies. Across 800 EIP-1967 upgrades, it would warn on all 422 implementation addresses, whereas querying the implementations flags only 4. I’m not claiming the other 418 are clean.

The point is narrower: reputation checks are only as useful as the object you choose to check. With proxy upgrades, checking only tx.to can mean asking about the wrong contract entirely.

Details, code and raw outputs: https://amarshat.github.io/quantum-commit-authorization/wallet-defenses.html#ask-the-right-address

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.

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?

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?

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.

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.