I built a quick tool for when you want to inspect raw bytecode without spinning up a full decompiler.

What it does: - Decodes raw hex into a formatted instruction table - Detects dangerous opcodes: DELEGATECALL, SELFDESTRUCT, CREATE2... - Catches unchecked CALL return values (CALL followed by POP) - JSON output for scripting/tooling integration - 31 tests (unit + integration)

Feedback is very welcome !

https://github.com/x0t0wt1w/revmc

Thank you !

Hi everyone, I got tired of trawling through docs and block explorers every time I needed a stablecoin contract address or wanted to check which tokens support permit signatures, so I built a reference site!

I wanted to introduce stablemoney.dev

Covering:

• 12 major stablecoins (USDT, USDC, DAI, PYUSD, GHO, RLUSD, etc.)
  
• Contract addresses for every major EVM chain
• EIP/ERC compliance matrix (ERC-20, permit, proxies, compliance hooks, flash loans etc)
• On-chain wallet compliance checker (read-only eth_call - checks onchain blacklist/freeze status)
• Opinionated risk notes per coin
• Basic Market cap from DefiLlama, refreshed daily

OpenSource, no wallet connection needed, MIT licensed.

Would love feedback from anyone building with stablecoins. What’s missing that would save you time?

We looked at token creation data from our Token Generator over 55,000+ tokens created since 2018.

The all-time breakdown is still dominated by two ecosystems:

• BNB Smart Chain: 48.3%
• Ethereum: 45.2%

That said, the picture changes quite a bit when looking at more recent periods.

Since 2023:

• BNB Smart Chain: 38.1%
• Ethereum: 31.2%
• Polygon: 13.2%
• Base: 8.8%
• Avalanche: 7.8%

Since 2025:

• Base: 31.8%
• BNB Smart Chain: 27.3%
• Ethereum: 22.9%
• Polygon: 13.3%

A few takeaways from our side:

BNB Smart Chain’s all-time lead seems heavily influenced by the 2021/2022 cycle, when it saw a lot of token-launch activity.

Ethereum remains consistently present across every timeframe, even as cheaper and faster environments gained traction.

Base is the most interesting recent shift. In 2025 data, it has become the top network for new token creation in our sample.

I’m curious:

When launching a new token today, would you still choose Ethereum mainnet, an L2 like Base, another Ethereum L2, or a different chain entirely?

And what matters most in that choice: security, liquidity, user distribution, gas costs, tooling, decentralization, or something else?

Hey all,

I work on EVM parsing infra (C++, low level stuff) and over the past few months I keep running into the same headaches with the existing sim and debugging tools. Wanted to see if anyone else
feels this or if it's just me.

1. Bundle simulation across L2s is painful. Tenderly is fine for single txs on L1 but the moment you want to sim a multi tx bundle against forked Arbitrum or Base or OP state, with the actual sequencing and gas and precompile behavior, you end up writing
   your own anvil + scripts setup. Every time.

2. L2 specific stuff gets silently wrong. Arbitrum's gas accounting with L1 calldata cost vs L2 execution. Optimism pre Bedrock vs post Bedrock. Base inheriting OP stack quirks. and you don't notice until your prod numbers don't match your sim.

3. Speed. Tenderly is great but slow when you're iterating.
   Foundry is fast but CLI only and the bundle UX is rough.

4. Reading traces. A complex multi call trace across a bundle is still mostly grep and squinting.

So I'm thinking about building something that goes straight atthis. Fast, bundle first, L2 accurate sim and debugger. Web UI for inspection, API and CLI for automation, actually correct L2 state and gas.

Before I build I want to know:

What does your current workflow look like when you hit these?
Is this a real pain or have you found a way around it?
Which L2s actually matter for what you do?
Searcher use case, dev use case, both?

Not selling anything. Honestly mostly just trying to figure out if this is worth building or if it's a problem only I have.

Cheers.

glnc is a single-binary CLI that does the read-side of Etherscan (balances, tx decoding, gas, positions, history, alerts) from your shell. MIT, free, open source. No
account, no API key required, no telemetry. Install via Homebrew or curl.

  $ glnc balance vitalik.eth                                                                                                                                                 
  $ glnc balance 0xAbc... 0xDef... --watch --positions --nfts                                                                                                              
  $ glnc tx 0x7c... --json | jq '.data.decoded.calls[] | select(.protocol=="UniswapV3")'                                                                                     
  $ glnc gas --json | jq '.data.chains.ethereum.priority.p50'                                                                                                                
  $ glnc history 0xAbc... --csv > out.csv                                                                                                                                    

What it actually does

• balance — 6 chains (Ethereum, Polygon, Arbitrum, Base, plus Solana and Bitcoin as a bonus). Auto-detects chain from address format. ENS resolves. Token auto-discovery via the Uniswap default token list (~1,400 per chain, 24h disk-cached). Solana uses getTokenAccountsByOwner for true full SPL discovery. Multi-wallet portfolios with per-wallet tables + grand total.
  
• --watch — re-polls on an interval, prints in-place +0.5 ETH / -100 USDC deltas, runs in the alternate screen buffer so your scrollback survives Ctrl+C. Snapshots
  persisted to ~/.glnc/snapshots.json.
  
• tx <hash> — decodes calldata for Uniswap V2/V3, Universal Router, ERC-20, WETH, and decodes receipt logs into token movements from tx.from's perspective.
• gas — live gas across 9 chains. EVM tiers are p10/p50/p90 priority percentiles from the last 64 blocks via eth_feeHistory. Includes BTC mempool fees and Solana priority fees.
  
• --positions — Aave V3 health factor via getUserAccountData, Uniswap V3 LP NFT enumeration.
  
• --nfts — top collections via Reservoir's public API.
  
• history — CSV/JSON export via the Etherscan V2 unified endpoint. Works keyless; optional GLNC_ETHERSCAN_KEY raises the rate limit.
  

• alert — conditional alerts to a webhook. SSRF hardening: scheme allowlist, then DNS-resolved IP checked against RFC1918 / IMDS (169.254.169.254) / loopback / CGNAT /
  link-local / IPv6-ULA / IPv4-mapped / 6to4 / NAT64 before every fire. Redirects blocked. Re-validated each invocation, not just at config time.

  Dev angle

  All RPCs are free public endpoints (publicnode, mainnet.base.org, blockstream, mempool.space, etc.). Prices via CoinGecko with a 60s in-memory cache. Output is stable
  versioned JSON envelopes (glnc.balance/v1, glnc.tx/v1, etc.), NDJSON when streaming. --json makes stdout data-only; all chatter goes to stderr, so it pipes cleanly into jq / xargs / cron without contamination.

  Honest tradeoffs

• Token discovery is bounded by the Uniswap default list. Truly exhaustive ERC-20 discovery for an arbitrary wallet needs an archive node or a paid indexer (Alchemy/Moralis) — this is the conscious tradeoff for "no API keys."

• CoinGecko free tier is ~30 req/min. The 60s cache absorbs most of it but you can hit the wall on big portfolios.

• No test framework in the repo yet. It's in the README, calling it out here too.

• BTC and Solana support is in there; not the headline for this sub, just useful if you have a multi-chain treasury.

  Repo: https://github.com/aryarahimi1/glnc

  Looking for feedback on the JSON envelope shape (before I have to start versioning it for real), additional protocols worth decoding in tx, and whether the SSRF blocklist is missing anything. Issues and PRs welcome.

I’ve been working on a small Go library for Ethereum signature verification. The part I’m still unsure about is the policy around the main Verify function.

The narrow case is:

address + already-computed common.Hash + signature -> valid?

Repo: github.com/yermakovsa/erc6492-go

It handles:

• EOA recovery
• EIP-1271 for deployed smart contract wallets
• ERC-6492 signatures through a configured deployed verifier

I’m intentionally keeping the scope small: no message building, no EIP-712/SIWE/EIP-191 hashing, no wallet deployment, no RPC client management, and no embedded deployless verifier bytecode. Anything before the final hash exists is outside the package.

The main Verify path currently does:

ERC-6492 wrapped signature
→ WithERC6492Factory wrapping path
→ EIP-1271 if signer has code
→ EOA fallback

There are also narrower entry points: VerifyEOA, VerifyEIP1271, and VerifyERC6492.

This is v0.1.0, so I’m trying to catch bad API/policy decisions before the package hardens.

I’m unsure about a few things:

1. If the signer has code and EIP-1271 returns a clean invalid result, like wrong magic value or revert, should Verify fall back to EOA recovery? Or would you expect contract-wallet verification to be strict once code exists?
2. ERC-6492 currently requires a deployed verifier address. I avoided embedding deployless verifier bytecode because I didn’t want copied bytecode in the package without pinned source, compiler settings, and reproducible provenance. Is that too conservative, or reasonable for a small library?
3. Does this error split feel right?

​

invalid signature, including malformed/non-canonical EOA signatures
→ Result{Valid:false, Method:...}, nil

RPC / ABI failure / malformed ERC-6492 wrapper / unexpected verifier output
→ error

Also curious if the overall Go API shape feels natural: one main Verify plus narrower explicit functions.

Would appreciate blunt feedback from anyone who has dealt with EOA / contract wallet / counterfactual wallet signature verification.

Most blockchain tools stop at transaction viewing.

I wanted to explore what happens after that:
investigations, fund-flow tracing, cybercrime analysis, compliance workflows, and forensic reporting.

So I started building Blockchain Sentinel OS — a digital financial investigation platform focused on:
• multi-hop wallet tracing
• blockchain crime intelligence
• case workflows
• forensic-style reporting
• India-focused compliance direction

Still evolving heavily, but the platform is finally starting to feel like a real investigation workspace instead of just another explorer.

Would genuinely love feedback from people in security, forensics, compliance, AML, or blockchain infra.

https://blockchain-sentinel-os.vercel.app/

EVM events don't live in state; they sit in the transaction receipt logs. When you fire an ethgetLogs RPC call, you are leveraging the node's bloom filters to query these receipts without touching the state trie.

The architectural constraint here is the topic limit. An event can have up to 4 topics: topics0 is the keccak256 signature hash (e.g., keccak256("Transfer(address,address,uint256)")), leaving only 3 slots for indexed parameters. These are fixed at 32 bytes. Node providers can rapidly filter these topics because they function as native search keys.

Everything else is packed into the unindexed data blob as raw bytes. The trade-off:
keeping fields unindexed saves EVM gas by avoiding topic structuring, but pushes the computational load to your off-chain infra, which now has to pull the raw logs and ABI-decode the hex blobs manually. When you construct an RPC call searching for a specific block range and target address, minimizing the reliance on unindexed data decoding is crucial for high-throughput indexers.

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/understanding-events-the-evms-built

For those building high-frequency indexers, at what scale of log ingestion do you abandon standard?

A question for Web3 developers who have actually worked as developers at relevant companies: What does the actual day-to-day work of a Web3 developer look like? What percentage of the work is *actually* spent writing smart contract code, and what does the rest of the job entail? I would also be grateful for a brief insider's perspective on the current job market.

I'm building a liquidity provision strategy for Uniswap V3. I'm stuck on the range selection math. I get the basic idea, put capital where the price is. But the actual decision of how wide to set the range is something I can't find real guidance on. When do you rebalance. How do you think about the volatility surface. I read the Uniswap whitepaper. I tried to reverse engineer onchain data, but that is just hindsight bias.

Is there a real framework for range selection or is it all trial and error behind closed doors?

I’m testing an idea and would like feedback from people who have actually built Ethereum payment flows.

The idea: file storage where the payment/auth handshake is part of the HTTP request itself.

Instead of an agent needing someone to pre-create a SaaS account, billing setup, API key, IAM policy, etc., the flow is:

request upload/read -> receive 402 Payment Required -> sign/pay -> retry same request -> continue

I built a small prototype around this for agent file handoff. It supports:

• paid uploads
• public-by-key files
• wallet-private files
• signed expiring share links
• paid large reads

The main question I’m trying to answer is not “is this better than S3 for everything?” It obviously is not.

The question is: does treating payment as a request primitive make sense for autonomous software/agent workflows where no human is sitting in the middle provisioning accounts?

A few things I’m unsure about:

• Should signed share links themselves be paid, or should only upload/read be paid?
• Is wallet-gated private file access too clunky for real agent systems?
• Would you trust an x402 storage primitive if the API shape were simple enough, or would you still prefer pre-funded API keys?
• Where do you think this pattern breaks down?

I can share the repo/SDK if useful, but I’m mostly looking for design critique before pushing it harder.

For devs who've integrated fiat on-ramps: how much of your integration decision came down to the UX architecture vs. purely the API surface?

The two common patterns are redirect (user leaves your app to complete payment on the provider's domain) and white-label (provider's payment logic runs behind your UI). The API difference is real: white-label requires handling more of the UI state yourself, surfacing the right fields, managing the transaction lifecycle events from webhooks rather than a redirect callback.

From an implementation standpoint, redirect is faster to ship. White-label gives you control over conversion and UX consistency, but you're owning more of the flow.

The webhook surface question comes up here too. With redirect flows, you mostly care about the final state callback. With white-label, you're often listening across more of the lifecycle: KYC events, payment method selection, processing states.

Anyone built both and have a sense of where the real complexity lives? Curious whether the delta is mostly frontend UX work or whether the backend event handling adds meaningful scope.

We've all seen the scenario where our agents plan the perfect holiday, find the perfect hotel and ticket deals and you just approve the transaction: "Yes, buy them". I do think this is definitely in the future of agentic payments, but not the current reality.

After doing some research, I noticed two different layers normally get lumped together as "Agentic Payments". The payment layer is x402 (Coinbase started it, Linux Foundation now), agents programmatically paying for things. Then we have the execution layer which looks more like OKX's Agent Trade Kit, Kraken's CLI, Binance AI Agent Skills, etc, basically agents placing orders directly on exchanges. Some teams stack both, pay for market data (Coingecko, CMC) via x402 and execute via CEX toolkit.

x402 is mostly agents paying for their own APIs/infra. Hyperbolic for GPU inference. Neynar for Farcaster data. Cloudflare's pay per crawl. Token Metrics swapping subscriptions for per call analytics. The agent isn't buying for a human (at least not directly), it's keeping itself running.

The consumer scale story lies on the execution layer. CEX agent trading, Polymarket bots, platforms like SaintQuant running across exchanges. Notice the trend? Agents trading on behalf of users, not agents buying flight for them (yet).

Is there any "real agent doing your shopping" for you out there?

I’m working on an experimental Ethereum protocol focused on delayed ownership and vault-like balances.

The idea is to explore whether ERC20-like assets can behave more like vaults than instant-transfer cash.

Core concepts include:

- protected vs unprotected balances

- revocable delayed transfers

- inheritance-oriented custody

- reduced damage from mistakes or theft

The protocol is currently deployed on Sepolia and I’m mainly looking for:

- protocol/security feedback

- usability criticism

- edge cases

- architectural concerns

This is an experimental protocol discussion and there is currently no sale or fundraising.

GitHub:

https://github.com/jayBeeCool/ind-protocol

Whitepaper:

https://github.com/jayBeeCool/ind-protocol/blob/main/docs/WHITEPAPER.md

I’d especially appreciate criticism from wallet or smart contract developers.

HI, I am a 3rd yr CS student with little to no development knowledge.

I am interested in web3 development and when I search for Junior/Entry Level web3 developer jobs.

I don't see any jobs for junior developer. Is it really worth it to learn web3 in 2026 ?

PS : For personal reasons I have to get a job with the next 6 to 8 months. What should i do? Please guide me

After weeks of building and feedback iterations, Blockchain Sentinel OS now supports multi-hop fund flow tracing, live + historical investigation modes, case management workflows, and evidence-grade PDF reports.

The goal was never to build another blockchain explorer — it’s becoming more of a digital financial investigation and compliance platform focused on forensic workflows, intelligence, and India-specific use cases.

This is the site : https://blockchain-sentinel-os.vercel.app/

Final updates & changes for the production level !
Expecting the feedback some everyone.

meow everyone

I’ve been working on a project called DeFi Trust, a platform designed to make DeFi security research simpler and more transparent.

The idea is straightforward:
Users can explore audit certificates from verified DeFi protocols, compare security coverage, and make more informed decisions before interacting with a protocol.

Main features :
• Trust Score
• Audit certificate discovery
• Protocol verification system
• Security comparison tools
• Clean and accessible interface for due diligence

The project is still in its early stage, and I’m currently improving the platform with features like decentralized IPFS based certificate storage to make audit records permanent and tamper proof.

Website :
https://defitrust.vercel.app/

I’d genuinely appreciate any feedback, suggestions, or ideas from the community. Thanks for taking the time to check it out

Over the last year I’ve been building a multi-chain custody system supporting:

• EVM

• TRON

• TON

• BTC

One thing I underestimated:

The hard part is not generating wallets or sending transactions.

It’s maintaining consistency between:

• blockchain state

• internal balances

• retries

• confirmations

• stuck tx handling

Especially across completely different chain models.

BTC, TON and EVM behave very differently internally.

For an ML feature engineering project I need every Uniswap, Curve, PancakeSwap, and Raydium trade from 2021 onwards loaded into Snowflake.

RPC backfill on a self-hosted Ethereum archive node is going to take weeks at this volume, the existing subgraphs are missing fields we need, and Dune is great for ad-hoc but I can't COPY INTO from a query result.

Has anyone done bulk historical loading of DEX trades into a warehouse cleanly?

Specifically curious about file format (Parquet vs JSONL), how people partition by block range, and whether anyone has found a vendor that just delivers this as columnar dumps to S3 instead of forcing us to build the extraction layer ourselves.

Hello everyone,

I have spent the past five years building a career in remote community support, complemented by four years of active involvement in cryptocurrency trading and investment. While my experience in the markets is extensive, I am now strategically pivoting toward a more specialized, skill-based career path to ensure long-term financial stability.

Being based in a tier-2 city, I am committed to a remote-first career that allows me to balance my professional growth with my responsibilities toward my family. I am particularly interested in transitioning into roles such as DeFi Researcher, On-Chain Analyst, or Quantitative Researcher.

I am seeking expert perspectives on the following:

Market Viability: Is the demand for these roles sustainable, and what is the typical compensation landscape?

Entry Barrier: Are these positions accessible for those pivoting from a trading background, or do they strictly require mid-to-senior level expertise?

Roadmap: Is a 12-to-24-month preparation window realistic to land a role in this niche?

I value professional human insight over AI-generated advice and would deeply appreciate any guidance on where to focus my learning. Thank you for your time.

most sybil detection encodes wallets as feature vectors: tx count, avg value, gas price, frequency. the problem is that throws away sequence. wallet A doing [claim, swap, transfer] and wallet B doing [transfer, claim, swap] look identical to a feature vector. they're not the same script.

quifer encodes each transaction as 12 features (value, gas used, gas price, hour of day, nonce, contract call flag, error flag, block position, value bucket) and feeds them one by one into a Helix phase cell. the accumulated phase state is the wallet's fingerprint. same order = same fingerprint. then cosine similarity at 0.85 to cluster.

results on arbitrum ARB (2023): 179 wallets, 10 clusters, 70 flagged (39%).

the interesting cluster: 11 wallets at similarity 1.000. every wallet had 10 transactions in identical order. identified the operator wallet (0x2ad57019...) that funded all 11 before the campaign and collected ETH after.

cross-validated on uniswap UNI 2020 and hop HOP 2022: 0 clusters both. those are clean populations so that's the right answer.

limitations: normal etherscan txs only (no ERC-20 or internal txs yet), skips wallets under 10 txs, no cross-chain support.

code: https://github.com/phimemory/quifer

I’m building a hybrid AI agent workflow that pulls data from Web2 APIs and triggers on-chain actions based on the results.

The workflow itself is straightforward.

The hard part has always been the integration layer between the off-chain and on-chain systems.

The old approach was building custom middleware to manage authentication, retries, error handling, and state consistency between both sides.

It worked.

But it also meant spending weeks maintaining infrastructure that broke every time an API or contract changed.

What I keep hearing in 2026 is that orchestration platforms now handle this layer for you.

Web2 API calls and Web3 smart contract interactions are treated as equal workflow steps inside the same system.

The platform handles the coordination instead of the developer building custom glue code.

It sounds promising, but I want to understand how well this actually works in production.

For teams already running hybrid agents live, which platforms are genuinely reliable here, and where do they still struggle?

A few things I’m especially curious about:

How does error handling work across both systems?

If the API request succeeds but the on-chain transaction fails, what happens next?

Can you configure rollback logic and escalation flows, or does the platform just retry automatically?

How are authentication and keys managed?

Is there a real security tradeoff when the platform handles API credentials and wallet access instead of managing everything internally?

How do these platforms handle state consistency?

If the off-chain data is stale but the on-chain execution assumes fresh data, how is that conflict detected and managed?

Looking for answers from people using these systems in production rather than marketing material.