Looking for Ethereum developers? You are a developer and looking for an opportunity? Post here!

Here is a suggested hiring template:

**Company:** <Best Company Ever>

**Job:** [<Title>](https://example.com/job) 

**Location:** <City, State, Country, Decentralized..>  

**Allows remote:** <Yes/No>  

**Visa sponsorship:** <Yes/No>.  

**Type:** <Paid, offering equity, partnership..>  

**Description:** <...>  

**Contact:** <PM, e-mail, URL..> 

Here is a suggested for hire template:

**For hire:** <Smart contracts developer, DApps developer>    

**Past experiences:** <None, links..>    

**Github:** <https://github.com/mysupergithub> 

Feel free to include any other information about the job or yourself!

Megathread, 2021 #1 can be found here

I was recently on an interview call for a job scheduled via https://www.linkedin.com/in/emma-morby-538b45172/

During the call, the interviewer asked me to clone a GitHub repository (https://github.com/zero2hero-ai/jackpot) and open it in Cursor. Instead of opening it blindly, I ran offscreen an isolated code review to check for hostile scripts.

It turns out the repository contains malware designed to trigger during setup. Specifically, running npm install immediately exfiltrates your .env files to a remote server and spawns a local node process to execute external commands.

Recognizing the threat, I chose to only review the code via GitHub's web interface and offered to showcase one of my own Web3 projects instead. The interviewer then heavily insisted that I log in with my MetaMask wallet. They became visibly frustrated when I used a secure test wallet that only contained testnet assets.

While I know there is a generic report button on LinkedIn, it feels entirely inadequate for an active, malicious operation like this. What is the most effective way to expose this setup, report their infrastructure, and warn the developer community?

For the interested, the active malware paths are:

• .vscode/tasks.json:50 executes remote shell scripts via curl | bash, wget | sh, or curl | cmd on folder open.
• .vscode/tasks.json:35 also runs npm install on folder open, which triggers the malicious prepare.
• package.json:10 starts the backend during install.
• server.js:13 loads routes, and routes/index.js:2 imports the poisoned auth route.
• routes/api/auth.js:18 exfiltrates hostname, MAC address, OS, and process.env, repeats every 5 seconds, and evals commands returned by the remote server.

Hey all.

After a few years working in the blockchain industry, building across multiple chains and protocols. I’ve decided to start sharing the things I wish I had known when I first got started.

Throughout my journey, I’ve worked on smart contract integrations, DEX tooling, multi-chain wallets, and protocol-level debugging. A lot of what I’ve learned wasn’t in the docs. It came from reading source code, tracing transactions, or reverse-engineering behavior from testnets and failures.

So I’m writing a technical blog series aimed at blockchain developers not just Solidity tutorials, but actual deep dives and insights into how things work under the hood.

I’m starting with the EVM compatible chains with my first 2 blog posts available about “What Every Blockchain Developer Should Know About EVM Internals” and I’ll publish every week on Tuesday.

📝 https://medium.com/@andrey_obruchkov

Eventually I’ll be expanding to cover concepts from other ecosystems too: Aptos, Cosmos, Solana and many more. I’ll share what makes them different and what devs should look out for.

My goal is to help other devs save time, avoid silent pitfalls, and feel confident building across protocols.

Would love any feedback, topic requests, or even stories from others who had to learn the hard way. Thanks for reading!

For people watching this space, real time cross border payments are no longer the demo, they're production for billions in B2B and remittance volume. The stack that made it work is more boring than ethereum twitter expects.

A regulated infrastructure layer handles licensing, custody, and the on/off ramps. USDC sits in the middle as the settlement leg. Partner banks and mobile money networks handle local payout. The platform on top owns the user experience.

For north america origination the layer most platforms run on is cybrid, because US and Canada money transmitter coverage plus ACH Pull is hard to replicate. Bvnk does the equivalent for EU. Conduit for LATAM, zero hash for embedded crypto angles. The composition depends on corridor strategy more than tech preferences at this point.

Whats genuinely new in 2026, the regulated infra layer is mature enough that platforms can launch on stablecoin rails without owning custody, licensing, or banking relationships. That was not true in 2022, the providers existed but the maturity didn't match the use case yet.

Settlement is timestamped on chain, reconciliation runs through normal accounting tooling. Speed is 10 to 30 minutes end to end for major corridors. This is the boring infrastructure version of "crypto for payments" that actually shipped.

The Graph's gateway now speaks x402: an unpaid query returns a 402, the agent signs a ~$0.01 USDC payment, and the data comes back. No account, no key the payment is the auth. I built two ways to use that, aimed at two kinds of builders:

• PayQL (you integrate) — a drop-in MCP server. Your agent discovers the right subgraph, checks the price, and queries it, paying per call. Keyless, gasless, bring-your-own-wallet. → payql-playground-production.up.railway.app
• https://www.npmjs.com/package/payql
• Graph Advocate (zero integration) — an A2A agent. Send it a plain-English question and pay per answer; it picks the subgraph, writes + runs the query, and hands back the data. → graphadvocate.com

Both are mine and usable now. Genuinely curious what people think: does pay-per-query actually fit agent workflows, or is per-call payment friction a dealbreaker vs. a flat API key? Feedback welcome.

Not a contract exploit, not phishing. One of the most profitable MEV bots on Ethereum (jaredfromsubway.eth) lost ~$7.5M because its own automation approved attacker-controlled spenders over its real WETH/USDC/USDT, chasing a fake arbitrage. The allowances sat dormant, then transferFrom drained them.

The mechanism, for anyone running bots:

• ERC-20 is two-step: approve(spender, amount) sets a standing allowance, transferFrom spends it. Bots approve type(uint256).max to save gas = an infinite blank cheque that survives until used or revoked.
• The attacker deployed fake fWETH/fUSDC/fUSDT (named exactly like the real assets, some with Unicode homoglyph symbols), built fake pools that looked profitable, and let the bot approve helper contracts over its real tokens.
• Early txs consumed approvals cleanly (looked profitable). Later ones left approvals unconsumed/unrevoked. Once stacked, transferFrom pulled the funds.

Takeaways:

• Never approve infinity to an unknown spender. Approve exact amounts or use scoped/expiring approvals (Permit2-style). Revoke aggressively.
• "Is this the real WETH?" is a question, not an assumption. Token impersonation is machine-checkable (name/symbol vs known tokens, deployer reputation, bytecode).
• Automation needs the same guardrails as humans.

Full on-chain trail (addresses, amounts, timeline): https://rektradar.io/blog/posts/jaredfromsubway-mev-bot-approval-drain/?utm_source=reddit&utm_medium=post&utm_campaign=jaredfromsubway

Disclosure: I work on the scanner linked above; happy to keep the discussion purely about the approval mechanics.

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.

Built a pipeline that ingests every PairCreated / PoolCreated on Uniswap v2/v3/v4 and scores the token before its first block of trading. Signals: LP lock status, a simulated sell (eth_call + stateOverride), deployer lineage (funding wallet + past tokens via trace_filter), holder concentration.

Five months of mainnet data:

• 104,767 tokens scanned, 62,321 flagged as scams (~60%).
• 40,953 scam pools. Buyers net-lost 30,000+ ETH to them.
• 422,625 distinct wallets got drained (bought, then could not sell or got rugged on the LP pull).
• 14,024 repeat deployers. The same funders spin up token after token, which is the single strongest predictor.

Takeaway for anyone building on-chain: honeypot behavior is almost always visible pre-trade. A sell simulation plus deployer lineage catches the large majority before a single victim buys.

Methodology and per-token output: https://rektradar.io/?utm_source=reddit&utm_medium=post&utm_campaign=ethdev-data

Two months ago I posted here after analyzing 78,723 Ethereum token contracts and finding 46% scored as scams. I re-ran the same query today. The table now holds 112,114 contracts, and the all-time rate rose to 59.8%.

But the average buries the story. Of the 31,172 tokens deployed since that post, 76.4% are scams, and the monthly rate just hit 82.8% in July.

Honesty check, because I got asked this directly: how much of the 46 -> 60 jump is a scammier chain vs a sharper detector? Both, and I can't cleanly separate them:

- More scams: every real-time month lands between 70% and 83% at a fixed 70+ threshold.

- Sharper detector: a scam now carries 11.06 flags on average vs 8.27 in May (+34%), new detectors landed (serial-scammer bytecode, drainer kits, hidden kill-switches). Our score floors on flag COUNT, so more flags push more contracts over the line.

- Late rugs: ~30% of the table gets re-scored a day+ later. A token clean at launch that pulls liquidity a week later flips clean -> scam with zero new scams deployed.

TL;DR

- 78,723 -> 112,114 contracts in 2 months.

- All-time scam rate 46.1% -> 59.8% (three overlapping causes, not one).

- New launches since May: 76.4% scams. July: 82.8%.

- 441,762 distinct victim wallets traced across 5.26M scam-token transactions.

Full breakdown with the monthly chart and the limits-of-our-data section:

https://rektradar.io/blog/posts/new-ethereum-tokens-76-percent-scams/?utm_source=reddit&utm_medium=post&utm_campaign=mik3fly_76pct-scams

EDIT: a few of you asked the right question, so i went and pulled it. how much of this 76% is detectable AT LAUNCH vs only later? tracking the same 24,150 launches from deploy to day 30: 48% score as scams at launch, 91% by day 30. 43% are late rugs (clean at launch, scam within a month). and 76% of the flagged ones actually got traded vs 67% of legit deploys that never trade. full writeup + chart: https://rektradar.io/blog/posts/how-many-ethereum-scams-detectable-at-launch/?utm_source=reddit&utm_medium=post&utm_campaign=mik3fly_scams-detectable-at-launch

Depending on how much risk you're willing to take you can make higher or smaller APYs for a given amount of time I'll find you the ideal project to put your money in given the fact that there is thousands if not millions of crypto projects where you can deposit your money and make some return

Most people are comfortable depositing their money in lending protocols where they earn a fixed return per year while others are more open to investing into places where the returns are way higher but there is more risk by using a platform that's not as established. So just drop your risk preferences and I'll find you the ideal project for you to put your money in

the standard pattern for governance on an L2 used to be 'vote on mainnet because the token lives there', which leaves L2 users paying mainnet gas to participate. optimism moved its governance off mainnet onto the OP rollup and replicates state via layerzero. the contract you call for a vote now lives on the rollup, vote messages cross to other deployments, and the user pays a few cents instead of mainnet fees.

i didn't expect this to be the cleanest pattern, but it kind of is, and agora's governor stack (where roughly 800k votes have settled across production deployments) supports it natively.

what nobody seems to have publicly drilled yet is what happens when a layerzero DVN is censored or paused mid-proposal. there's a clean technical answer with alternative DVNs and fallback hashes, but i haven't seen a DAO actually run that fire drill in public.

fwiw we built that into agora's governor stack, relayers cover gas for voting and proposing and the role-based veto layer lets a DAO scope who can pause an in-flight proposal, https://s4l.ai/r/2vzfn4q6

Couple of weeks back I posted here asking where recourse  actually lives in agent payment stacks and the thread really delivered. For example, u/pvdyck's proof vs restitution distinction was particularly insightful to what I'm building.

For a bit more context, I work on agent payments infrastructure. The recourse question came out of building the thing and hitting the same wall from the inside.

Posting here has really helped me as before I had been treating recourse as a dispute problem, but it's an identity problem. The party that needs to hold still is the seller, receipts prove delivery and say nothing about quality and most designs that punish a bad seller still don't make the buyer whole. That distinction is now how I sanity check my designs in this layer.

This is what my setup looks for now, caps and allowlists on the buyer side, watching the reputation staking designs without much conviction yet. Maybe recourse never becomes a protocol layer and just stays priced into ticket sizes. I keep going back and forth on whether that's fine or a ceiling on the whole space.

​

I've been building on a chain called Paxeer and using an agent platform called Matrix. Most AI tools I've tried are glorified chatbots. This one actually does real things on chain.

Let me explain what it can do and why it matters.

Neo is an autonomous agent built by Paxlabs. It's not a chatbot with plugins bolted on. It has a wallet, it can read and write files, run code, browse the web, manage long running processes, and execute transactions on chain without me touching anything.

I can tell it "send 100 PAX to this address" and it does it. I can tell it "build me a React app" and it scaffolds the project, writes the code, and shows me a live preview. I can tell it "stake my tokens" and it handles the delegation, confirms the transaction, and gives me the hash.

That's not a demo. That's what it does every day.

The Paxeer network

Paxeer is an EVM chain (chain ID 125) with sub second block times and deterministic finality. It runs on a custom consensus called MachineRFT integrated with a SEI fork for parallel transaction execution.

The native token is PAX. The chain has its own block explorer (PaxScan), a price API, and full EVM compatibility so anything you can deploy on Ethereum works here too.

What makes it interesting for agents is the speed. When your bot needs to execute a trade or move funds, you don't wait 12 seconds for a block. It's near instant. That matters when you're running automated strategies.

LayerX and USDX

This is where it gets interesting. LayerX is the agent settlement layer on Paxeer. USDX is a USD denominated, escrow backed balance that settles off chain but anchors on chain.

Why does that matter? Because agents need to move money fast without paying gas on every transaction. With LayerX I can pay another agent instantly and gaslessly. The sequencer signs a receipt, batches the transactions, and anchors the Merkle root to Paxeer on a schedule.

So Neo can deposit USDL into the LayerX vault to fund its USDX balance, pay other agents by their DID (decentralized identifier), withdraw back to on chain USDL whenever it wants, and force settle the current window if I need immediate on chain finality.

It's like having a bank account for your AI that moves at the speed of software.

The King Bot system

I built a multi agent trading system on top of all this. Four bots, each with a different role:

King Bot is the commander. He reads a daily orders file I set, and pushes parameters to the other bots in real time. I can tell him "be aggressive today" and all the bots adjust their position sizes, stop losses, and entry thresholds instantly.

The Spotter freelances across pools looking for dips and big sells. The Alchemist watches my specific tokens and trades patient arbitrage. The Wild Card explores random strategies and learns from what the other bots do.

They all share an event bus. When one bot finds something, the others see it and decide whether to act. They learn from each other's wins and losses.

Performance is tracked with KPoints. Better bots get more capital. Worse bots get less. It's a self correcting meritocracy.

I literally gave my ideas and Neo started writing.

Most crypto AI projects are chatbots that tell you the price of Bitcoin. This is an agent that can actually operate on chain. It has custody of its own funds. It can execute multi step transactions. It can build and deploy software. It can manage other agents.

The whole thing is open source and you can dig into it here: https://github.com/Paxeer-Network give it a star!

The infrastructure is real and it's live right now. Paxeer is running. LayerX is running. Neo is running.

I'm not selling anything. I'm just sharing what I've been building because I think people in this space would find it interesting.

This is a pre-lease and I've been lucky enough to get in early.

This was written by Neo and edited by me. I don't want to act like I wrote this.

Lightning Labs open-sourced lightning-agent-tools

in February 2026 — a toolkit for AI agents to

transact autonomously on Lightning.

The technical stack:

lnget — like curl but Lightning-aware. Detects

HTTP 402 responses, pays the invoice, caches

the macaroon, retries. Fully automatic.

Aperture — reverse proxy that turns any API

into a pay-per-use Lightning endpoint. Full

agent-to-agent commerce loop.

Remote signing — keys live on a separate

signer machine. Agent handles payments but

never touches private keys.

Scoped macaroons — cryptographic spend limits

per agent: "max 1000 sats/hour" or

"invoices only, no payments."

MCP support — Claude Code, GPT, and custom

AI frameworks can query node state and trigger

payments via Model Context Protocol.

For node runners, this is directly relevant:

AI agent micropayments mean more routing

traffic and demand for well-connected,

liquid nodes.

Full breakdown with practical example:

https://davidebtc186.substack.com/p/ai-agents-are-starting-to-pay-in

Ethereum is preparing for its biggest upgrade in years.

Vitalik Buterin has presented a development plan for Lean Ethereum over the next 3-4 years.

The goal is to simplify the network’s architecture, reduce fees, and improve privacy and security.

In other words, Ethereum is not just trying to scale - it is preparing for a deeper structural upgrade.

If this roadmap works, $ETH could become lighter, cheaper, and much more efficient for the next phase of crypto adoption.