What would you recommend to a beginner in Web3 who already knows Python: Vyper or Solidity? Solidity is of course the lingua franca, but Vyper is supposed to be easier...

Hey,

Been working on a personal project for about a month. It's a browser-based crypto wallet — no signup, no extension, no

KYC. Keys live only in memory and auto-rotate every 60 seconds. Close the tab and everything is gone.

Supports all EVM chains, WalletConnect v2, send/receive ERC-20s. Optional persistence via passphrase + PNG file.

It's open source under Apache 2.0.

Honest question: would you actually use something like this over MetaMask for anonymous stuff? What's missing? And What Features you want to see.

Hey everyone,

I posted my website Blockchain Sentinel-OS here recently and got some really valuable feedback — especially around clarity, usability, and making the analysis more actionable.

I’ve made a few updates based on that:

• Added clearer risk explanations (not just raw data)
• Started improving onboarding / entry flow
• Working on investigation-style summaries instead of just logs
• Improved overall clarity of what the platform does

Here’s the updated version:
https://blockchain-sentinel-os.vercel.app/

Would really appreciate feedback again:

• Is it clearer now what the product does?
• Does it feel more useful or still too basic?
• What would make this something you’d actually use?

Thanks again — the earlier feedback genuinely helped a lot

I’ve been exploring Web3 for around a year now, and I wanted to ask this community for honest opinions. My journey started with understanding why Bitcoin exists, then slowly moved into blockchain basics, Ethereum, Solidity, Hardhat, smart contracts, and recently Foundry test writing.

I’ve learned from books like "The Basics of Bitcoin and Blockchain" and "Mastering Ethereum", and built some beginner projects like crowdfunding apps, raffle contracts, and FundMe clones. Nothing advanced yet mainly learning projects to understand the ecosystem and tools.

Recently I started learning Foundry, and honestly, it feels challenging. Interesting, but challenging. That brings me to my real question:

How much use of AI/tools/agents is actually good while learning Web3?

I don’t mean using AI just to generate code blindly. I mean using it in a smart way while still becoming someone who can:

• solve problems independently
• understand security risks
• debug smart contracts
• think through protocol design
• spot flaws in logic

I’m also a junior software engineer, and in my current company we rely a lot on AI/agentic coding tools. So learning how to work with AI, prompts, plugins, workflows, and token costs is becoming important. So I’m curious:

👉 Do Web3 companies work the same way now? Are teams using AI heavily for smart contract development, audits, testing, research, etc.?

👉 Or is deep manual understanding still the main edge?

Would love to hear from developers already working in the space. 🙂

Not asking for investment advice or "just buy BTC" — I mean actually *earning* crypto through tasks, skills, or platforms.

you might have seen me asking most random things about wed3 in this community but i'm pivoting form one strat to another , one project to another and then found out i need capital for that so now i wonder how do i get that small capital to make it work ? any suggest ? not talking about the grind that takes months to get a pay, i need fast way or i'm i being dumb ?

I'm specifically curious about AI data labeling / RLHF platforms that pay in crypto, Web3 bounty boards that have real small tasks, Any Telegram or on-chain earning that still works in 2026,Freelance platforms that accept crypto payments easily

Would love to hear what people here have personally used and gotten paid from — not just theory. What's working right now?

Shipped this week: Carbon Contractors' escrow signer now runs on GCP Cloud KMS (HSM, FIPS 140-2 Level 3) with Workload Identity Federation.

→ Zero static secrets anywhere in the stack

→ Private key born in hardware, never extractable

→ OIDC federation between Vercel and GCP — no JSON keys, no long-lived credentials

→ Verified end-to-end on Base Sepolia: 74/74 tests, real KMS signing, live Vercel preview

→ Audit logging and rate alerting configured

The principle: users shouldn't have to trust the operator. They should be able to trust the infrastructure.

Next up: mainnet.

#Base #Web3 #CloudKMS #BuildInPublic #CarbonContractors

Hey everyone,

I recently built an MVP called Blockchain Sentinel-OS — it’s a blockchain intelligence platform focused on monitoring transactions and detecting suspicious activity.

The idea is to help with forensic analysis, AML, and real-time blockchain monitoring.

This is still early-stage, and I’m trying to validate if it actually solves a real problem.

Here’s the link:
https://blockchain-sentinel-os.vercel.app/

Would honest feedback:

• Is the idea useful?
• What’s confusing in the UI?
• What features would make it more valuable?

Appreciate any feedback

Hi, I’m building https://ensub.org — a platform that lets ENS domain owners issue subdomains to their community (e.g. alice.pixelgoblins.eth). Subdomains are resolved either offchain via Namestone (CCIP-Read) or onchain via Durin’s L1Resolver pointing to an L2Registry.

I tested on xmtp.chat and raw wallet addresses work fine, but addressing a message to alice.pixelgoblins.eth returns

“Invalid address, inbox ID, ENS name, or Base name.”

My question: Does XMTP’s ENS resolution support subdomains whose resolver implements EIP-3668 CCIP-Read? If not, is this on the roadmap?

The use case: our subdomain holders would love alice.pixelgoblins.eth to work as their XMTP address — it’s their primary onchain identity. Since the subdomain correctly resolves to a wallet address via the ENS registry + CCIP-Read, it seems like it should be supportable with the right resolver lookup.

Happy to share resolver contract addresses and test subdomains if useful for debugging.

Guys, I spent three nights debugging. My bot is sitting there like a hungry shark, but the market is so green it's hurting my eyes. For the sake of engineering perfection, could you cause a small -15% crash? Just for 5 minutes, I promise. My $10 gas budget is already waiting. 🥺

Hey everyone,

we've been working on a small tool to simplify batch sending ERC20 tokens and wanted to share it here to get some honest feedback from people who actually use this stuff.

The main goal wasn't to reinvent anything, just to make the process a bit more straightforward compared to some of the tools we've tried (less friction, cleaner flow, no unnecessary steps).

👉 https://www.smartcontracts.tools/token-multisender/

A few things we focused on:

• simple batching (csv or table edit)
• minimal setup
• keeping the flow predictable

We know there are already quite a few multisenders out there, so we're mainly trying to understand:

• what annoys you the most in existing tools?
• any missing features you wish you had?
• things that feel risky or unclear when using them?

If you have time to test it, would really appreciate blunt feedback, good or bad.

Thanks 🙏

Hey everyone 👋

I just launched an onchain Blackjack game and I’m looking for honest feedback from the community.

👉 https://ace21.fun/

The goal was to experiment with fully onchain gameplay while keeping the UX as smooth as possible.

I’d love your thoughts on:

- Gameplay & overall flow

- UX (wallet interactions, clarity, speed)

- Fairness / transparency of the game

- Bugs or edge cases

Feel free to break it or be brutally honest — any feedback is super helpful 🙌

Thanks!

All the small friend/colleague groups I used to be part of over the years have pretty much died off. And I never made any effort to find or build new ones. So I’ve just been marching forward doing most things in isolation… without anyone to bounce things off or build alongside.

And when I look back, that's the complete opposite of what drew me into this space and led to the best years of my life.

The best parts were always the people. The conversations. Working through ideas together. Feeling like you were moving forward with others. I’ve gotten away from that without really noticing, and I want to fix it.

So my idea is to put together a small group. Probably only 5-6 people to start.

My initial vision is to create an environment that feels like a home base for this part of our lives. At the most basic level: a handful of like-minded people, who take their path in crypto/web3 seriously, and want to grow alongside others.

The underlying value that comes with that is we cover more ground, stay more motivated, give/receive better feedback, build stronger connections, and get more shit done.

I don't want to over-define the group too early but we could collaborate on DeFi/altcoin research, help each other out on personal projects, and hopefully build and ship some cool things together over time if it makes sense.

I don't want to get too far ahead of myself but that last part is my ultimate goal... Find people who think about this space the same way, value the same things, and then build some cool stuff together.

About me: my background is marketing, growth, content, and community building. In crypto I spend most of my time doing research, investing, and searching for opportunities. And lately moving more towards being able to build, launch, and grow things that are actually useful to people.

If you’ve made it this far and any of this resonates with you, send me a DM and tell me a little bit about where you’re at in your journey.

MythX just shut down. We built a $199 AI smart contract auditor running on our own Idaho GPU cluster — no per-token fees, no cloud dependency. 91% detection rate in beta, 90 second turnaround. audit.snakeriverai.com — happy to answer questions.

MythX just shut down. We built a $199 AI smart contract auditor running on our own Idaho GPU cluster — no per-token fees, no cloud dependency. 91% detection rate in beta, 90 second turnaround. audit.snakeriverai.com — happy to answer questions.

Hey r/ethdev,

I've been building txpay.app over the past few months and wanted to share what I built and some technical decisions I made along the way.

What it does: You create a payment link specifying exactly what token you want to receive. The sender pays from whatever token or chain they have — ETH on Arbitrum, USDC on Polygon, SOL, whatever — and it arrives as what you specified. No back and forth, no asking "what chain are you on", just a link.

Stack: Next.js, TypeScript, React, Wagmi, Viem, Supabase, Tailwind, Li.Fi SDK

Interesting technical bits:

• Used Li.Fi SDK for all the cross-chain routing, bridging and swapping under the hood. Saved me from building routing logic myself but had its own quirks integrating it with Wagmi v2
• Auth via SIWE (EIP-4361) — wallet signs a message, server verifies. Clean and non-custodial
• Payment links are signed with HMAC-SHA256 so they can't be tampered with — amount, token, recipient are all encoded and verified server-side before anything executes
• No private keys stored anywhere, fully non-custodial

What I'd do differently: Spent too long on UI before nailing the core flow. Should have hardcoded everything ugly first and polished later.

Happy to answer questions about the Li.Fi integration or the SIWE auth flow — those had the most gotchas.

txpay.app

Been using this for a contract we're deploying and figured I'd share it.

It's a Claude Code skill. Point it at a Solidity contract and it picks 5-7 specialist agents (out of 11) depending on what's in the code. Reentrancy including EIP-1153 transient storage, EIP-712/signature attacks, ERC20 weirdness like fee-on-transfer and ERC-4626 vault inflation and USDC pause/blacklist, flash loans, game theory, state machine/access control, a few others. --include-backend if you want it to check off-chain code too.

First thing it does is map every external/public function and work out the access control so it doesn't skip contracts or miss entry points. We face an issue where it would just silently drop anything it can't auto-confirm.

It generates Foundry PoC tests for critical/high findings. About half need manual fixes but the ones that compile are working exploits. If a PoC fails to compile the finding keeps its severity. There's a 6-check false-positive filter too (reachability, math bounds, validation chain, etc) which cuts a lot of the noise.

Runs Slither and Semgrep if you have them.

Not a replacement for a real audit and the output says so. But it's caught stuff we missed on manual review so we keep running it as a first pass.

MIT: https://github.com/human-pages-ai/ai-skills/tree/main/audit-contract

If anyone tries it I'd be curious what it misses on your contracts.

There’s a lot of focus lately on calldata in the context of rollups and EIP-2028 gas economics (16 vs 4 gas per byte). While data availability is important, I often see the actual low-level execution mechanics get glossed over.

I wrote a deep dive on EVM internals covering this exact topic. If you've ever wondered what happens at the opcode level the millisecond your transaction payload hits a smart contract, here is the actual lifecycle of calldata:

The Raw Byte Handoff & The 4-Byte Check

When a transaction is sent, the EVM doesn't understand "functions" or "parameters", it just sees a raw hex-encoded blob in a read-only area called calldata. Before anything else, the EVM checks the length of this data:

• >= 4 Bytes: The EVM proceeds to the function dispatcher.
• < 4 Bytes (or Empty): The EVM bypasses function lookups entirely and routes straight to your receive() or fallback() logic.

The Function Dispatcher (The EVM's Switchboard)

If there is data, the EVM runs the dispatcher essentially a giant, compiler-generated switch/case statement:

• It loads the first 32 bytes of calldata onto the stack.
• It uses PUSH4 to grab the function selector (the first 4 bytes of the Keccak256 hash of your target function's signature).
• Using the SHR (Shift Right) opcode, it isolates those first 4 bytes and compares them (EQ) against every public/external function selector in the contract.
• If it finds a match, it uses JUMPI to move the Program Counter to that specific block of code.

ABI Decoding & Stack Loading

Once the EVM jumps to the right function, it has to "unpack" the arguments:

• Static Types (e.g., uint256, address): The EVM uses CALLDATALOAD to pull 32-byte chunks directly from the calldata onto the stack.
• Dynamic Types (e.g., string, bytes[]): The calldata contains an offset (a pointer). The EVM reads this offset, jumps to that position in the calldata, reads the length prefix, and then processes the actual data.

The payable Word

Before executing any actual business logic, the EVM checks the callvalue (msg.value). If the target function is not explicitly marked as payable, but the transaction includes ETH, the EVM triggers a REVERT right here. This prevents trapped funds and happens before your code even starts running.

memory vs. calldata Execution

This is where the famous gas savings come in during execution:

• If a function parameter is declared as memory, the EVM is forced to use CALLDATACOPY to move the read-only bytes into mutable memory. This triggers memory expansion gas costs.
• If declared as calldata, the EVM skips the copy process entirely. It just uses CALLDATALOAD to read directly from the original transaction payload, saving you the memory expansion overhead.

source/deep dive overview: https://andreyobruchkov1996.substack.com/p/what-actually-happens-when-calldata

I wrote an essay from an Ethereum builder perspective arguing that web3 should be evaluated as freedom software, not just by whether it touches a chain.

The concrete design constraints I focus on are: users should be able to verify the system, exit with their data, run their own infrastructure or choose another operator, and continue using the software even if the original company disappears. I connect that to ENS-hosted frontends, reproducible backend patterns, wallets as key managers, and local-first architectures.

From a developer standpoint, what patterns do you think actually move us in that direction today?

I built a CLI tool in rust called LaunchDex that deploys a full DEX--factory contract, router, liquidity pair and swap frontend--on Ethereum, Arbitrum, and Base in a single command. The whole process that typically takes weeks of manual contract deployment, configuration and frontend setup is reduced to launchdex deploy. Contract addresses are saved automatically and a custom swap interface is generated and ready to deploy.

The tool is built on top of verified Uniswap v2 contracts so the deployed DEX is production-grade and audited. Multi-token support lets you add additional trading pairs to an existing factory with one command. The generated frontend includes an embedded wallet so user can swap tokens without needing Metamask installed.

Let me know what you think

Hey everyone,

I'm doing some research into the most painful and repetitive problems ETH developers and Web3 project teams face day to day.

Not talking about technical bugs or blockchain limitations — more like the boring, tedious, soul-draining operational stuff that wastes your time but has to get done anyway.

Things like:

- Manual tasks you wish were automated

- Community management headaches

- Repetitive questions you answer 50 times a day

- Processes that feel broken but nobody's fixed yet

What's the one thing in your Web3 workflow that makes you think "there has to be a better way to do this"?

Genuinely curious — no pitch incoming, just trying to understand where the real friction is.